Page 28 - The Art of Designing Embedded Systems
P. 28
Disciplined Development 1 5
Checkpoint Your Tools
An often overlooked characteristic of embedded systems is their as-
tonishing lifetime. It’s not unusual to ship a product for a decade or more.
This implies that you’ve got to be prepared to support old versions of every
product.
As time goes on, though, the tool vendors obsolete their compilers,
linkers, debuggers, and the like. When you suddenly have to change a
product originally built with version 2.0 of the compiler-and now only
version 5.3 is available-what are you going to do? The new version
brings new risks and dangers. At the very least it will inflict a host of un-
knowns on your product. Are there new bugs? A new code generator
means that the real-time performance of the product will surely differ. Per-
haps the compiled code is bigger, so it no longer fits in ROM.
It’s better to simply use the original compiler and linker throughout
the product’s entire lifecycle, so preserve the tools. At the end of a project
check all of the tools into the VCS. It’s cheap insurance.
When I suggested this to a group of engineers at a disk drive com-
pany, the audience cheered! Now that big drives cost virtually nothing,
there’s no reason not to go heavy on the mass storage and save everything.
A lot of vendors provide version control systems. One that’s cheap,
very intuitive, and highly recommended is Microsoft’s Sourcesafe.
The frenetic march of technology creates yet another problem
we’ve largely ignored: today’s media will be unreadable tomorrow.
Save your tools on their distribution CD-ROMs and surely in the not-
too-distant future CD-ROMs will be supplanted by some other, bet-
ter, technology. In time you’ll be unable to find a CD-ROM reader.
The VCS lives on your servers, so it migrates with the advance
of technology. If you’ve been in this field for a while, you’ve tossed
out each generation of unreadable media: can you find a drive that
will read an 8-inch floppy anymore? How about a 160K 5-inch disk?
Step 2: lnstitUfe a Firmware Standards Manual
You can’t write good software without a consistent set of code guide-
lines. Yet, the vast majority of companies have no standards-no written
and enforced baseline rules. A commonly cited reason is the lack of such

