Embedded Systems
Thanos Stathopoulos
CS239 Spring 03
Introduction
• Embedded systems: What are they?
– ‘A special purpose computer built into a larger device’
• ‘Special-purpose’
– Embedded systems have a (more or less) well-defined
purpose
– Contrast with: general purpose computers (PCs etc)
• ‘Built into a larger device’
– Ess are (usually) part of a larger device, augmenting its
capabilities
Some history…
The first Embedded System: Apollo Guidance
Computer
http://www.nasm.si.edu/nasm/dsh/artifacts/GC-ApolloBlock1.htm
Today/Tomorrow
Embedded Systems in today’s
world
• Signal processing systems
– Real-time video, set-top boxes, DVD players, medical
equipment, residential gateways
• Distributed control
– Network routers, switches, firewalls, mass transit
systems, elevators
• “Small” systems
– Mobile phones, pagers, home appliances, toys,
smartcards, MP3 players, PDAs, digital cameras,
sensors, smart badges
Cars (again)
• Modern cars: Up to 100
or more processors
– Engine control unit
– Emissions control
– Diagnostics
– Automatic transmission
– Accessories (doors,
windows etc)
http://www.howstuffworks.com/car-computer.htm
The CPU marker
• Pervasive/Ubiquitous computing <=
Embedded systems
– Reverse not true
Embedded System
Characteristics
• Part of a larger system
– Limited peripherals
• Application-specific
– Both hardware and software is tailored to
application(s), which are well defined
– However, re-programmability is a requirement
– ‘HALT’ is a bad state!
• Interaction with the physical world
Constraints
• Hardware
– CPU, Memory
– Power consumption
– Limited peripherals and slower buses
– Size, weight, environmental reliability
• Software
– Latency
• ‘Hard’ or ‘Soft’ Real-time requirements
– Limited HW resources
– Reliability
• Not very easy to debug
– Device heterogeneity
• Interoperability becomes an issue!
Typical ES Hardware
• Commercial off-the-shelf components (COTS)
– e.g. wireless radios, sensors, I/O devices
– Cheap
• Application-Specific ICs (ASICs)
– ICs tailored to meet application needs
– Good performance for their intended task(s)
– Original Ess were ASICs only
• Domain-specific processors
– DSPs
– Microcontrollers
– Microprocessors
New trends in ES H/W
• Systems-on-chip
– Usual (or desired) specs:
• 32-bit RISC CPU
• Built-in interfaces to RAM and ROM
• Built-in DMA, interrupt and timing controllers
• Built-in interfaces to disk or flash memory
• Built-in Ethernet/802.11 interfaces
• Built-in LCD/CRT interfaces
– New SOCs appearing almost every week!
• Examples
– Intel StrongARM SA-1110
– Motorola PowerPC MPC823e
– NEC VR4181
– Many, many more
http://www.linuxdevices.com/articles/AT4313418436.html
Small (and cool) SOCs
• Camera-on-chip
(Bell Labs)
• CMOS-based
• 100,000 optical
sensors in a 2D grid
(active pixels)
• Very low power
• Cheap (~$50)
http://www.bell-labs.com/news/1998/july/15/1.html
Small (and cool) SOCs (cont’d)
• SPEC: one step closer to “Smart Dust”
– 2mm x 2.5 mm
– AVR-like RISC core
– 3k RAM
– 8-bit ADC
– FSK radio transceiver
– Paged memory system
– Lots of other cool stuff…
• Manufacturing cost
– $ 0.3 for the die
– $ 0.5 for the five external components
(antenna, crystals, power source etc)
http://www.cs.berkeley.edu/~jhill/spec/
Beyond SOCs: RSOCs
• Reconfigurable System-on-Chip
– Processor core + (re)Programable logic
• E.g. FPGAs
• Changing the system behavior at the hardware level
– Examples:
• Atmel’s FPSLIC
– Up to 40K Gates
– 8-bit microcontroller @ 40 MHz
• Triscend’s A7S
– Up to 40K Gates
– ARM-based
http://www.atmel.com/products/FPSLIC/
http://www.triscend.com/products/a7.htm
Embedded Software
• Principal role: ‘Not transformation of data
but interaction with physical world’
• Acquires properties of physical world
– Takes time
– Consumes power
– Does not terminate (unless it fails)
Problems with Embedded
Software
• Vast majority written by people who are not comp.
scientists
– Challenge for CS: inventing better abstractions for the domain
experts to do their job
– Domain experts are skeptical
• ‘They see Java programs stalling for 1/3 second to perform garbage
collection and update the UI and envision airplanes falling out of the
sky’
• The methods used in general-purpose software require
considerable adaptation
– Perhaps new abstractions are needed
Embedded Software Properties
• Timeliness
• Concurrency
• Liveness
• Interfaces
• Heterogeneity
• Reactivity
Timeliness
• Time: systematically removed from theories of
computation
• RTOSes often reduce the characterization of a task
to a single number (its priority)
• But: computation does take time
– However, even with infinitely fast computers, time would
still have to be dealt with
• Physical processes evolve over time
• Need to find abstractions that regain control of time!
Concurrency
• In the physical world, multiple things happen at once
• Challenge: reconcile sequentiality of software with the
concurrency of the real world
– Classic approaches (semaphores, monitors etc) provide good
foundation
• But: potentially insufficient
– One approach: compile concurrency away (Estrel)
• Estrel: synchronous/reactive language
– FSM based, deterministic behavior
• Pros: Higly reliable programs
• Cons: Too static for some systems
– Middle ground is needed
Liveness
• Programs must not terminate
– Unlike the traditional Turing model of computation,
halting is undesirable
– Deadlock is an absolute ‘no-no’
• Correctness isn’t just about getting the right
final answer
– Must consider things like timing, power
consumption, fault recovery, security and robustness
Reactivity
• Interactive systems:
– react at their own speed (or the speed of the controlling human)
• Transformational systems
– Transform a data input to a data output (e.g. matrix multiplication)
• Reactive systems
– react continuously with environment, at the same speed
– Must adapt to changing conditions
• Resources and demands may change frequently
– Real-time constraints
– Safety-critical
• Fault-tolerance can be a major issue
Embedded Operating Systems
• Office-style OSes
– PalmOS
– WindowsCE
• RTOSes
– VxWorks
– QNX
• Linux
– Linux is already ubiquitous
• Hundreds of different devices are using it
• http://www.linuxdevices.com/articles/AT4936596231.html
– Several variations-from ‘soft real time’ to ‘hard real time’
– Numerous commercial + open source products
• Others
– TinyOS
Typical Scheduling Techniques
in Embedded OSes
• Cyclic executive
– Static schedulability analysis
• Result used at runtime
– Great for periodic tasks
• But: inflexible
• Event-driven non-preemptive
– Tasks represented by functions (event handlers)
– FIFO
– Safe, but limited
Scheduling (cont’d)
• Static/dynamic priority preemptive scheduling
– Static schedulability analysis
– No explicit schedule: at run-time execute highest
priority task first
• Rate/deadline monotonic, earliest deadline first, least
slack
– Flexible, but potentially dangerous
• Priority inversion
• Deadlock
Scheduling (cont’d)
• Dynamic planning-based scheduling
– Schedulability checked at runtime for a dynamically arriving task
• Resulting schedule decides when to execute
• If scheduling fails, take alternative action
– Flexible and fairly predictable
• Dynamic best-effort scheduling
– No checks
• No knowledge if timing constraints met until task finishes (or
deadline expires)
– System tries to meet deadlines
• Tasks can be preempted at any time
Which OS to choose?
• Depends on the device and the task(s) it needs to
perform
• You might even want to build your own
• There are cases when an embedded OS is not
needed at all!
– Sometimes all that’s needed is an infinite loop with a
couple of interrupt handlers
– “Getting by without an RTOS”
http://www.embedded.com/2000/0009/0009feat4.htm
Bridging the HW/SW gap: The
future?
“Automatically configurable embedded Linux OS for an
Extensible Processor core”
– Start with a version of Linux for the base version of the
processor core
– As modifications are made (remember RSOCs), the ‘OSkit’ is
generated and allows the base version to be automatically
updated
– Does it work?
• I don’t know but Tensilica (rSOC) and MontaVista(Linux) seem to
think so…
• http://www.tensilica.com/html/pr_2003_04_23.html
References
• CACM Vol 43, num. 5, May 2000
• Edward Lee, “Embedded Software”
– http://citeseer.nj.nec.com/497408.html
• http://www.embedded.com
• http://www.wikipedia.org/wiki/Embedded_system
• http://www.linuxdevices.com
• Mani Srivastava’s EE202A class
– http://nesl.ee.ucla.edu/courses/ee202a/2002f/
