Hardware/Firmware Interface Design: Best Practices for Improving Embedded Systems Development

by Dennis L Feucht

Hardware/Firmware Interface Design: Best Practices for Improving Embedded Systems Development
by Gary Stringham, published by Newnes
ISBN 13: 978-1-85617-605-7, hardback, 376 pp, $69.95, December 2009

I did not have to read too far into this book to realize that the author has extensive experience with not only microcontroller programming but also the management of engineering projects involving hardware and firmware. The format of the book is characterized by numerous boxed text inserts and copious bullet items. However, the content is not fluff; the book is loaded with information, some significant fraction of which can be found only in industry among those with development experience. This author has it.

The first four chapters lay out the framework for a hardware-firmware project, setting forth the authors’ general viewpoint and principles such as “set and adhere to standards,” “design for compatibility.” He spends a chapter on “collaboration.” Anyone who has worked on this kind of a project has stories of failures between hardware and software engineers to adequately communicate with each other and thus coordinate for effective work. Stringham covers both formal and informal forms of collaboration. A chapter on planning covers some of the major decisions made at the outset of the project, such as design-or-buy decisions.

Chapter five on documentation is long and involved. The author is well aware of the critical importance of well-documented work. He provides plenty of details, right down to how to document registers, register map formats, bit descriptions, interrupts (edge- or level-triggered), timing, error-handling, and even state machines. You get the impression that documentation is supposed to be comprehensive. It appears that the author is trying to convey the importance of not leaving out anything that is important. And that might even be something you do not imagine could be important – hence a long chapter on documentation.

For the rest of the book, he writes not about how to manage a project but how to design. He has a chapter titled “Superblock,” “a block that has a superset of functions… even if only a subset will be used in a given product.” Here is the rare manager who looks ahead beyond the present project. Next, he takes up “Design” with plenty of talk about timing and synchronization, communication, and control. He includes the often-neglected power-on event (but does not include the power-off event, at least not separately).

Then there are chapters on those items that were supposed to be documented, this time addressing how they are used in design: registers, bit assignments, and how to handle registers shared by multiple drivers. Interrupts deserve a chapter and a simple timing diagram and chunks of C code illustrate ideas. Address mapping pops up and some logic gates appear in one or two places. There is just enough circuitry and just enough code to signal that the author is in touch with the concrete realities of the subject-matter.

What is left? Aborts get a chapter, then hooks and generous portions of diagnostic and test talk, followed by a chapter concluding the book. The appendices include a long list of “best practices” and a bicycle controller specification as a concrete example is Appendix B. Appendix D is a glossary. (There was no appendix C. Maybe it was left out as an example of farsighted planning for the second edition.)

In short, this is a good book for anyone who is involved in hardware-firmware development and who knows just enough to want to better understand how to organize and design it all. It is certainly not a book on analog electronics but it is the kind of knowledge useful to analog engineers who work on products with microcontrollers and need to know the kinds of issues that arise on the digital side in order to interface to them.