Page 145 - Embedded Microprocessor Systems Real World Design

be written only for speed or they will not work. Many embedded systems cannot
tolerate a function that just “goes away” for a long time, say, to sort data in a table.
The definition of a “long time” depends on the system, but may range from
seconds down to milliseconds (even microseconds in a DSP-based design).
An embedded system is not a general-purpose computer. There often is no
display to handle errors. There may be no human within miles, so “Hit Any Key
to Continue” generally is not an option. Errors must be handled and often
operation must resume after they occur.
A real-time system handles asynchronous external events. This means that a
switch can be closed at any time and an interrupt can occur between any pair of
instructions. The code must handle all timing combinations without error. (We’ll
discuss this further in Chapter 5.)
There is no nanny to be sure the hardware is in a known state. The embedded
code must initialize everything at power-up. We’ll discuss more about this at the
end of the chapter.

Other considerations include the following.

Safety
If the code in a PC goes “off into the weeds,” the disk-drive spindle motor cannot
reach out and grab the user’s tie. In some real-time systems, an unsafe scenario is
a real possibility. When in doubt, makz it safe. Turn the motors off. Shut down the
high voltage.
Another safety issue has to do with limits. There have been numerous accidents
in which a software-controlled system gave bad information to the operator because
the software engineer assumed that everything would remain in “normal” condi-
tions. For example, if you have a sensor that measures temperature in a vat of water,
you know that the water temperature can’t ever be higher than IOO’C, right? But
what happens if the water all boils away or someone seals up a pipe and makes the
vat into a pressure cooker? In any safety-related system, it is always risky to give the
operator or other subsystems false information. It is safer to either give the opera-
tor the right temperature or indicate that the temperature reading is suspect. Any
time that you have a safety-related input to an analog-to-digital converter (ADC)
and the ADC is saturated at one end or the other, it should be indicated in some
way. In our temperature example, if a saturated ADC output indicates that the
temperature is 120°C, don’t just indicate the temperature. Indicate the tempera-
ture and make it flash or light a light or do something to tell the operator that the
temperature is not only high, but probably off-scale.
A common way to eliminate noise on analog inputs is to average several samples.
This does a good job of eliminating noise, but it can also mask problems. If you
have a pressure sensor with a normal reading of 100, you might average readings
of 95, 105, 98, and 102 to get a reasonable result. On the other hand, if the

126 Embedded Microprocessor Systems