The Art of Designing Embedded Systems
ISBN: 0750698691
Buy this book at fatbrain.com
With all the furor over VxWorks and Hard Hat Linux and Windows CE, and ARM vs. Motorola, sometimes we forget that an embedded system is, well, an embedded system. Yes, its important to pick the right operating system and display drivers, and its vital to know how to code effectively and ensure that there arent any memory leaks. But the best code in the world wont help you if the hardwares not stable because the watchdog timer circuits arent properly configured. Integrated development environments are good. So are X-Acto knives and oscilloscopes. Helping enterprise developersand development managersremember that embedded systems are a balance of properly built software and hardware is Jack Ganssle, a successful entrepreneur and founder of The Ganssle Group (www.ganssle.com), which consults and trains. Hes also familiar as a long-standing columnist in CMP Media Inc.s Embedded Systems Programming magazine. Ganssles mission: help get products to market faster. Reprinted with permission of SDTimes. Originally appeared in Issue 15, October 1, 2000. Dont Forget the Oscilloscope!
by Alan Zeichick
That might be the theme of The Art of Designing Embedded Systems, but Ganssle takes a direction that I find refreshing. Rather than presenting a one-size-fits-all methodologya Ganssle Unified Processhe shares anecdote after anecdote, suggestion after suggestion. Hes not telling design teams to change their strategies. He just refines them, and throws in a few more tactics along the way, with a conversational style that makes you think youre chatting away at a conference, rather than reading a book about electronics. Well, perhaps its too chattyone might even call it rambling. But this is the distillation of years of experience, not an academic textbook, and its clear that Ganssle has a lot to say, and is going to say it in his own way.
Ganssle starts out with what he calls the seduction of the keyboard. Systems cant be consistently designed, built and delivered on schedule by cranking code. There needs to be planning, a process, communication. He preaches the gospel of the CMM, the Capability Maturity Model developed by Carnegie Mellons Software Engineering Institute (www.sei.cmu.edu/cmm/cmms/cmms.html), and prods managers to realistically assess where their development teams fall on this one-to-five scale, and to aggressively seek to improve their standing.
How do you do that? With Ganssles seven-step plan: Buy and use a version control system for both source code and tools; institute a firmware standards manual; use code inspections; create a quiet work environment; measure defect rates; measure code production rates; and continuously study and look for ways to improve software engineering.
And all that in the first 34 pages. As mentioned before, Ganssle has a lot to say. For example, he takes pains to remind everyone that projects dont scale linearly. With a one-man-year project, a developer can produce 439 lines of code per month; on a 1,000-man-year project, productivity drops to 55 lines of code per developer per month. One solution: Partition huge projects logically into many smaller projects. Another: Develop firmware incrementally.
In the fourth chapter, Ganssle moves into the murky world of real time, with a lengthy exposition on the best ways to make applications adhere to their schedules. Interrupts, polling, vectoring: Ganssle has opinions on different approaches, and in particular on the development and testing of ISRs. Poorly coded interrupt service routines are the bane of our industry, he says, along with inappropriate use of processors external interrupt sources.
There are suggestions galore on what to do about it, including adding inexpensive hardware to handle interrupts so that the main processor wont need to. Another is to be careful when writing interrupt handlers in high-level languages. Modern C and C++ compilers are poorly implemented in that they give us no feedback about the real-time nature of the code theyre producing, he cries, before offering pages of suggestions for coding, debugging and testing real-time code.
The art of debugging is a constant thread running through The Art of Designing Embedded Systems. As Ganssle moves into the next portion of the book, he begins focusing on hardware, and in particular on creating debuggable designs. For example, he talks about the problems caused by pull-down resistors, which although legitimate, make hardware designs difficult to debug with ROM emulators and other tools. Dont use em, he says. And while youre at it, pay special attention to the processors specifications for clock voltages and reset timing requirements. A system designed to the wrong specifications might work sometimes and be hard to debug when it malfunctions.
Ganssle doesnt overlook the basics, eithereven a topic as mundane as designing printed circuit boards earns a discussion. Design for mistakes, he says: Make extra holes in the board, and make sure theyre large enough to act as wiring channels. Add pads of extra chips and socket the chips, even if it adds cost. Stack sockets to make it easier to lift pins, so that you can lift the pin on the second socket rather than damage the chip. If designing with surface-mount technology, leave the tracks on the outer layer, rather than inside, to make it easier to cut them with an X-Acto knife.
Ganssles background includes starting and running several companies devoted to making embedded troubleshooting tools, and he leverages this knowledge in a chapter on emulators, ROM monitors and oscilloscopes. The goal of any debugging tool, he reminds us, is to provide visibility into a system. If you cant see whats going on, you cant find the problem. If your tool doesnt provide the visibility you need, its worthless. Its natural that Ganssle will advocate that embedded developers buy and use good-quality toolsthat, after all, is his backgroundbut hes right.
This book is equally valuable for someone looking for a higher-level understanding of the process of building reliable embedded systems, and the steps that can be taken to deliver them on time and on budget. Managers will benefit from reading this book; when teams get into trouble, Ganssle provides plenty of Have you tried this? fodder for brainstorming. But equally important, his suggestions can help nearly any development organization improve its efficiency and productivityand its the managers, after all, who are in the position to move their departments up the CMM ladder, invest in tools and training, and enforce quality standards and style.
"Hard work never killed anybody, but why take a chance?" - Charlie McCarthy (Edgar Bergen) |