 |
|
Jack Ganssle's The Art of Designing Embedded Systems is a witty summary of embedded systems design and execution as it really looks at ground zero. Ground zero for the typical embedded systems hack is light-years from where you are sitting if you're doing disciplined, methodological team programming of desktop computers, let me tell you.
Better yet, let Ganssle tell you. If you really don't know how different conditions are in the harried, cramped, insular world of embedded design, take heed from Chapter Two:
[Every] shop needs a [version control system]. It is truly magical to be able to rebuild any version of set of firmware, even one many years old.
Embedded-systems programming is typically performed by individuals concerned primarily with either the electronic characteristics of the execution platform (in particular, the I/O circuitry) or the real-world problem domain and its real-time constraints. Computer science is sometimes as distant from embedded systems praxis as the Universal Declaration of Human Rights is from the plight of a political prisoner.
Anyone can crank code or draw logic diagrams. Truly gifted engineers are those who predictably deliver quality products on time, on budget, that meet the specs.
Into the chaos wades Ganssle, veteran of two decades in the field, keyboard in one hand and oscilloscope probe in the other. There he thrives on teaching you the principles of designing to avoid the pitfalls. As much as any one slender, rich, and enjoyable book can illustrate and mitigate the headaches of unreliable prototype hardware, hurried, speculative software, unprovable execution models, uncooperative toolchains, and unappreciative, uninspired management, The Art of Designing Embedded Systems does so.
Management must understand that time costs money -- real money, not just sunk costs. Further, crummy development environments never yield faster product introductions...This is not a Dilbert-like rant against managers...
Reading this book is both a pleasurable and painful experience. Pleasurable, because Ganssle spots the critical hangups that so often plague the project and offers at each juncture several eminently practical suggestions. Painful, because it conjures up memories of the open PC chassis wired into the analog hardware running under the BIOS writing in the FORTH inline assembler with the boss leaning over my shoulder asking every five minutes if it's done.
When I was a young technician, my associates and I arrogantly believed we could build anything with enough 10K resistors and duct tape. Now it seems that even simple electronic toys use several million transistors...
Things have changed since that time; not the boss, who still leans over your shoulder every five minutes asking if it's done; it's the tools that have changed. It's now possible to code yourself inextricably into a corner of undebuggability and impending doom much faster than you could in the 1980s. Ganssle is there, right on the mark, and up to date on C/C++ toolchains and the spectrum of RTOS available.
If you're not using an RTOS in your embedded designs today, you surely will be tomorrow. Get familiar with the concepts, as designing tasking code requires a somewhat different view -- the time domain view -- than conventional procedural programming.
Products are noted but it's not a product review. Ganssle's advice applies to 8051 assembler as surely as to PC-on-chip C/C++.
Similarly, if the CPU has a BDM or JTAG debugging interface, put a BDM/JTAG connector on the PCB, even if you're using the very best emulators. For almost zero cost you may save the project when/if the ICE gives [you] trouble.
The text springs lightly from the elevated and general to the hard-core and practical while avoiding the facile. Ganssle isn't culling documentation for you; he's telling you how he and his associates have done it on a deadline when it looked pretty darn hopeless. There's no central theme except getting it done on time and bug-free. There's no ideological slant other than a definite inclination to project success.
The exact parameters are fuzzy...We need to develop a sense of the art. A 68HC16, at 16 MHz, runs so many instructions per second (plus or minus). With this particular compiler you can expect (more or less) this sort of performance under these conditions...
Mention should be made of Ganssle's electronics acumen. That's the aspect of theory embedded-systems designers take seriously. Software engineers may fret over efficient list traversals, but a few picofarads short and the embedded design is toast.
If two signals seem impossibly skewed by 15 nsec on the logic analyzer, make sure this not an artifact of setting it to sample too slowly. When your 100-MHz scope shows a perfectly clean logic level, remember that undetected but virulent strains of 1-nsec glitches can still be running merrily around your circuit.
One of Ganssle's tendencies makes the hairs on the back of my neck stand up -- to wit, his use of suspect productivity statistics.
Barry Boehm found that typically 80% of defects in a program are in 20% of the modules. IBM's numbers showed that 57% of the bugs are in 7% of the modules. Weinberg's numbers are even more compelling: 80% of the defects are in 2% of the modules.
Software productivity metricists strain at gnats and swallow camels. They habitually pull numbers like those quoted by Ganssle out of a very personal dark place. It's as if he is winking surreptitiously at the senior engineer while conjuring up the bogeyman to frighten the junior engineer into applying some self-discipline.
Another cautious criticism of Ganssle's writing is that it leans markedly towards the colloquial. This makes the book entertaining. It also renders this useful volume somewhat difficult for non-U.S. engineers. American tech writers and their editors should be at pains to remember that it's a small world, even if, as Steven Wright points out, you wouldn't want to have to paint it.
Veterans of embedded systems programming like Ganssle are empiricists. They are survivors. If you're at sea in embedded systems and are afraid you'll never feel land under your feet again, rush out and buy this book. It's the "Hitchhiker's Guide" of the trade. Don't panic!
-- Jack Woehr
| Readability |
|
| Originality |
|
| Organization |
|
| Accuracy |
|
| Consistency |
|
| Depth |
|
| Timeliness |
|
| Editing |
|
| Design |
|
| Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.