Application-defined hardware/software tradeoffs mark the difference between success
and failure
Scott Rosenthal
November, 1991
Although all embedded-design projects require you to meld hardware and software
requirements, many people still tend to treat them as separate entities that never
interact. Unfortunately, this attitude is particularly prevalent in some trade
publications that continually run articles and editorials espousing one discipline versus
another without any consideration for the engineer's ultimate goal---creating a design
that's acceptable to the customer. No matter how elegant the software is or how
state-of-the-art the hardware is, the software and the tradeoffs you can (indeed, must)
make between the two in order to create an application useful to the customer.
Getting off on the right foot
How can you translate application requirements into engineering tradeoffs so that you
don't condemn a design to either commercial or technological failure? The first step is to
put off detailed conversations about bits and bytes of hardware and software
implementations until everyone on the design team fully understands the customer's needs.
To repeat, the basic goal is to work with a customer to create equipment that fills his
needs. For example, a client came to me for the design of a new type of optical instrument
called a confocal microscope. It differs from the microscopes found in high-school biology
labs in that it illuminates the subject with a scanning laser beam and synchronizes light
detection to electronically display an image on a CRT. Although we were certain we knew
what the customer wanted, we nonetheless wrote a document describing a proposed design
before starting any development work.
This proposal detailed the design in an easily readable form so that even our
nontechnical customer could understand it. After a brief review, he returned it with the
desired changes to our original design marked in red. We modified the design, resubmitted
it and again it came back. We repeated this process eleven times before everyone was
satisfied with the proposal. Once completed, however, this document became the final
authority for all questions regarding functionality of what the customer wanted. Although
your development organization might not bring you into contact with an end user, you still
aren't off the hook for ensuring clear communications and complete functional
descriptions. An in-house development staff still has a customer in the form of the
marketing department that's going to sell the products, the manufacturing group that's
going to build it and the customer-support staff.
The reason I’m devoting so much time to this nontechnical concept is that I've
seen more embedded designs fail due to inadequate communication than inadequate technical
expertise. In the case of the microscope, the customer was patient enough to go through
the process to ensure we got the design right. Such isn't always the case. Some customers
are under pressures that make that repetitive process impractical. To see what I mean,
consider a situation when a client wanted a design for an antenna-position readout system.
The antenna's center axis incorporated a potentiometer we could use for detecting antenna
position, so our design proposal consisted of an A/D, stable references and large numeric
displays all topped off with a microcomputer-based controller. We presented this
magnificent concept to the customer who calmly said, "Why can't we instead just use a
voltmeter and the proper scaling voltage?" We pursued elegance whereas the customer
sought practicality---with the result that we didn't get the job.
Making tradeoffs
Once you've finalized a design you’re ready to address two issues that, in my mind
are inseparable. In an embedded system, hardware and software can't exist without each
other. Note that when I speak of hardware I don't mean just the computer and its memory
but also include all system I/O. To simplify later software development, I always try to
design hardware so that all I/O functions appear to the computer as switches. In
particular, I eliminate most if not all logic feedback loops because the best place for
that kind of hardware is in the software! By taking this general approach, you can modify
the product's design with only a software change. Consider a cardiac-surgery continuous
blood-gas analyzer I designed. Over a 3- year development effort the software underwent 49
major changes that caused the program size to triple, but the only hardware change I ever
made was to add one wire. Even that hardware patch was time consuming compared to swapping
out ROM. Just imagine the expense if we had to change even more hardware.
The decision between implementing a function in hardware or software is usually a
tradeoff between expense and complexity. For example, the nearby figure shows two
different ways to scan a keypad. The inexpensive approach in (a) requires a fair amount of
processor overhead to scan the keypad and detect a keypress. Another way to accomplish the
same task is with a keypad decoder chip (b). Both methods work, but one is less expensive
while the second requires fewer CPU resources. Which one is better depends on design
constraints. If you've got the room and money, the keypad controller works nicely and
removes considerable overhead from the processor. On the other hand, if you've got CPU
time to burn or have space or money restrictions, the software scanner is the option of
choice. Let the design dictate what it needs rather than trying to make all your designs
fit into a standard mold. For what it's worth, in nine out of ten of my designs that
require a keypad I've used the scanner chip because the CPU is usually quite busy.
Note that the goal mentioned earlier of trying to design I/O hardware so that it
appears as a switch also facilitates debugging. Hardware checkout is easier because it's
either on or off, so all you need worry about is whether simple I/O devices such as LEDs
and relays are operating correctly---a much easier task compared to checking out a design
in which the computer sets a bit and starts a process running independent of the CPU.
Moving external processes into software reduces the unit cost while increasing the
nonrecurring software-development expense.
Be sure to embed hardware functionality as software drivers rather than in-line code.
Using them, all access to the remaining hardware goes through a known path, and any
necessary changes can occur in one place in the software. A simple example is a relay
control bit that closes some relay contacts when you set the bit to One. Unless
you’re using a relay with mercury-wetted contacts, its contacts don't just
close---they first bounce a few times before they stay closed. Unfortunately, these
bounces can appear to digital circuitry as individual switch closings and disturb other
parts of a system. One way to compensate for this effect is to program in a time delay.
Every time you switch the relay, the program counts down for a contact bounces time to die
down. If a particular type of relay bounces more than expected, a relay driver lets you
change the delay time for the entire product in one place. If you used in-line code, how
many places would you have to change?
The bottom line is that you'll always have to make tradeoffs, but in doing so consider
more than just the immediate technical aspects. Consider the decision from a global
viewpoint, a system viewpoint.PE&IN
Adapted from an article that appeared in Personal Engineering & Instrumentation
News.
Return to the article index.
|
