1. The Embedded System Design Process Chapter 1

2. Designing Embedded Systems How is designing an embedded system different from a non-embedded system? Generally speaking, there are two (sometimes three) design paths running in parallel –Hardware –Embedded software (often called firmware) –Host software (we won’t really address this here)

3. Embedded System Design Phases Product specification Hardware/software partitioning Partition iteration/refinement Independent hardware and software design Hardware/software integration Product testing Maintenance and upgrade Repeat as necessary

4. Embedded System Design Phases

5. An Alternate View Tool-based development cycle Based not so much on what has to be done as on what has already been done –Available processors –Available software development tools –Available hardware development tools –Available testing support tools –Available hardware/software designs from previous projects More on this approach when we start discussing tools

6. Tool-Based View

7. Product Specification Two approaches –Build a device that does everything under the sun –Build a device that suites the customer’s needs This should be a marketing function but inclusion of the design team can be beneficial (if not critical)

8. Product Specification Customer Research Tour –Marketing person (1) Leads the meeting Asks questions, presents possible solutions –Engineering/design specialists (2 or 3) Wait in the shadows Provide technical support or ask/clarify technical questions Take notes

9. Product Specification Debriefing –Soon after customer meeting –Compare notes –Assess customer reactions Translation to specification –Convert customer reactions to design requirements

10. Product Specification Goals: –Get the design team (and marketing team) to share a common vision of the product –Make sure that the common vision is consistent with the market (what the customer wants) –Make sure that the tools required by the design team are available

11. Product Specification This approach is the starting point for what software developers call agile methods –Extreme programming Communication Simplicity Feedback Courage This is especially important in embedded systems design because of the integrated hardware/software complexities

12. Product Specification Digital cellphone camera example –This was not done! –Engineers were not consulted –Marketing data was poorly gathered –Marketing personnel reacted to customer “wants” with “sure, we can do that” Unfortunately, every customer wanted something different from the rest –It was “give them everything including the kitchen sink” –Recipe for disaster – and that’s how it turned out

13. Hardware/Software Partitioning The partitioning decision –Which part of the solution will reside in hardware and which part in software? –Specify the desired algorithm as a sequence of processing stages –Map processing stages to either hardware or software

14. Hardware/Software Partitioning Decision criteria –System performance requirements –Future upgrades –Development cost –End product cost –Time to market (market competition) –Intellectual property protection –Standard vs. non-standard components –Market leader or market follower These criteria can (and do) conflict with one another

15. Hardware/Software Partitioning Designers may choose an evolutionary path –Start with items in software for initial product release –Move to hardware for subsequent releases –Reduces Initial time to market Development cost Opportunity to reduce product cost on subsequent releases Ultimately, it comes down to experience

16. Hardware/Software Partitioning Digital cellphone camera Sensor Color Image Processing Image Compression Image Storage User Interface There are many HW/SW partitioning possibilities Host Support Control

17. Partition Iteration/Refinement Last chance before hardware and software paths diverge –Dependence on tools to validate (or invalidate) the partitioning decision –Hardware designers use simulation tools to model performance –Software designers use evaluation boards (like the Stamp boards) to develop and benchmark code

18. Partition Iteration/Refinement Nowadays, the time when the hardware and software paths diverge is being pushed further out –The toolsets are sophisticated enough to provide confidence in the decision while not holding off development

19. Partition Iteration/Refinement Digital cellphone camera Sensor Color Image Processing Image Compression Image Storage User Interface Host Support Control Analog hardware Software → Digital hardware → Analog hardware Digital hardware Software

20. Independent Hardware and Software Design These are specific to –The task at hand –The field (hardware or software) –Various design practices exists –Some will be discussed later but, realistically, these are topics of individual classes, if not entire degrees and specialties Software engineering Electrical engineering –Analog circuit design –Digital circuit design Systems engineering Mechanical engineering etc.

21. Hardware/Software Integration Exercise in debugging and discovery… –and frustration Hardware not built as originally designed Software not written as originally designed Errors in the hardware that can’t be fixed within allotted time/budget Additional software to compensate for hardware shortcomings

22. Hardware/Software Integration System works but… –Is too slow –Doesn’t meet quality needs –Late to market –No longer meets customer needs –…–…

23. Hardware/Software Integration System doesn’t work so… –Focused Ion Beam (FIB) chips –Add wires to board –Cut traces in board –Add “dead-bugs” to board –Repartition hardware functions into software –Remove software functionality –Rewrite software –…–…

