Michael Barr - Programming Embedded Systems in C and C++

Figure 1-1. A generic embedded system

With the exception of these few common features, the rest of the embedded hardware is usually unique. This variation is the result of many competing design criteria. Each system must meet a completely different set of requirements, any or all of which can affect the compromises and tradeoffs made during the development of the product. For example, if the system must have a production cost of less than $10, then other things — like processing power and system reliability — might need to be sacrificed in order to meet that goal.

Of course, production cost is only one of the possible constraints under which embedded hardware designers work. Other common design requirements include the following:

The amount of processing power necessary to get the job done. A common way to compare processing power is the MIPS (millions of instructions per second) rating. If two processors have ratings of 25 MIPS and 40 MIPS, the latter is said to be the more powerful of the two. However, other important features of the processor need to be considered. One of these is the register width, which typically ranges from 8 to 64 bits. Today's general-purpose computers use 32– and 64-bit processors exclusively, but embedded systems are still commonly built with older and less costly 8– and 16-bit processors.

The amount of memory (ROM and RAM) required to hold the executable software and the data it manipulates. Here the hardware designer must usually make his best estimate up front and be prepared to increase or decrease the actual amount as the software is being developed. The amount of memory required can also affect the processor selection. In general, the register width of a processor establishes the upper limit of the amount of memory it can access (e.g., an 8-bit address register can select one of only 256 unique memory locations). [1] Of course, the smaller the register width, the more likely it is that the processor employs tricks like multiple address spaces to support more memory. A few hundred bytes just isn't enough to do much of anything. Several thousand bytes is a more likely minimum, even for an 8-bit processor.

The cost of the hardware and software design processes. This is a fixed, one-time cost, so it might be that money is no object (usually for high-volume products) or that this is the only accurate measure of system cost (in the case of a small number of units produced).

The tradeoff between production cost and development cost is affected most by the number of units expected to be produced and sold. For example, it is usually undesirable to develop your own custom hardware components for a low-volume product.

How long must the system continue to function (on average)? A month, a year, or a decade? This affects all sorts of design decisions from the selection of hardware components to how much the system may cost to develop and produce.

How reliable must the final product be? If it is a children's toy, it doesn't always have to work right, but if it's a part of a space shuttle or a car, it had sure better do what it is supposed to each and every time.

In addition to these general requirements, there are the detailed functional requirements of the system itself. These are the things that give the embedded system its unique identity as a microwave oven, pacemaker, or pager.

Table 1-1 illustrates the range of possible values for each of the previous design requirements. These are only estimates and should not be taken too seriously. In some cases, two or more of the criteria are linked. For example, increases in processing power could lead to increased production costs. Conversely, we might imagine that the same increase in processing power would have the effect of decreasing the development costs — by reducing the complexity of the hardware and software design. So the values in a particular column do not necessarily go together.

Table 1-1. Common Design Requirements for Embedded Systems

In order to simultaneously demonstrate the variation from one embedded system to the next and the possible effects of these design requirements on the hardware, I will now take some time to describe three embedded systems in some detail. My goal is to put you in the system designer's shoes for a few moments before beginning to narrow our discussion to embedded software development.

At the end of the evolutionary path that began with sundials, water clocks, and hourglasses is the digital watch. Among its many features are the presentation of the date and time (usually to the nearest second), the measurement of the length of an event to the nearest hundredth of a second, and the generation of an annoying little sound at the beginning of each hour. As it turns out, these are very simple tasks that do not require very much processing power or memory. In fact, the only reason to employ a processor at all is to support a range of models and features from a single hardware design.

The typical digital watch contains a simple, inexpensive 8-bit processor. Because such small processors cannot address very much memory, this type of processor usually contains its own on-chip ROM. And, if there are sufficient registers available, this application may not require any RAM at all. In fact, all of the electronics-processor, memory, counters and real-time clocks — are likely to be stored in a single chip. The only other hardware elements of the watch are the inputs (buttons) and outputs (LCD and speaker).

The watch designer's goal is to create a reasonably reliable product that has an extraordinarily low production cost. If, after production, some watches are found to keep more reliable time than most, they can be sold under a brand name with a higher markup. Otherwise, a profit can still be made by selling the watch through a discount sales channel. For lower-cost versions, the stopwatch buttons or speaker could be eliminated. This would limit the functionality of the watch but might not even require any software changes. And, of course, the cost of all this development effort may be fairly high, since it will be amortized over hundreds of thousands or even millions of watch sales.

When you pull the Nintendo-64 or Sony Playstation out from your entertainment center, you are preparing to use an embedded system. In some cases, these machines are more powerful than the comparable generation of personal computers. Yet video game players for the home market are relatively inexpensive compared to personal computers. It is the competing requirements of high processing power and low production cost that keep video game designers awake at night (and their children well-fed).

The companies that produce video game players don't usually care how much it costs to develop the system, so long as the production costs of the resulting product are low-typically around a hundred dollars. They might even encourage their engineers to design custom processors at a development cost of hundreds of thousands of dollars each. So, although there might be a 64-bit processor inside your video game player, it is not necessarily the same type of processor that would be found in a 64-bit personal computer. In all likelihood, the processor is highly specialized for the demands of the video games it is intended to play.