Page 120 - The Art of Designing Embedded Systems

Firmware Musings 107

The cost of creating a virtual model of your product, using purchased
components, is immeasurably small compared to that of designing, build-
ing, and troubleshooting real hardware and software. Though there’s no
way to avoid building hardware at some point, count on adding months to
a project when a new board design is required.
Another nice feature of doing a virtual model of the product is the
certainty of creating worthless code. You’ll focus on the real issues-the
ones identified in your prototyping goals-and not the problems of creat-
ing documented, portable, well-structured software. The code will be no
more than the means to the end. You’ll toss the code as casually as the
hardware folks toss prototype PC boards.
I mentioned using Excel. Spreadsheets are wonderful tools for eval-
uating the product’s science. Unsure about the behavior of a data-smooth-
ing algorithm? Fiddling with a fuzzy-logic design? Wondering how much
precision to carry? Create a data set and put it in your trusty spreadsheet.
Change the math in seconds; graph the results to see what happens. Too
many developers write a ton of embedded code, only to spend months tun-
ing algorithms in the unforgiving environment of an 8051 with limited
memory.
Though a spreadsheet masks the calculations’ speed, you can indeed
get some sort of final complexity estimate by examining the equations. If
the algorithm looks terribly slow, work within the forgiving environment
of the spreadsheet to develop a faster approach. We all know, though too
often ignore, the truth that the best performance enhancements come from
tuning the algorithm, not the code.
Though the PC is a great platform for modeling, do consider using
current company products as prototype platforms. Often new products are
derivatives of older ones. You may have a lot of extant hardware and soft-
ware-that works!-in a system on the shelf. Be creative and use every re-
source available to get the prototype up and running.
Toss out the standards manual. Use every trick in the book to get it
done fast. Do code in small functions to get something testable quickly,
and to minimize the possibility of making big mistakes.
There’s a secret benefit to using cruddy “languages” for software
prototypes: write your proto code in Visual Basic, say, and no matter how
hard management screams, it simply cannot be whisked off into the prod-
uct as final code. Clever language selection can break the dysfunctional
last-minute conversion of test code to final firmware.