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
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
“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
“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
“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
Differences
1.
2.
3.
4.
5.
6.
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
Differences
7.
8.
9.
10.
11.
12.
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
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
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%
Instructor: G. Rudolph, Summer 2006
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
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
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
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
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
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
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 superduper watch after you’ve lost the
instructions?
Instructor: G. Rudolph, Summer 2006
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
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
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
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
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
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