Page 233 - The Art of Designing Embedded Systems

220 THE ART OF DESIGNING EMBEDDED SYSTEMS

Compilers et a/.
Leave all compiler, assembler, and linker warnings and error mes-
sages enabled. The module is unacceptable until it compiles cleanly, with
no errors or warning messages. In the future a warning may puzzle a pro-
grammer, wasting time as he attempts to decide if it’s important.
Write all C code to the ANSI standard. Never use vendor-defined
extensions, which create problems when changing compilers.
Never, ever, change the language’s syntax or specification via macro
substitutions.

Debugging

You have a choice: plan for bugs before writing the code, and build a
debuggable product, or (surprise!) find bugs during test in a system that is
impossible or difficult to troubleshoot. Expect bugs, and be bug-proactive
in your design.
If at all possible, in all systems with a parts cost over a handful of dol-
lars, allocate at least two, preferably more, parallel YO bits to trouble-
shooting. Use these bits to measure ISR time (set one high on ISR entry
and low on exit; measure time high on a scope), time consumed by other
functions, idle time, and even entry/exit to functions.
If possible, include a spare serial port in the design. Then add a mon-
itor-preferably a commercial product, but at least a low-level monitor
that gives you some access to your code and hardware.
Debugging tools are notoriously problematic-unreliable, buggy,
with long repair times. As CPU speeds increase the problems increase. Yet
these tools are indispensable. Select a dual, complementary, debugging
toolchain: perhaps an emulator and a monitor. Or an emulator and a back-
ground debugger. Be sure that both sets of tools use a common GUI. This
will minimize the time needed to switch between tools, and will insure
there will be no file conversion problems (debuggers use many hundreds
of incompatible debug file formats).
When selecting tools, evaluate the following items:
Support-is the vendor responsive and knowledgeable? Is the ven-
dor likely to be around in a few months or years? If the unit fails,
what is the guaranteed repair time?
Intrusion-how much does the tool intrude on the system’s oper-
ation? What is the impact on debugging strategies and develop-
ment time?