Embedded Systems Examples

A First Lock at Embedded Systems

As microprocessors have become smaller and cheaper, more and more products have microprocessors "embedded" in them to make them “smart.” Such products as digital watches, elevators, automobile engines, thermostats, industrial control equipment, and scientific and medical instruments are driven by these microprocessors and their software. People use the term embedded system to mean any computer system hidden in any of these products.
Software for embedded systems must handle many problems beyond those found in application software for desktop or mainframe computers. Embedded systems often have several things to do at once. They must respond to external events (e.g., someone pushes an elevator button). They must cope with all unusual conditions without human intervention. Their work is subject to deadlines.

Examples of Embedded Systems

To understand the issues of embedded-systems software and to make the problems a little more concrete, let's start by examining a few sample systems.

Telegraph

The first system that we will study is one that was code-named “Telegraph” during its development. Telegraph allows you to connect a printer that has only a high-speed serial port to a network. From the outside, Telegraph is a little plastic box, 2 to 3 inches on a side and about half an inch thick. A pigtail cable on one side of the box plugs into the serial port on the printer. A connector on the other side of the box plugs into the network.

Obviously, Telegraph must receive data from the network and copy it onto the serial port. However, Telegraph is rather more complicated than that. Here are just a few things that Telegraph must do:

On the network, data sometimes arrive out of order, data sometimes get lost along the way, and some of the data sometimes arrive twice. Telegraph must sort out the chaos on the network and provide a clean data stream to the printer.
There might be lots of computers on the network, all of which might want to print at once. The printer expects to be plugged into a single computer. Telegraph must feed the printer one print job at a time and somehow hold off all the other computers.
Network printers must provide status information to any computer on the network that requests it, even if they are busy printing a job for some other computer. The original, serial-port printer can't do that. Telegraph has to.
Telegraph has to work with a number of different types of printers without customer configuration. Telegraph has to be able to figure out the kind of printer to which it is attached.
Telegraph must respond quite rapidly to certain events. There are, for example, various kinds of network frames to which Telegraph must send a response within 200 micro seconds.
Telegraph must keep track of time. For example, if a computer that has been sending print data to Telegraph crashes, Telegraph must eventually give up on that print job-Perhaps after 2 minutes and print from another computer on the network. Otherwise, one computer crash would make the printer unavailable to everybody.

Telegraph Development Challenges

To satisfy the list of requirements given above, Telegraph has a microprocessor embedded in it. Its software is more extensive and sophisticated than its external appearance might lead you to believe. What problems arise in developing such software?
To begin with, of course, software for Telegraph must be logically correct. It can't lose track of which computer is printing or drop data or report incorrect status. This is the same requirement placed on every piece of software in both the embedded and the applications arenas. However, writing the software for Telegraph-like writing software for many other embedded systems-offers up a few additional challenges, which we shall now discuss.

Throughput

The printer can print only as fast as Telegraph can provide data to it. Telegraph must not become a bottleneck between the computers on the network and the printer. For the most part, the problem of getting more data through an embedded system is quite similar to that of getting an application to run faster. You solve it by clever programming better searching and sorting, better numerical algorithms, data structures that are faster to Parse, and so on.

Response

When a critical network frame arrives, Telegraph must respond within 200 microseconds, even if it is doing something else when the frame arrives. The software must be written to make this happen.
People often use the relatively fuzzy word "speed" However, embedded system designers must deal with two separate problems -throughput and response- and the techniques for dealing with the two are not at all the same. In fact, dealing with one of these problems often tends to make the other one worse.

Testability

It is not at all easy to determine whether Telegraph really works. The problem is that a lot of the software deals with uncommon events. Telegraph is typical of embedded systems in this regard, because these systems must be able to deal with anything without human intervention. For example, lots of the Telegraph code is dedicated to the problem that data might get lost on the network. However, data doesn't get lost very often.
Similarly, Telegraph must deal with events that are almost simultaneous. If two computers request to start their print jobs at exactly the same time, for example, does the software cope properly? Telegraph contains code to handle this situation, but how do you make it happen in order to test that code?

Debugability

What do you think typically happens when testing uncovers a bug in the Telegraph software? Telegraph has no screen; no keyboard; no speaker; not even any little lights. When a bug crops up, you don't get any cute icons or message boxes anywhere. Instead, Telegraph typically just stops working. A bug in the network software? A bug in the software that keeps track of which computer is printing? A bug in the software that reports printer status? Telegraph just stops working.
Unfortunately, having Telegraph stop working doesn't give you much in- formation about a bug. Further, with no keyboard and screen you can't run a debugger on Telegraph. You must find other ways to figure out what has happened.

Reliability

Like most other embedded systems, Telegraph is not allowed to crash. Although customers seem to have some tolerance for desktop systems that must be rebooted once in a while, nobody has any patience with little plastic boxes that crash. In particularly awkward situations, application software can put a message on the screen and ask the user what to do. Embedded systems do not have that option; whatever happens, the software must function without human intervention.

Memory Space

Telegraph has only a very finite amount of memory-specifically, 32 KB of memory for its program and 32 KB of memory for its data. Making software fit into the available space is a necessary skill for many embedded-system software engineers.

Program Installation

The software in Telegraph didn't get there because somebody clicked a mouse on an icon. Special tools that are needed to install the software into embedded systems.

Cordless Bar-Code Scanner

