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

Instructor: G. Rudolph, Summer 2013

12 Ways Embedded Systems 12 Ways Embedded Systems Are Different From the Are Different From the

DesktopDesktop

This list adapted from “Embedded Systems This list adapted from “Embedded Systems Design” by Arnold S. Berger, with Design” by Arnold S. Berger, with permission.permission.


RationaleRationale

Poses different challengesPoses different challenges Distinct requirementsDistinct requirements Requires different strategies and skillsRequires different strategies and skills ““Normal” rules of thumb are inadequateNormal” rules of thumb are inadequate Unique opportunities for simplificationUnique opportunities for simplification Any Any experience is valuable to potential experience is valuable to potential

employersemployers


“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


“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


“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?


Differences

1. Not Generic Computing Platform!2. Many processors and architectures3. Cost-sensitivity4. Real-time Constraints5. May use Real-Time OS (RTOS)6. Software failures catastrophic


Differences

7. Power Constraints8. Operate in extreme environments9. Resource-restricted10. All code in ROM/Flash11. Need Specialized Tools & Methods12. Processors have dedicated debug

circuitry


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


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 processors

10M LOC Average Household has > 40 processors

PCs make up < 1%


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


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.


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


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


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


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”


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?


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


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


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


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


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


Summary

12 ways embedded systems differ from desktop systems

Key things to think about in design, development, deployment

Up next: embedded system development lifecycle

Documents

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