SLTF Consulting
Technology with Business Sense

 Home | Bio | Contact Us | Site Map


 

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


 


About Us | What We Do | SSM | MiCOS | Search | Designs | Articles

Copyright © 1998-2014 SLTF Consulting, a division of SLTF Marine LLC. All rights reserved.