24. Hardware/Software Integration These things occur for various reasons –Communication problems Lack of communication Lack of a common language –Complex, non-deterministic behaviors The tools go only so far –Design optimism Original design goals were just too aggressive

25. Hardware/Software Integration Digital cellphone camera –Due to the complexity of the analog circuitry there was a fair amount of repartitioning i.e. fix it in software and we’ll re-spin the hardware next time –Produced a suitable solution but was considerably slower than originally specified –It reverted back to a marketing problem i.e. this is what we have, figure out how to sell it

26. Hardware/Software Integration Digital cellphone camera –Subsequent product revisions moved software functionality into digital hardware Increased processing speed Reduction in product cost –Of course the cost of the “improvements” is loss of flexibility –Again, this ultimately becomes a marketing problem

27. Product Testing Requirements are generally more stringent than for a software only system –We can no longer live with “just reboot when it hangs up” “it’s only a small memory leak” “oh well, it’s fast enough” –Embedded systems often run for long periods of time between resets Testing must ensure system integrity over these long periods Testing must expose every nuance of the system

28. Product Testing Embedded systems are often placed in environments where the PC dare not go –Extreme temperatures –Extreme impacts –Extreme vibrations –Extreme dirt and filth –etc… The product must be tested under all of these conditions

29. Product Testing A well thought out test plan developed at the beginning of the product life cycle (the requirements phase) can alleviate [some] testing pains –What to test (specify the features to be tested) –How to test (specify the tests) –Test oracle (specify the expected answers) –Test group (who will perform the tests and who will evaluate the results) –Test response (what to do with the results)

30. Product Testing Digital cellphone camera –Testing poses a real problem Some things were easy in that they either worked or the didn’t Some things were difficult in that they are very subjective –“that image is too blue” … “no, it’s too red” –“it’s not vibrant” –“it’s too hazy” –“it’s too bright” … “no, it’s too dark” Basically, people started making up terms and measures for which there is no way to test –I believe it was due to poor marketing, relating back to the lack of that initial customer research tour (but then I’m an engineer)

31. Product Testing Digital cellphone camera –And that was just the image quality… –Environmental testing required exotic test setups Special heat chambers The “drop test” “burn in” testing (testing over time) –Production testing Can only spend seconds per part or you’re losing money

32. Maintenance and Upgrade Time to market is perhaps the most critical design goal today –To meet the time to market goal many embedded systems products get to market with… Reduced feature sets Known bugs Suboptimal hardware/software partitioning Maintenance and upgrade engineers address these shortcomings

33. Maintenance and Upgrade Often it is a different team of engineers with no overlap with the original design team –Can’t afford not to put your best designers on your newest products Often there are constraints of not making any major changes –Any new hardware must be “plug-compatible” –Any new software must fit into the current architecture These constraints often lead to a “family of products”

34. Maintenance and Upgrade Bottom line is it isn’t always fun and is rarely appreciated –Who wants to here about fixing old stuff when someone is talking about building new stuff

35. Maintenance and Upgrade Digital cellphone camera –Move software processing into hardware while maintaining chip compatibility –Add more pixels to the sensor while maintaining software compatibility –Fix design errors Generally it’s a “fix it in software” mentality because the market moves so fast and new hardware designs take time

36. Tonight’s Lab Testing

37. Testing Pins Your Basic Stamp board has –32 connectors for I/O pins (2 connectors/pin) –6 Vdd connectors –7 Vss connectors It is important to know that all connectors are working prior to embarking on a large scale project

38. Testing Pins To Do –Download the test report –Download the test circuit designs –Download the test software –Perform tests Yes, this is tedious and seems unnecessary…welcome to the world of embedded systems design

39. Homework

40. Homework/Project Homework #2 – see handout Project #2 – see following charts

41. Traffic Light Simulation

42. Stoplight Timeline tntn t button t button+10 North/South East/West t button+41 t button+51 t button+52 repeat forever Note: While this diagram depicts a fixed time interval scheme. Your code should provide variables so that the scheme can be easily changed. t button+20 t button+21

43. In words… 1.Initial condition: Light 1 is red, light 2 is green 2.Press button (to signify car waiting) 3.Pause – long 4.Light 2 turns yellow 5.Pause – short 6.Light 2 turns red 7.Pause – short 8.Light 1 turns green 9.Press button (to signify car waiting) 10.Pause – long 11.Light 1 turns yellow 12.Pause – short 13.Light 1 turns red 14.Pause – short 15.Light 2 turns green 16.Goto step 2

44. Deliverables A state-machine diagram depicting the operation of the system Source code A schematic diagram of the circuit A working demonstration on the Basic Stamp development board (in class)