Let's turn to another embedded-systems example, a cordless bar-code scanner. Whenever its user pulls the trigger, the cordless bar-code scanner activates its laser to read the bar code and then sends the bar code across a radio link to the cash register.
How do the problems of developing the software for the cordless bar-code scanner compare to those of developing the software in Telegraph?
Well, they're mostly the same. One problem that the cordless bar-code scanner does not have is the problem of throughput. There just isn't data in a bar code, and the user can't pull the trigger that fast. On the other hand, the cordless bar-code scanner has one problem that Telegraph does not.

Power Consumption

Since the scanner is cordless, its battery is its only source of power, and since the scanner is intended to be handheld, the weight of the battery is limited by what an average user can comfortably hold up. How long does the customer want the battery to last? The obvious answer—forever—isn't feasible. What is the next best answer?
The next best answer is that the battery should last for an 8-hour shift. After that, the scanner can go back into a holster on the side of the cash register for the night and recharge its battery. It turns out, however, that it also isn't feasible to run a laser, a microprocessor, a memory, and a radio for 8 hours on battery power. Therefore, one of the major headaches of this software is to figure out what parts of the hardware are not needed at any given time and turn those parts off. That includes the processor.

Laser Printer

Another embedded system is the laser printer. Most laser printers have fairly substantial microprocessors embedded in them to control all aspects of the printing. In particular, that microprocessor is responsible for getting data from the various communication ports on the printer, for sensing when the user presses a button on the control panel, for presenting messages to the user on the control panel display, for sensing paper jams and recovering appropriately, for noticing when the printer has run out of paper, and so on. But the largest responsibility of the microprocessor is to deal with the laser engine, which is that part of the printer responsible for putting black marks on the paper. The only thing that a laser engine knows how to do without microprocessor assistance is to put a black dot or not to put a black dot at each location on a piece of paper. It knows nothing about the shapes of letters, fonts, font sizes, italic, underlining, bold, or any of those other things that printer users take for granted.
The microprocessor must read the input data and figure out where each black dot should go. This brings us to another problem found in some embedded systems.

Processor Hogs

Figuring out where the black dots go when a printer has been asked to print some text on a slanted line with an unusual font in a screwball size takes a lot of time, even for powerful microprocessors. Users expect a quick response when they push buttons, however; it is no concern of theirs that the microprocessor is busy figuring out values for trigonometric functions to discover where on the page the serif of a rotated letter should go. Work that ties up the processor for long periods of time makes the response problem that much harder.

Underground Tank Monitor

The underground tank monitoring system watches the levels of gasoline in the underground tanks at a gas station. Its principal purpose is to detect leaks before the gas station turns into a toxic waste dump by mistake and to set off a loud alarm if it discovers one. The system also has a panel of 16 buttons, a 20-character liquid crystal display, and a thermal printer. With the buttons, the user can tell the system to display or print various information such as the gasoline levels in the tanks or the time of day or the overall system status.
To figure out how much gasoline is in one of the tanks, the system first reads the level of two floats in the tank, one of which indicates the level of the gasoline and one of which indicates the level of the water that always accumulates in the bottom of such tanks. It also reads the temperature at various levels in the tank; gasoline expands and contacts considerably with changes in temperature, and this must be accounted for. The system should not set off the alarm just because the gasoline cooled off and contracted, thereby lowering the float. None of this would be particularly difficult, except for the problem of cost that often arises in the context of embedded systems.

Cost

A gas station owner buys one of these systems only because some government agency tells him he has to. Therefore, he wants it to be as inexpensive as possible. Therefore, the system will be built with an extremely inexpensive microcontroller, probably one that barely knows how to add 8-bit numbers much less how to use the coefficient of expansion of gasoline in any efficient way.
Therefore, the microprocessor in this system will find itself extraordinarily busy just calculating how much gasoline there really is down there; that calculation will turn into a processor hog.

Nuclear Reactor Monitor

Last, one very simple example from which we can learn a surprising amount is a hypothetical system that controls a nuclear reactor. Our hypothetical system must do many things, but the only aspect that will interest us is the part of the code that monitors two temperatures, which are always supposed to be equal.

Typical Hardware

First, all of the systems need a microprocessor. The kinds of microprocessors used in embedded systems are quite varied.
An embedded system needs memory for two purposes: to store its program and to store its data. Unlike a desktop system, in which programs and data are stored in the same memory, embedded systems use different memories for each of the two different purposes. Because the typical embedded system does not have a hard disk drive from which to load its program, the program must be stored in the memory, even when the power is turned off. As you are no doubt aware, the memory in a desktop system forgets everything when the power is turned off. The embedded system needs special kinds of memory that will remember the program, even with no power. Unfortunately, these special memories are not very suitable for data; therefore, embedded systems need some regular memory for that.
After a processor and memory, embedded systems are more noted for what they do not have than for what they do. Most embedded systems do not have the following:

A keyboard. Some systems may have a few push buttons for user input; some- Telegraph, for example—do not have even that.
A screen. Many systems, especially in consumer products, will have a liquid crystal display with two or three dozen characters. A laser printer, for example, commonly has a two-line status display with 10 or 12 characters on each line.
Other systems do not even have this much output capability. Some may just have a few light-emitting diodes to indicate certain basic system functions.
A disk drive. The program is stored in the memory, and most embedded systems do not need to store much data on a permanent basis. Those that do typically use various kinds of specialized memory devices rather than disk drives.
Compact discs, speakers, microphones , diskettes, modems. Most embedded systems have no need for any of these items.

What embedded systems very often do have are a standard serial port, a network interface, and hardware to interact with sensors and actuators on equipment that the system is controlling.