Project Management

The Art of Designing Embedded Systems

Author: Jack G. Ganssle

ISBN: 0750698691

Buy this book at fatbrain.com

 Don’t Forget the Oscilloscope!
by 
Alan Zeichick 

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, it’s important to pick the right operating system and display drivers, and it’s vital to know how to code effectively and ensure that there aren’t any memory leaks. But the best code in the world won’t help you if the hardware’s not stable because the watchdog timer circuits aren’t properly configured. Integrated development environments are good. So are X-Acto knives and oscilloscopes.

Helping enterprise developers—and development managers—remember 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. He’s also familiar as a long-standing columnist in CMP Media Inc.’s Embedded Systems Programming magazine. Ganssle’s mission: help get products to market faster.

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 methodology—a Ganssle Unified Process—he shares anecdote after anecdote, suggestion after suggestion. He’s 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 you’re chatting away at a conference, rather than reading a book about electronics. Well, perhaps it’s too chatty—one might even call it rambling. But this is the distillation of years of experience, not an academic textbook, and it’s 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 can’t 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 Mellon’s 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 Ganssle’s 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 don’t 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 won’t 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 they’re 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. Don’t use ’em, he says. And while you’re at it, pay special attention to the processor’s 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 doesn’t overlook the basics, either—even 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 they’re 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.

Ganssle’s 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 can’t see what’s going on, you can’t find the problem. If your tool doesn’t provide the visibility you need, it’s worthless. It’s natural that Ganssle will advocate that embedded developers buy and use good-quality tools—that, after all, is his background—but he’s 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 productivity—and it’s 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. 

Reprinted with permission of SDTimes.  Originally appeared in Issue 15, October 1, 2000.


ADVERTISEMENTS

"Hard work never killed anybody, but why take a chance?"

- Charlie McCarthy (Edgar Bergen)

ADVERTISEMENT

Sponsors