Page 119 - The Art of Designing Embedded Systems

106 THE ART OF DESIGNING EMBEDDED SYSTEMS

The best prototype spec is one that models risk factors in the final
product. Risk comes in far too many flavors: user interface (human inter-
action with the unit, response speed), development problems (tools, code
speed, code size, people skill sets), “science” issues (algorithms, data re-
duction, sampling intervals), final system cost (some complex sum of en-
gineering and manufacturing costs), time to market, and probably other
items as well.
A prototype may not be the appropriate vehicle for dealing with all
risk factors. For example, without building the real system it’ll be tough to
extrapolate code speed and size from any prototype.
The first ground rule is to define the result you’re looking for. Is it to
perfect a data reduction algorithm? To get consensus on a user interface?
Focus with unerring intensity on just that result. Ignore all side issues.
Build just enough code to get the desired result. Real systems need a spec
that defines what the product does; a rapid prototype needs a spec that
spells out what won’t be in it.
More than anything you need a boss who shields you from creeping
featurism. We know that a changing spec is the bane of real systems;
surely it’s even more of a problem in a quick-turn model system.
Then you’ll need an understanding of what decisions will be made as
a result of the prototype. If the user interface will be pretty much constant
no matter what turns up in the modeling phase, hey-just jump into final
product development. If you know the answer, don’t ask the question!
Define the deadline. Get a prototype up and running at warp speed.
Six months or a year of fiddling around on a model is simply too long. The
raison d’ztre for the prototype is to identify problems and make changes.
Get these decisions made early by producing something in days or weeks.
Develop a schedule with many milestones where nondevelopers get a
chance to look at the product and fiddle with it a bit.
For a prototype where speed and code size are not a problem, I like
to use really high-level “languages” like Basic. Excel. Word macros. The
goal is to get something going now. Use every tool, no matter how much
it offends your sensibilities, to accomplish that mission.
Does your product have a GUI? Maybe a control panel? Look at
products like those available from National Instruments and IoTech. These
companies provide software that lets you produce “virtual instruments” by
clicking and dragging knobs, displays, and switches around on a PC’s
screen. Couple that to standard data acquisition boards and a bit of code in
Basic or C, and you can produce models of many sorts of embedded sys-
tems in hours.