Embedded Systems Design - August 2008 - (Page 48)

0808esd.p45to48 7/17/08 12:01 PM Page 48 break points cus on the real issues—the ones iden- Others are really quite good but simmatter how much it offends your sentiﬁed in your prototyping goals—and ply lack the ability to deal with detail, sibilities, to accomplish that mission. which is essential since, in a released not the problems of creating docuSpreadsheets are wonderful tools product, every lousy bit must be right. mented, portable, well-structured for evaluating the product’s science. These are the ideal prototype desoftware. The code will be no more Unsure about the behavior of a datavelopers. Bugs aren’t a big issue in a than the means to the end. You’ll toss smoothing algorithm? Fiddling with a model, and documentation is less than the code as casually as the hardware fuzzy-logic design? Wondering how important. The prototype lets them much precision to carry? Create a data folks toss prototype PC boards. Though the PC is a great platform exercise their creative zeal, while it’s set and put it in your trusty spreadlimited scope means problems are not for modeling, do consider using cursheet. Change the math in seconds; important. Toss Twinkies and caffeine rent company products as prototype graph the results to see what happens. platforms. Often new products are de- into their lair and stand back. You’ll Too many developers write a ton of embedded code only to spend months rivatives of older ones. You may have a get your system fast and they’ll be happy employees. Use the more discilot of extant hardware and software in tuning algorithms in the unforgiving plined team members to environment of an get the bugless real prod8051 with limited Another nice feature of doing a model uct to market. memory. Although a of the product is the certainty of STOP THE MADNESS spreadsheet masks creating worthless code. You’ll focus on The agile development the calculations’ the real issues and not the problems of approaches stress the imspeed, you can inportance of getting deed get some sort creating documented, portable, something working fast of ﬁnal complexity well structured software. in order to provoke estimate by examinchange. Show the cusing the equations. If tomer a system to get lots of feedback a system on the shelf. Be creative and the algorithm looks terribly slow, early. There’s a lot of value in employuse every resource available to get the work within the forgiving environing these techniques in prototyping. prototype up and running. ment of the spreadsheet to develop a The NASA system I described Toss out the standards manual. faster approach. We all know, and too smoked due to a bad power supply Use every trick in the book to get it often ignore, that the best performthat took out over 100 ICs. The engidone fast. Do code in small functions ance enhancements come from tunneer, his resignation rejected, through to get something testable quickly and ing the algorithm, not the code. to minimize the possibility of making heroic efforts and countless packs of Does your product have a GUI? cigarettes managed to salvage it, delivMaybe a control panel? Lots of math? big mistakes. ering it almost on time. Hours later Consider using products like MAThe was deep into another high-presPEOPLE LAB or LabVIEW to create a look sure project with another impossible All of us have worked with that creand feel that marketing can evaluate. deadline and too few resources. He Coupled to standard data-acquisition ative genius who can build anything, had kids to feed, so unquestioningly who pounds out a thousand lines of boards and a bit of code, you can produce models of many sorts of em- code a day but can never seem to com- accepted the new assignment. Watching this man’s angst, I plete a project. Worse—the fast coder bedded systems in hours. started to see how pressure can shrivwho spends eons debugging the The cost of creating a model of el a person’s soul. Part of managemegabyte of ﬁrmware he wrote on a your product is tiny compared with ment is effectively using people’s Jolt-driven all-nighter. Then there are designing, building, and troustrengths while mitigating their the folks who produce working code bleshooting real hardware and softweaknesses. Part of it is also giving devoid of documentation, who develware. Although there’s no way to the workers a break once in a while. op rashes or turn into Mr. Hyde when avoid building hardware at some No one cranks out 70-hour weeks told to add comments. point, count on adding months to a We struggle with these folks, plead forever without cracking. Prototypes project when a new board design is are always created under tremendous with them, send them to seminars, required. time pressures. But one must be reallead by example, all too often without Another nice feature of doing a istic and recognize that humans have success. Some of them are prima donmodel of the product is the certainty human limitations. ■ nas who should probably get the ax. of creating worthless code. You’ll fo48 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.