Page 118 - The Art of Designing Embedded Systems

Firmware Musings 105

Even hardware is moving away from conventional prototypes. Re-
programmable logic means that the hardware is nothing more than soft-
ware. Slap some smart chips on the board and build the first production
run. You can (hopefully) tune the equations to make the system work de-
spite interconnect problems.
We‘re paid to develop firmware that is correct-r at least correct
enough-to form a final product, first time, every time. We’re the high-
tech civil engineers, though at least we have the luxury of fixing mistakes
in our creations before releasing the product to the cruel world of users.
Though we’re supposed to build the system right the first time. we’re
caught in a struggle between the computer‘s need for perfect instructions.
and marketing’s less-than-clear product definitions. The B-schools are
woefully deficient in teaching their students-the future product defin-
ers-about the harsh realities of working in today’s technological envi-
ronment. Vague handwaving and whiteboard sketches are not a product
spec. They need to understand that programmers must be unfailingly pre-
cise and complete in designing the code. Without a clear spec, the pro-
grammers themselves, by default. must create the spec.
Most of us have heard the “but that’s not what I wanted’ response
from management when we demo our latest creation. All too often the cus-
tomer-management, your boss. or the end user-doesn‘t really know
what they want until they see a working system. It’s clearly a Catch-22
situation.
The solution is a prototype of the system’s software. running a min-
imal subset of the application’s functionality. This is not a skeleton of the
final code, waiting to be fleshed out after management puts in their two
cents. I’m talking about truly disposable code.
Most embedded systems do possess some sort of look and feel,
despite the absence of a GUI. Even the light-up sneakers kids wear (which,
I‘m told, use a microcontroller from Microchip) have at least a “look.”
How long should the light be on? Is it a function of acceleration? If I were
designing such a product, I’d run a cable from the sneaker to a develop-
ment system so I could change the LED’s parameters in seconds while the
MBAs argue over the correct settings.
“Wait,” you say. “We can’t do that here! We nlwzy ship our code!”
Though this is the norm, I’m running into more and more embedded de-
velopers who have been so badly burned by inadequate/incorrect specifi-
cations that even management grudgingly backs up their rapid prototyping
efforts. However, any prototype will fail unless the goals are clearly
spelled out.