I normally would enjoy any book that starts with "Any idiot can write code."  This was a fun book to read, but I can't say I accumulated important take-aways.  

 

Writing very casually, he says some interesting things.  An emulator trace "will capture weirdness like no other tool."  "Realize that a wire is not a wire, but a complex transmission line whose characteristics will confound your common sense." It's a punchy style replete with maxims, exhortations, and aphorisms.  

 

A few of the chapters are mere musings.  The hardware bit covers small controllers, voltage levels on pins, good and bad watchdog timers, memory types, noise-sensitive pins, off-board I/O, crosstalk, how many X-Acto knives you need, installment purchases, and such.  The people bit covers technicians, engineers, managers, and the value of degrees.  Can't we all just play nicely together?  Hire smart people that work hard and are nice.  No mention of incentive structure or performance evaluation.    

 

I'd quibble with the title.  First, there's the "Art."  My Apple Dictionary says "art: (noun) 4 a skill at doing a specified thing, typically one acquired through practice."  Ganssle says "This books lays out a very simple seven-step plan to get firmware development under control. There are no formal methodologies to master; the ideas are immediately useful."  Is this "art?"  Plan isn't skill.  He talks early about what me means under each step of the plan.  After that, the remainder of the book is more about tribalistic rituals and bug anecdotes.   For instance, there is no mention of what specifically to study to understand grounding, instead there are quite a few sentences devoted to probe clips.  That's practice, but it isn't skill.  Second, there's the "Designing."  My Apple Dictionary on this count says "design: (verb) decide upon the look and functioning of (a building, garment, or other object), typically by making a detailed drawing of it".   The book has little to say about the decision part of design.  It exhorts to select simpler and cheaper chips, all else being equal.  It exhorts to add test points at convenient locations; more is better.  It provides useful pointers for implementing FIFOs and ISRs.  These are useful ideas, but pragmatic rather than intuitive.  That's about it for decisions.  The book does not discuss the function part of design.  Ganssle states his intention to emphasize "effective ways to design products" by "applying problem-solving to the way we work."  I didn't get the sense there is a problem-solving or design method here, but rather a cornucopia of tips.  

 

Quibbling aside, the cornucopia does contain some practical advice.  Ganssle exhorts us to "cheat" the COCOMO exponentials, meaning finding was to flatten the software estimation curves.  He advises us to use

1. partitioning through encapsulation,

2. partitioning through CPUs, including my favorite: "Let the software drive the hardware design" (p.40).

3. partitioning by using an RTOS

4. partitioning by features

5. partitioning by top-down decomposition

 

Ganssle's Seven Step Plan for better embedded system design, briefly, is

1. Buy and use a version control system

2. Institute a Firmware Standards Manual

3. Start a program of Code Inspections

4. Create a quiet environment conducive to thinking

5. Measure your bug rates

6. Measure code production rates

7. Consistently study software engineering

 

I find this plan interesting because it is not, like so many other such improvement suggestions, all about process.  The creativity and study element are not things one likely would put in his ISO-9001 or CMMI agenda.  But they're worth doing.  However I would categorize this like so many process solutions as a defensive strategy.  There is no emphasis on quality introduced into the design or implementation from the outset.  Even the code inspections step is a defensive tactic.   Measuring bug rates is good, but it doesn't have a counterpart step to prevent bugs from being introduced in the first place.  This is true for most of the software development field, not just embedded systems.  

 

A few spurious thoughts.  Ganssle claims that it's too difficult to estimate instruction-level run time at source level, owing to processor hardware design, pipelines and prefetchers and cache and such.  I think it's still possible to do a statistical analysis.  Ganssle mentions that studies show each interruption for personal interaction sets the creative thinking back 15 minutes.  I have to agree, and think the book Finding Time reviewed here some months ago covers this issue pretty well.   Ganssle states that rewriting bad code is 2x the original cost, but prevents a 4x cost in debugging later.  I'd have to agree with that, recalling many times when chucking (or more likely losing) the first draft led to a much tidier second draft.  Ganssle includes firmware standards and drawing management system standards in appendices, intended as precepts for the yet-to-be-professional embedded system development organization.