Page 38 - Embedded Microprocessor Systems Real World Design

in software? An example of this can be found in the pool timer. As we will see in
the next chapter, the pool timer displays time information on four seven-segment
LED displays. There are display decoder ICs that accept a four-bit input and
produce the signals necessary to drive the display. This design takes a different
approach and drives the display segments directly from a register, which is under
software control. When the software wants to display a number, it must convert the
number to the seven-segment pattern and write that pattern to a register. The
savings was a single IC in the design. This approach also allows the code to display
nonnumeric symbols on the display (A, C, H, J, L, P, U), which I used for debug-
ging the system.
While this decision saved an IC, it had three costs: ROM space was needed for
the lookup table, extra code had to be included for the hex to seven segment con-
version, and the software needed extra time to perform the translation. Given the
simplicity of this function, none of these was a serious problem. The table was 16
bytes long, so the code took a few more bytes and needed only a few microseconds
to execute. But the principle described is at the heart of the software/hardware
tradeoff: The more functions that can be pushed into software, the lower will be
the product cost, up to the point where a faster processor or more memory is
required to implement the added functionality. The pool timer demonstrates
another example of this kind of tradeoff, which we’ll discuss in Chapter 4.
As the saying goes, there is no such thing as a free lunch. Pushing functionality
into the software increases software complexity, development time, and debug
time. This is an NRE, just like the mask ROM charges described earlier. However,
given the increasing speed and power of microprocessors, I expect to see an
ever-increasing trend toward including as much functionality in the software as
possible.
In a more complex system, these tradeoffs can create heated discussion. Should
the software handle regular timer interrupts at a high rate and count them to time
low-rate events, or should an external timer be added that can be programmed to
interrupt the software when it times out? Should the software drive the stepper
motor directly, or should an external stepper controller be used? If the software
drives the motor, should protection logic be included to prevent damage to the
motor drive transistors if the software turns on the wrong pair? And if the proces-
sor runs out of throughput halfway though the project, did the design place too
much of a burden on the software, or did the software engineer write inefficient
code? The answers to these questions depend on your design. If you stay in this
field very long, be prepared to get into one of these discussions.
While doing everything in software increases development costs, moving
functionality to the hardware increases product cost, and these costs are incurred
with every unit built. In a low-cost design, addition of any extra hardware can have
a significant effect on product cost, so the software/hardware tradeoff can be
extremely important. In an extremely cost-sensitive design, such as a low-cost

System Design 23