Embedded Systems Design - June 2008 - (Page 56)

break points the patience and discipline—and time—to create code for a future need? Reuse is like a savings account: there’s no value till you’ve put a lot into the account. The more you invest, the more benefit accrues. When will we be able to buy big chunks of our applications, rather than write them all from scratch? Is REUSE the software IC even possible? Tools that help us write more code The future belongs to people faster are but a part of the solution, brave and clever enough to discard though. Clearly a new model of old modes of thinking and adopt reuse is desperately needed. A prodand create new ideas. We will find uct composed of a million lines of ways to design products using previcode is just too big to be built a line ously-written code. The benefits are at a time, especially when the boss too compelling to continue building wants it shipped today. systems a line at a time. It may mean Barring some fantastic new detossing resources, memory, and velopment in software engineering, high-end CPUs at low-end apps. It the future simply must belong to may mean new tools. reuse. Until we Surely we’ll design sysmanage to beg, Someday each of us, supported by tems differently. borrow, steal, Though some of the or buy huge management, will recognize implementation details chunks of the two critical factors: ﬁrmware is the most are murky today, the code base, we’ll expensive thing in the universe, and outcome is pretty clear. be forever The biggest change doomed to any idiot can write code. will be in our attitudes, writing every our approach to buildlast bloody line ing products. Someday ourselves. each of us, supported by manageSelby found that, when porting old That’s intolerable. ment, will recognize two critical faccode to a new project, if more than Reuse means much more than about 25% gets modified, there’s not tors: firmware is the most expensive hacking up some code we salvaged thing in the universe, and any idiot much of a schedule boost. Reuse from a previous project. It’s more can write code. The future belongs works best when done in the large. than recycling 20% of the firmware. to developers who find better ways The gritty truth is, though, that Million-line-plus systems require exbefore a package is truly reuseable, it to build products, not to supertreme level of reuse. coders. must have been reused at least three But let’s define a few terms to So, to my friend Kirk and all the times. In other words, domain show what reuse is, and what it’s rest of the nonengineering world, we analysis is hard. We’re not smart not. Software salvaging is using code do work under enormous schedulenough to truly understand the again that was never designed for ing pressures. You, the public, dereuse. That is, hacking away at a base range of applications where a chunk mand it. Your digitally stabilized of software may be used. Every doof crummy old source to somehow binoculars, that $100 GPS, the digimain requires its own unique feashoehorn it into a new application. tal camera, and all of the other electures and tweaks; till we’ve actually Carrying-over code is porting tronic products that make up your used the code several times, over a firmware from an old project to a wide enough range of apps, we won’t world all come from engineers new one. Like salvaging, it’s largely a struggling under impossible deadhave generalized it enough to have it matter of heroic source hacking. lines to produce amazingly inexpentruly reuseable. True reuse is building systems a sive and reliable systems. This suggests that reuse is terricomponent at a time, not a line at a Once in a while, when you use bly expensive. We spend money like time. It’s working with big blocks one of these systems, think of us! mad making decent code but don’t that work in well-defined ways, We’re back in the lab, working on reap the benefits till we’ve reused it without digging into the guts to version 2.0. ■ three times. How many of us have tweak, debug or improve. Richard Klocwork, Polyspace, Green Hills, and GrammaTech all push static analyzers that looks for run-time problems. The tools certainly can’t find all bugs, but they offer a schedulecheating weapon that as yet has little market penetration. 56 JUNE 2008 | embedded systems design | www.embedded.com http://www.embedded.com

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

Embedded Systems Design - June 2008 Contents #Include Party Bit Programmer's Toolbox Cover Feature: Virtual Hardware Platforms for Embedded Software Validation Allocating Memory in MATLAB-to-C Code MDD and IDEs: Making the Twain Meet in Embedded Systems Design Avoid a Thrashing Guest Editor Advertising Index Break Points Marketplace

Embedded Systems Design - June 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.