EXAMPLES OF EMBEDDED SYSTEMS

• automatic teller machines (ATMs)
• cellular telephones and telephone switches
• 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 analyzers
  multifunction wristwatches
• 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 game consoles
  

CHARACTERTICS OF EMBEDDED SYSTEM

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.

PLATFORM

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.

TOOLS

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. (cross-compiler)
• 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.

OPERATING SYSTEM

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

Debugging is usually performed with an in-circuit emulator, or some type of debugger that can interrupt the microcontroller's internal microcode.

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 events.

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 are recommended

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 SYSTEM

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 to run)
• Multi-architecture (code ports to another type of CPU)
• 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.

DESIGN PHILOSOPHIES

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.

SCHEDULING

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.

TASK INTERFACES 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:

• Semaphores
• 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 SCHEDULER

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

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 machines—when rebooted every month or so—but 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 SYSTEMS

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.

EXAMPLES RTOSes

• eCos
• ITRON
• MicroC/OS-II
• OS-9
• OSE
• OSEK/VDX
• pSOS
• QNX
• RSX-11
• RT-11
• RTOS-UH
• VRTX
• VxWorks
• Windows CE
• RTLinux
• RTAI

Various companies also sell customised versions of Linux with added real-time functionality.