Page 148 - The Art of Designing Embedded Systems

Troubleshooting Tools 135

and pastes a repair . . . and then forgets to document it, dooming himself or
some other poor soul to troubleshooting the same symptom all over again.
Above all, don’t plunge into the troubleshooting madness too
quickly. Debugging some embedded projects can take months. Invest time
up front to organize your workbench, acquire the tools, and learn to use
them effectively.
Who built the first lathe? The first oscilloscope? It’s hard to conceive
how these pioneers bootstrapped their efforts, somehow breaking the cycle
of needing equipment X to produce equipment X. Though this surely
proves that modem tools are dispensable, only a fool would wish to repeat
the designers’ Herculean efforts.
Select and buy a tool for one reason only: to save time! Since this is
a rapidly evolving field, expect to continuously invest in new equipment
that keeps you maximally productive. Surely no one would advocate using
286 computers in a Pentium world, yet far too many companies sentence
their engineers to hard labor by refusing to upgrade scopes, compilers, and
emulators when advancing technology obsoletes the old.
Every bookstore is crammed with volumes of sage advice for getting
more from each hour. Never forget that the fundamental rule of time man-
agement is to work smart; in the computer business, delegate as much as
possible to your electronic servants that cost so little compared to an engi-
neer’s salary.
Debuggers-of every ilk-do one fundamental thing: provide visi-
bility into your system. Features vary, but all we ask of a debugger is, “Tell
me what is going on.” Sometimes we’re interested in procedural flow (sin-
gle-stepping, breakpointing); other times it’s function timing or depen-
dencies or memory allocation. Regardless, we simply expect our tools to
reveal hidden system behavior. Only after we see what’s going on can we
use our brains to understand “why that happened,” and then apply a fix.
Before talking about specific tools, let’s look at the features we’d like
to see in any sort of debugger (see Figure 7-l), and only then see how the
tools match feature requirements.
Source-level debugging-If you write in C, debug in C. There is no
more important feature than an environment that lets you debug in the
same context in which you originally wrote the code. If the debugging
tools won’t automatically call up the appropriate source files showing
where the current program counter lies, then count on long, painful days of
despair trying to make things work.
Tools, after all, are the intelligent assistants that provide us a level of
abstraction between the awful bits and bytes the computer uses and our code.
The source-level debugger is the critical ingredient that connects us to the