Those not busy being born . . .Books and more books. What is Jack reading these days?
In a terribly unscientific poll I conducted last year 34% of embedded developers indicated they hadn't read a single book about software engineering in the previous year.1 Twenty percent plowed through just a single volume.
Wow. Tom DeMarco, a prolific author on software topics, complains that software people don't read, a crude generalization that perhaps reflects his angst at an inadequate royalty stream. But there is some truth in his exasperated cry.
The irony is that this field changes faster than perhaps any other. Today's impossible 90nm design node will be tomorrow's bit of obsolete technology. Similarly, agile methods nearly didn't exist a mere decade ago and have evolved with breathtaking speed since then. Developers who don't keep up will be tossed on the technological scrapheap.
Bob Dylan was probably thinking about embedded systems developers when he wrote "those not busy being born are busy dying."2
Last December I wrote about magazines aimed at this business.3 Their short articles are topical and offer quick insight into important issues. But it's impossible to delve into deep and complex subjects in two or three thousand words. All-day and all-week classes, for those with the time, give very valuable deeper understanding of complex issues. But most of us are far too busy to spend many weeks a year in training, so must regularly protect our careers by perusing relevant books. Though too many of these are dry, it's hard to not learn something important from each one.
My stack of as-yet-unread tech books currently measures 3 feet, 2 inches high. I try, with varying success, to get through one volume every two weeks. Here are my thoughts on a few I've read recently.
Everything Jan Axelson has written is brilliant. Most of her books cover communications, including complete works on RS-232, the PC's parallel port, Ethernet/Internet, and USB. A whole book on the parallel port? Egad, the subject hardly seems to merit such in-depth treatment. Yet there's more to parallel communications than one might think, and, as in all of her books, Axelson gives a detailed "how-to" that endears her to any engineer looking for practical solutions today.
USB Complete: Everything You Need to Develop USB Peripherals covers a subject much more complex than parallel communications.4 The paradox of USB is that its simplicity and artlessness for a user means extraordinary complexity for developers.
Here's the short review: if you're doing USB development, buy this book now.
It's not a fun work; you won't be dazzled by ringing Churchillian prose or amused by witty double entendres. USB is hard stuff, which Jan does a crystal clear job of explaining to the willing technical reader. The book starts with a very readable and clear description of the basics of USB communications, then moves on to a dense but important three chapters detailing the standard's different types of transfers. The author makes it clear that one doesn't have to master all of the details of these data exchanges to effectively develop USB devices, but the 107 pages devoted to the subject are not terribly mind-bending and will give an engineer the knowledge needed to interpret data displayed on a protocol analyzer.
Do you need to write a custom device class or will your peripheral mesh into an extant USB class? Let's hope for the latter, but either way, a chapter shows how to make the decision.
Most USB devices connect to a PC, one generally running the inexcusably complex Microsoft Windows. How does Windows handle USB? Need a new device driver? A third of the book is devoted to getting your custom device working with that often-inscrutable operating system. This section assumes you understand programming in the Windows environment, a skill that's just about orthogonal to cranking out traditional embedded code. But listings give the vital how-to that engineers need, both in Visual C++ and in Visual Basic.
The book then switches gears and delves into the peripheral side, which encompasses the embedded part of the application. Using typical USB controller chips you'll see how to build the hardware and software needed to make a working USB application, including dealing with power requirements, testing, and debugging.
The final chapters should have been labeled appendices, as they give complete electrical specifications of the interface. This is just the sort of practical book needed by engineers tasked with building a USB peripheral. Jan's web site, which contains lots of material that supplements her books, is www.lvr.com.
Though we're all familiar with the assert() macro, for good and bad reasons darn few of us use it in any disciplined fashion. Yet assertions are a pretty painless way to catch all sorts of runtime errors that might otherwise cause weeks of debugging.
Design by Contract (a trademark of Eiffel Software) is a programming approach that's like assertions on steroids. DbC assumes that all functions or classes are clients of those that invoke them, and therefore must conform to rules--a contract--that's implicit in the caller/callee relationship. Each class has preconditions that must be satisfied before it is called, postconditions that describe what sorts of results will be returned, and invariants, things that stay unchanged. Preconditions, postconditions, and invariants are guarantees made by the caller and callee.
What makes DbC really powerful, in my opinion, is that these contracts or guarantees are checked at runtime. Any violation throws an exception. It's a different way of programming, since classes must include code snippets that check the contract. For instance, a square root routine's precondition might look like:
require 0 < input
Though this looks a lot like an assertion, some languages (notably Eiffel) have substantial DbC support built-in.
Design by Contract, by Example, by Richard Mitchell and Jim McKim is one of the few tomes around that goes into DbC in detail.5 Though I was excited to start the book because of the novelty and importance of DbC, disappointment quickly set in.
All of the examples are in Eiffel. Two get reworked in Java. Eiffel has 0% market share in the embedded space, with Java managing just about 3%. Since the Java versions are left till the end of the book, unfamiliarity with Eiffel will leave you struggling with language semantics instead of thinking deeply about the ideas behind DbC. The book desperately needs parallel examples in C++, which, admittedly, has no built-in contract support--libraries do exist that correct this shortcoming.
The SPARK language offers much that's relevant to Design by Contract, and SPARK is used in the embedded space. But it's not mentioned in the book.
The contracts surely eat memory and burn execution time. PC programmers working with gigabytes of RAM and 3GHz processors may be content burning resources like a West Coast wildfire, but we embedded people can't. I sure would have liked some insight into the resources consumed by contracts.
The chapter describing DbC's benefits is brilliant and can serve as a manifesto for contracts. Yet that doesn't surface till Chapter 8, long after legions of embedded readers will have given up with Eiffel exhaustion. Read it first, and then struggle through the code.
DbC is an interesting and potentially very important way to create more reliable code. This book is a great resource for Eiffel programmers but is merely titillation to firmware developers, who will only see glimmers of the technique's possibilities without getting any sense of how to actually use it in their day-to-day work.
So little time
Two thousand words on and I still have a dozen books I'd like to review. Those will have to wait for a future column, though do check out my book review page on www.embedded.com/books for a couple of more reviews. Till then, as John Prine sang, "Blow up your TV, throw away the paper."6 And spend an hour or so a day reading books, for professional development and just for fun.
2. Dylan, Bob. It's Alright, Ma (I'm Only Bleeding). Copyright 1965.
4. Axelson, Jan. USB Complete: Everything You Need to Develop USB Peripherals (Lakeview Research, 2005, Madison WI, ISBN 978-1-931448-02-04) in 572 pages
5. Mitchell, Richard and Jim McKim. Design by Contract, by Example. (Addison-Wesley, 2002, ISBN 0-201-63460-0)
6. Prine, John. Spanish Pipedream (Blow up your TV). 1971.
I agree that it is both unfortunate and amazing that those in one of the the fastest-changing industries don't have time to keep up! Good article, but I disagree with the quote from John Prine - instead, here's one from Zig Ziglar, "I read the Bible and a newspaper every day, because I want to know what both sides are up to."
- Bill Wurst