Page 146 - Embedded Microprocessor Systems Real World Design
P. 146
readings are 50, 150, 48, and 152, you will get the same average. The second set of
numbers, however, may indicate a dangerous oscillation somewhere that will cause
something to burst. When you use averaging, be sure it doesn’t cause your software
to ignore a potential problem.
Hardware Damage
This is a less serious version of the safety issue. An example is control of a direct
current (DC) or stepper motor using an H-bridge. If the software directly controls
all four transistors in a motor H-bridge, it can turn on the wrong pair and destroy
the transistors. Situations like this must be dealt with in embedded systems, either
through hardware protection or careful software design.
Mechanical Delays
In a PC, the operating system takes care of the delay between turning on a disk
spindle motor and waiting for the disk to come up to speed. Similarly, embedded
system software must take into account the fact that mechanical systems are often
much slower than the processor. A real-world example involves AC motors
controlled by two relays. A run relay provides AC for normal operation. For faster
stopping, a second relay provides a momentary pulse of DC to brake the motors.
Relays have a delay of many milliseconds from when voltage is applied to the coil
until the contacts close. There is a similar (usually longer) delay from the time the
coil voltage is removed until the contacts open. So when switching from running
to braking, the software must introduce a delay between turning off the run relay
and turning on the brake relay. Without the delay, the run relay will fail in a quite
spectacular manner, accompanied by blue sparks and smoke. A second delay is
required to inhibit run startup after the brake relay is opened. Since the brahng
relay is a large contactor with an opening time in the tens of milliseconds, the
second delay must be much longer than the first.
Recovery Time
Many peripheral integrated circuits (ICs) have a recovery time. You cannot perform
a read or write cycle until so many clocks have elapsed since the last cycle. Be sure
to check for and abide by these. If you do not, the resulting problems can be inter-
mittent and difficult to find.
€MI
Although EM1 considerations normally are considered a hardware design issue,
there are some areas that software must control. For example, in a system with mul-
tiple softwarecontrolled motors, it may be possible for the software to self-induce
EM1 problems. DC motors have a larger current draw at startup, possibly three times
Software Design 127