Firmware developer's essential reading list -

Firmware developer’s essential reading list

Plenty of great sources exist for information on firmware design. Here are some of the best.

Magazines (online and otherwise) –You're reading it now. It's the most important publication dedicated to embedded systems.

EDN –Yes, this is a hardware publication, but hardware is never far from the software.

EE Times –EE Times is the source of information about what technologies are coming, where the jobs are, and what companies are up to.

Circuit Cellar Ink –Sort of a dream embedded magazine, it covers projects that include both hardware and software. Though aimed at hobbyists, professionals can learn a lot from it.

Crosstalk –An Air Force site, two out of three issues are dreadfully about big process. But one of three are gold.

Peopleware, Tom DeMarco and Timothy Lister. This is the most important book on productivity in the software engineering environment around. The key takeaway: interruptions destroy productivity. Cubicles–and, worse, open offices–ensure everyone is operating at the nadir of performance.

A Discipline for Software Engineering, by Watts S. Humphrey. This is the single most important book ever written about software engineering. In it Humphrey takes the reader through the Personal Software Process. The net is huge gains in productivity, lower defect rates, and shorter schedules. But it's not for the faint of heart; there's a lot of homework and math, and if you don't do that, you'll get nothing from the book. This is one for grown-ups: developers who really care about their profession and are willing to work hard at the problems to get tremendous benefits.

Guidelines for the Use of the C Language in Vehicle Based Software , by MISRA. This PDF is a compilation of about 140 rules for the safer use of C. It is not, by itself, enough to define an entire software standard, but it's a good first step. And it's pretty industry standard now.

Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric, by Arthur H. Watson and Thomas J. McCabe. Testing can be done somewhat scientifically. This method is useful and important.

Peer Reviews in Software by Karl E. Wiegers. This is the all-around best book on the subject. Wiegers looks at the entire spectrum of inspections from informal pass-around reviews to the most formal of processes. The book gives a complete description of the entire review process, from start to finish, in about 80 pages. And the rest of it fills in the details.

Best Kept Secrets of Peer Code Review. This free book from SmartBear Software does a good job at avoiding promoting their products while digging into reviews of three million lines of code at Cisco. Great reference for doing distributed reviews.Next-tier reading
Confessions of a Used Program Salesman, Will Tracz. This is one of the best books about reuse. Presented in a fun, readable, and very accessible manner.

Debugging by David Agans. Most of us have an ad hoc approach to finding bugs. Agans lays out a step-by-step approach. I disagree with his assessment that we must read the databook cover to cover first; with some parts having a 5,000-page datasheet, that's impractical. But this other ideas are gems.

Object-Oriented Software Construction , Bertrand Meyer. Hands down the best book about OO around. Meyer takes the reader through the entire process of writing object-oriented code. The book is brilliantly-written and deserves a Pulitzer of tech writing. Alas, he does teach Eiffel in it, but all of the ideas scale to C++.

An Embedded Software Primer by David E. Simon. It's aimed at the novice or nearly novice embedded person, one with experience in C but little feel for the unique issues of embedded systems. The book starts with the standard introduction to microprocessor hardware (which could have been left out), but quickly moves on to a very good description of interrupts; this section alone is quite worthwhile. And from there it delves into one of the best discussions of RTOSes anywhere.

Computer Approximations , by John Hart. The art of computer approximations is establishing a balance between accuracy and computational burden. Nearly all commonly used approximations do use polynomials. The trick is figuring out the best mix of coefficients and terms. This is the best book on the subject, although it offers little in terms of theoretical insight. The meat is in it's Tables of Coefficients. There you'll find 150 pages of polynomial coefficients for square and cube roots, exponentials, trig and inverse trig, and logs. The coolest part of this is the large number of solutions for each function: do you want a slow accurate answer or a fast fuzzy one? Hart gives you your choice.

It's not the easiest book to use. Hart assumes we're all mathematical whizzes, making some of it heavy going. Do skim over the math section, and figure out Hart's basic approach to implementing an approximation. His notation is quite baffling: until I figured out that (+3) +.19400 means multiply .194 times 10**3, none of my code worked.

eXtreme Programming Explained. Kent Beck's book is a classic of agile programming. Very readable, very interesting, and full of good ideas. I don't buy into it all, but Beck is thought-provoking and might change some of your approach to development.

Balancing Agility and Discipline , Barry Boehm and Richard Turner. Some of the agile pronouncements are a bit hard to buy for firmware. Zealots on both sides muddy the issues. In this book the authors define five parameters that help one make an engineering decision about where to be in the agile vs. plan-driven approaches.

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges, and works as an expert witness on embedded issues. Contact him at. His website is .

6 thoughts on “Firmware developer’s essential reading list

  1. Jack

    As always you dredge up some interesting reading and there are certainly some there I will start to read.

    One you seems to have missed is “Test Driven Development for Embedded C”.

    Is MISRA really that well adopted by industry? I certainly have not

    Log in to Reply
  2. For me (automotive software development in Europe) MISRA is a must and nobody question its usage. The OEMs (GM, Volvo, BMW, Renault, PSA, Daimler) my company is/was working for always request(ed) usage of static checker with enabled MISRA rules.
    Also some

    Log in to Reply
  3. Peopleware is one of the best books about productive engineering environments I have read. Before anyone sets out to design work space for engineers it should be required read. I also really like the MISRA rules, read those a few years ago while working

    Log in to Reply
  4. I used the first version of MISRA at a previous employer. Some very good stuff in there, but a lot of nonsense too. I haven't seen the later versions. Hopefully they've improved. In any case, 99% or more of the problems MISRA attempts to solve can be b

    Log in to Reply
  5. Surely you meant to link to the current MISRA-C standard? The MISRA link seems to points at some old publication from 1994, which is probably highly irrelevant. The document of interest for the embedded community as whole is called “MISRA-C:2004 Guidelines

    Log in to Reply
  6. I don't think you understand what MISRA-C is. It is a coding standard dictating rules not only for the programmer, but for the tool manufacturers as well. One of the most important things MISRA-C enforces is the mandatory use of a static analysis tool. PC

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.