Page 147 - The Art of Designing Embedded Systems

134 THE ART OF DESIGNING EMBEDDED SYSTEMS

This is clearly unacceptable. There are a few solutions:
1. Single-step though all of the code. Keep a listing handy, on
paper, and check off each branch and decision node as you
step through it, running tests until every bit of code has
been executed. The downside of this, of course, is that sin-
gle-stepping destroys the real-time nature of most embed-
ded systems.
2. Construct tests guaranteed to run through every decision
node. This means modifying the test procedure after you’ve
written the firmware to ensure that the tests are robust
enough to run through every node.
3. Buy a fancy tool. Applied Microsystems and HP both make
code coverage tools that identify unexecuted lines of code,
watching system operation in real time. These tools serve as
a complement to option 2, as you’ll still have to construct
appropriate tests. Still, if bugs are unacceptable, then the
fancy tools are probably necessary to ensure quality.

No management techniques or methodologies will ever eliminate the
need for test and debug. The late, great Deming taught the world that it’s
impossible to test quality into a system; quality is a characteristic of the de-
sign, not of our ability to find and fix bugs. Yet no matter how elegant the
design, test is always important, always a crucial validation of the code.

Tools

Your lovingly crafted, finely tuned masterpiece of engineering will
not work. Period. Sometimes it’s a little frightening when we discover the
real scope of our errors in a design. How often have you thought, in a bleak
moment of despair, “I’ll never make this stupid thing work!”
But that’s why we build prototypes. Prototypes are not expected to
work at first. Electronics engineering is perhaps one of the last great areas
where we can and should build test systems that are meant to be thrown
away once their contribution to the design process is done.
Although this is no excuse for doing a sloppy job of design, expect
problems. Develop an engineering strategy that expects problems as part of
the design process, rather as a reaction to (surprise!) a mistake. Set up a
system where you extract every bit of meaning from problems and their
eventual solutions. Don’t be like the engineer who finds a mistake, cuts