12 Ways Embedded Systems Are Different From the Desktop

1. 12 Ways Embedded Systems Are Different From the Desktop This list adapted from “Embedded Systems Design” by Arnold S. Berger, with permission. Instructor: G. Rudolph, Summer 2013

2. Rationale • Poses different challenges • Distinct requirements • Requires different strategies and skills • “Normal” rules of thumb are inadequate • Unique opportunities for simplification • Any experience is valuable to potential employers Instructor: G. Rudolph, Summer 2006

3. “Embedded System” • Any device that contains one or more dedicated micropressors or microcontrollers • We don’t think of it as a “computer” • Strict, specific operational constraints Instructor: G. Rudolph, Summer 2006

4. “Real-Time” • MUST respond to external events in a TIMELY fashion • For practical purposes, LATE is just as bad as wrong, a bug, or a crash • The system fails to perform with potentially catastrophic results Instructor: G. Rudolph, Summer 2006

5. “Microprocessor vs.Microcontroller” • Microprocessor: CPU core and other components packaged discretely, separately • Microcontroller: CPU core and other elements integrated into single package • Key distinction: level of integration • Question: what’s fueling the driver toward integration? Instructor: G. Rudolph, Summer 2006

6. Differences • Not Generic Computing Platform! • Many processors and architectures • Cost-sensitivity • Real-time Constraints • May use Real-Time OS (RTOS) • Software failures catastrophic Instructor: G. Rudolph, Summer 2006

7. Differences • Power Constraints • Operate in extreme environments • Resource-restricted • All code in ROM/Flash • Need Specialized Tools & Methods • Processors have dedicated debug circuitry Instructor: G. Rudolph, Summer 2006

8. Not A Generic Computing Platform • Embedded processor is task-specific • Changing the task means changing the entire system • PC’s must be able to run a wide array of programs easily • Processors for heart monitors and toasters aren’t expected to run word processors or spreadsheets Instructor: G. Rudolph, Summer 2006

9. Many Processors & Architectures • PC’s: Intel x86, Sun SPARC • Hundreds of microprocessors are available • auto may contain 100 processors,100M LOC • Jetliners can have > 200 processors10M LOC • Average Household has > 40 processorsPCs make up < 1% Instructor: G. Rudolph, Summer 2006

10. Cost-Sensitive • System cost, not just cost of processor • Replace PCB and Power Supply with Integrated Microcontroller plus smaller Power Supply • Processor more expensive, but overall cost is less • Savings is significant for mass-produced items like cars Instructor: G. Rudolph, Summer 2006

11. Real-time Constraints • Hard vs. Soft real-time constraints • Hard: A task must take place within a specified window of time, or the task fails. • Soft: A task can finish/die gracefully, and everything’s OK. Instructor: G. Rudolph, Summer 2006

12. Real-Time OS • May or may not use an OS • Many RTOS’s available • RTOS is NOT democratic! • Highest priority task that is ready to run gets all the time it needs • If other tasks starve, it’s the programmer’s fault Instructor: G. Rudolph, Summer 2006

13. Software Failures Catastrophic • Suppose a medical machine miscalculates a dosage • Suppose a missile guidance system miscalculates target parameters • Hardware watchdog timer brings system back to life if software loses control Instructor: G. Rudolph, Summer 2006

14. Power Constraints • PC’s usually have massive heat sinks • Embedded systems must run for a long time on minute amounts of power • System is in “sleep” mode most of the time, and is completely interrupt-driven or “reactive” • Power constraints are often the dominant system constraints imposed on the software Instructor: G. Rudolph, Summer 2006

15. Extreme Environmental Conditions • space, ice poles, sea, forest, desert, military, home… • Environmental concerns usually conflict with other requirements • Usually left to the end of the project when the product is being tested, and problems are found • System cannot run outside its “thermal budget” Instructor: G. Rudolph, Summer 2006

16. Far Fewer Resources • VCR controller manages a lot fewer resources than a desktop CPU • Usually driven by cost • Designer usually forced to overload and serialize I/O lines and functions. • Ever try to set the time on your super-duper watch after you’ve lost the instructions? Instructor: G. Rudolph, Summer 2006

17. All Object Code in ROM/Flash • May limit maximum code size • Significant effect on system design & debugging • All startup code must be in ROM, establish runtime environment • Typical debugger can’t set a breakpoint in ROM, because you can’t replace instructions • Specialized tools have evolved to solve debugging issues Instructor: G. Rudolph, Summer 2006

18. Specialized Tools/Methods To Design Effectively • Can’t set breakpoint in ROM code • Must set up execution & runtime environments • Final code is never hardware-independent • ROM Emulator • In-Circuit Emulator (ICE) • Finite State Machines (FSM’s) • (Real-time) UML • Push for standards Instructor: G. Rudolph, Summer 2006

19. Processors Often Have Dedicated Debugging Circuitry • Counter-intuitive given cost sensitivity • Required for chip to be serious contender • Vendor can restrict information about how debug circuitry works Instructor: G. Rudolph, Summer 2006

20. Software Design Concepts • Specific Solutions simpler, more efficient • Handling Errors and Exceptions • Memory Management (Heap) • Event/Message Passing • Multi-tasking, Mutual Exclusion & Blocking • Initialization & Cleanup • Time Management Instructor: G. Rudolph, Summer 2006

21. Why use an RTOS? • Multi-tasking • Scheduling • Timers • Inter-task communication • Isolate/manage software changes WRT hardware • If not using an RTOS, use alternate software framework Instructor: G. Rudolph, Summer 2006

22. Summary • 12 ways embedded systems differ from desktop systems • Key things to think about in design, development, deployment • Up next: embedded system development lifecycle Instructor: G. Rudolph, Summer 2006