Embedded Systems Design - August 2008 - (Page 46)

0808esd.p45to48 7/17/08 12:01 PM Page 46 break points cus 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 deﬁnes 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 deciSOFTWARE This is not a skeleton of the ﬁnal code, sions will be made as a rePROTOTYPES waiting to be ﬂeshed out after sult of the prototype. If the We’re paid to develop ﬁrmware that is management puts in their two cents. I’m user interface will be pretty much constant no matter correct—or at least talking about truly disposable code. what turns up in the modcorrect enough—to eling phase, jump into ﬁnal form a ﬁnal product, product development. If you know the run a cable from the sneaker to a deﬁrst time, every time. We’re the highanswer, don’t ask the question. velopment system so I could change tech civil engineers, though at least Deﬁne the deadline. Get a protothe LED’s parameters in seconds we have the luxury of ﬁxing mistakes type up and running at warp speed. while the MBAs argue over the corin our creations before releasing the Six months or a year of ﬁddling rect settings. product to the cruel world of users. around on a model is simply too long. Although we’re supposed to build The raison d’être for the prototype is GROUND RULES the system right the ﬁrst time, we’re to identify problems and make Any prototype will fail unless the caught in a struggle between the changes. Get these decisions made goals are clearly spelled out. computer’s need for perfect instrucearly by producing something in days The best prototype spec is one tions, and marketing’s less than clear or weeks. Develop a schedule with that models risk factors in the ﬁnal product deﬁnitions. The B-schools many milestones where non-developproduct. Risk comes in far too many are woefully deﬁcient in teaching ers get a chance to look at the product ﬂavors: user interface (human intertheir students—the future product action with the unit, response speed), and ﬁddle with it a bit. deﬁners—about the harsh realities of development problems (tools, code working in today’s technological enTHE CODE speed, code size, people skill sets), vironment. Vague hand waving and The goal of a prototype is to resolve “science” issues (algorithms, data rewhite-board sketches are not a produnknowns, not to build a ﬁnal prodduction, sampling intervals), ﬁnal uct spec. They need to understand uct. Yet when the boss sees something system cost (some complex sum of that developers must be unfailingly working he’s inclined to ship. A hardprecise and complete in designing the engineering and manufacturing ware prototype looks ugly; there are a costs), time to market, and probably code. Without a clear spec, the engizillion green wires all over the PCB. other items as well. neers, by default, will create the spec. Those green wires are also in the softA prototype may not be the apMost of us have heard the “but ware version but just aren’t visible. propriate vehicle for dealing with all that’s not what I wanted” response “Working” doesn’t mean maintainrisk factors. For example, without from management when we demo able, reliable, or even tested, so it’s wise building the real system it’ll be tough our latest creation. All too often the to create a prototype that might work, to extrapolate code speed and size customer—management, your boss, but that isn’t shippable. So I’m infrom any prototype. or the end user—doesn’t really know clined to eschew C and use really high The ﬁrst ground rule is to deﬁne what he wants until he sees a working level “languages” like Visual Basic. Or the result you’re looking for. Is it to system. The solution is a prototype of the perfect a data-reduction algorithm? To Excel macros. The goal is to get something going now. Use every tool, no get consensus on a user interface? Fosystem’s software, running a minimal Besides, who wants to redo a project? Most of us love the challenge of making something work but want to move on to bigger and better things, not repeat our earlier efforts. Hardware now suffers from the same ills. Reprogrammable logic means the hardware is nothing more than software. Slap some smart chips on the board and build the ﬁrst production run. You can (hopefully) tune the HDL to make the system work despite major logic errors. subset of the application’s functionality. This is not a skeleton of the ﬁnal code, waiting to be ﬂeshed out after management puts in their two cents. I’m talking about truly disposable code. Most embedded systems do posses some sort of look and feel, despite the absence of a GUI. Even the lightup sneakers kids wear 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 46 AUGUST 2008 | embedded systems design | www.embedded.com http://www.embedded.com

Table of Contents Feed for the Digital Edition of Embedded Systems Design - August 2008

Embedded Systems Design - August 2008 Contents Number Include Parity Bit Programmer's Toolbox Cover Feature: Virtualization for Embedded X86 Multiprocessor Applications Wanted: Industry Standards for Benchmarking Embedded VMM Hypervisors Achieving Cache Coherence in a MIPS32 Multicore Design Memory Allocation in C Advertising Index Break Points Marketplace

Embedded Systems Design - August 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.