embedded system is a special-purpose computer system usually built
into a smaller device. An embedded system is required to meet very
different requirements than a general-purpose personal computer.
EXAMPLES OF EMBEDDED SYSTEMS
- automatic teller machines
- cellular telephones and telephone
- computer network equipment,
including routers, timeservers and firewalls
- computer printers
- disk drives (floppy disk drives
and hard disk drives)
- engine controllers and antilock
brake controllers for automobiles
- home automation products,
like thermostats, air conditioners, sprinklers, and security monitoring
systems handheld calculators
- household appliances, including
microwave ovens, washing machines, television sets, DVD players/recorders
inertial guidance systems, flight control hardware/software and
other integrated systems in aircraft and missiles medical equipment
- measurement equipment such
as digital storage oscilloscopes, logic analyzers, and spectrum
- personal digital assistants (PDAs), i.e.
small handheld computers with PIMs and other applications programmable
logic controllers (PLCs) for industrial
automation an monitoring stationary videogame consoles and handheld
CHARACTERTICS OF EMBEDDED
Two major areas of differences are cost and power
consumption. Since many embedded systems are produced in the tens
of thousands to millions of units range, reducing cost is a major
concern. Embedded systems often use a (relatively) slow processor
and small memory size to minimize costs.
The slowness is not just clock speed. The whole architecture
of the computer is often intentionally simplified to lower costs.
For example, embedded systems often use peripherals controlled by
synchronous serial interfaces, which are ten to hundreds of times
slower than comparable peripherals used in PCs.
Programs on an embedded system often must run with
real-time constraints with limited hardware resources: often there
is no disk drive, operating system, keyboard or screen. A flash
drive may replace rotating media, and a small keypad and LCD screen
may be used instead of a PC's keyboard and screen.
Firmware is the name for software that is embedded
in hardware devices, e.g. in one or more ROM/Flash memory IC chips.
Embedded systems are routinely expected to maintain
100% realibility while running continuously for long periods, sometimes
measured in years. Firmware is usually developed and tested to much
stricter requirements than is general purpose software which can
usually be easily restarted if a problem occurs.
There are many different CPU architectures
used in embedded designs. This in contrast to the desktop computer
market, which as of this writing (2003) is limited to just a few
competing architectures, mainly the Intel/AMD x86, and the
Apple/Motorola/IBM PowerPC, used in the Apple Macintosh.
One common configuration for
embedded systems is the system on a chip, an application-specific
integrated circuit, for which the CPU was purchased as intellectual
property to add to the IC's design.
Like a typical computer programmer, embedded
system designers use compilers, assemblers and debuggers to develop
an embedded system.
Those software tools can come from several sources:
- Software companies that specialize
in the embedded market
- Ported from the GNU software development tools.
- Sometimes, development tools for a personal computer
can be used if the embedded processor is a close relative to a
common PC processor.
Embedded system designers also use a few software
tools rarely used by typical computer programmers.
- Some designers keep a utility program to
turn data files into code, so that they can include any kind of
data in a program.
- Most designers also have utility programs
to add a checksum or CRC to a program, so it can check its program
data before executing it.
They often have no operating system, or a specialized
embedded operating system (often a real-time operating system),
or the programmer is assigned to port one of these to the new system.
Debugging is usually performed with an in-circuit
emulator, or some type of debugger that can interrupt the microcontroller's
The microcode interrupt lets the debugger operate
in hardware in which only the CPU works. The CPU-based debugger
can be used to test and debug the electronics of the computer from
the viewpoint of the CPU. This feature was pioneered on the PDP-11.
Developers should insist on debugging which shows
the high-level language, with breakpoints and single-stepping, because
these features are widely available. Also, developers should write
and use simple logging facilities to debug sequences of real-time
PC or mainframe programmers first encountering
this sort of programming often become confused about design priorities
and acceptable methods. Mentoring, code-reviews and egoless programming
DESIGN OF EMBEDDED SYSTEM
The electronics usually uses either a microprocessor
or a microcontroller. Some large or old systems use general-purpose
mainframe computers or minicomputers.
REAL TIME OPERATING
A Real Time Operating System or RTOS is an operating
system that has been developed for real-time applications. Typically
used for embedded applications they usually have the following characteristics:
- Small footprint (doesn't use much memory)
- Pre-emptable (any hardware event can cause a task
- Multi-architecture (code ports to another type
- predictable response-times to electronic events
It is a fallacy to believe that this type of operating
system is "efficient" in the sense of having high throughput.
The specialized scheduling algorithm and a high clock-interrupt
rate can both interfere with throughput.
Many real-time operating systems have scheduler and
hardware driver designs that minimize the periods for which interrupts
are disabled, a number sometimes called the interrupt latency. Many
also include special forms of memory management that limit the possibility
of memory fragmentation and assure a minimal upper bound on memory
allocation and deallocation times.
An early example of a large-scale real-time operating
system was the so-called "control program" developed by
American Airlines and IBM for the Sabre Airline Reservations System.
Debate exists about what actually constitutes real-time.
There are two basic designs:
- An event-driven operating system only changes
tasks when an event requries service.
- A time-sharing design switches tasks on a clock
interrupt, as well as on events.
The time-sharing design wastes more CPU time on unnecessary
task-switches. However it also gives a better illusion of multitasking.
In typical designs, a task has three states: running,
ready and blocked. Most tasks are blocked, most of the time. Only
one task per CPU is running. The ready list is usually short, two
or three tasks at most.
The real trick is designing the
scheduler. Usually the data structure of the ready list in the scheduler
is designed so that search, insertion and deletion require locking
interrupts only for small periods of time, when looking at precisely
defined parts of the list. This means that other tasks can operate
on the list asynchronously, while it is being searched. A typical
successful schedule is a bidirectional linked list of ready tasks,
sorted in order by priority. Although not fast to search, the time
taken is deterministic. Most ready lists are only two or three entries
long, so a sequential search is usually the fastest, because it
requries little set-up time.
The critical response time, sometimes
called the flyback time is the time it takes to queue a new ready
task, and restore the state of the highest priority task. In a well-designed
RTOS, readying a new task will take 3-20 instructions per ready
queue entry, and restoration of the highest-priority ready task
will take 5-30 instructions. On a 20MHz 68000 processor, task switch
times run about 20 microseconds with two tasks ready. 100 MIP ARM
CPUs switch in a few microseconds.
TO EACH OTHER
The only multitasking problem that multitasked systems
have to solve is that they cannot use the same data or hardware
at the same time. There are two notably successful designs for coping
with this problem:
- Message passing
A semaphore is either locked, or unlocked. When locked
a queue of tasks wait for the semaphore. Problems with semaphore
designs are well known: priority inversion and deadlocks. In priority
inversion, a high priority task waits because a low priority task
has a semaphore. A typical solution is to have the task that has
a semaphore run at the priority of the highest waiting task. In
a deadlock, two tasks lock two semaphores, but in the opposite order.
This is usually solved by careful design, implementing queues, or
by having floored semaphores (which pass control of a semaphore
to the higher priority task on defined conditions).
The other solution is to have
tasks send messages to each other. These have exactly the same problems:
Priority inversion occurs when a task is working on a low-priority
message, and ignores a higher-priority message in its in-box. Deadlocks
happen when two tasks wait for the other to respond.
Although their real-time behavior is less crisp than
semaphore systems, message-based systems usually unstick themselves,
and are generally better-behaved than semaphore systems.
INTERRUPT INTERFACE TO THE
Typically, the interrupt does a few things that it
must do to keep the electronics happy, then it unlocks a semaphore
blocking a driver task, or sends a message to a waiting driver task.
Memory allocation is even more
critical in a RTOS than in other operating systems.
Firstly, speed of allocation
is important. A standard memory allocation scheme scans a linked
list of indeterminate length to find a suitable free memory block;
however, this is unacceptable as memory allocation has to occur
in a fixed time in a RTOS.
Secondly, memory can become fragmented as free regions
become separated by regions that are in use. This can cause a program
to stall, unable to get memory, even though there is theoretically
enough available. Memory allocation algorithms that slowly accumulate
fragmentation may work fine for desktop machineswhen rebooted
every month or sobut are unacceptable for embedded systems
that often run for years without rebooting.
The simple "fixed-size-blocks" algorithm
works astonishingly well for simple embedded systems.
See memory allocation for more details.
USE OF MEMORY IN DEEPLY EMBEDDED
Some RTOSes (or embedded OSes) support XIP (Execute
In Place) where the kernel and applications are executed directly
from ROM instead of transferring the code to RAM first. This offers
a tradeoff between the required RAM size and ROM size of the OS.
- Windows CE
Various companies also sell customised versions
of Linux with added real-time functionality.