Firmware coding requires constant (re-)education - Embedded.com

Firmware coding requires constant (re-)education

Of all the software programming environments, the problems facing embedded developers of C-language based code used in microcontroller firmware is themost difficult by several orders of magnitude. It reminds me in many waysof the Biblical saying about trying to get the camel through the eye of a needle. 

While solid-state technology has made the ROM, EPROM and flash-based firmwaredensities significantly larger, the constraints of the application as regardsspace, timing and power still limit a developer’s options. Other than codein the specific machine language of the processor being used in the design,the cross-platform language of choice for memory and compute efficient codeis still C.

Comparatively speaking, it is easy to learn. But using it to write concise resource-efficient code, and doing so without bugs, is a challenge. It is an unruly language and requires close attention to your programming “Ps and Qs.” 

Because of this, the wise and experienced firmware developer is always in a state of constant education and re-education about the best ways to programefficiently in C for firmware apps. A good resource to help you is “Firmware developer's essential reading list,“ Jack Ganssle’s most recent blog on C-programming and firmware challenges, in which he provides a list of bookson firmware development. 

But as a regular reader of his blogs, I alsothink many of Jack’s blogs are worth reading and rereading, not only fortheir insights, but for the humor he brings to the subject. Of the manyhe has written for Embedded.com on this topic, among my favorites are:

Firmware Maintenance
Firmware Metrics
Firmware Design Patterns, and
Reverse engineering ANSI-C legacy code

In this week’s Embedded Tech Focus newsletter   are some of Jack’s more recent blogs on firmware development by Jack and Michael Barr, as well as a collection of design articles, webinars and tech papers on the topic. In addition, here are a few other less recent, but still very useful, articles and blogs on firmware related topics that I still find useful:

Bug-killingstandards for firmware coding,” and “Morebug-killing standards,” by Michael Barr.
Gettingdisciplined about embedded software,” by Jack Ganssle.
Makingembedded system debug easiers,” by Jack Ganssle and Ken Arnold
Tipson building & debugging embedded designs,” by Jack Ganssle, and,
Hardware/softwareco-development (with some emphasis on software),” by Mark Saunders.

If you think it is time for an intensive two or three day course in all-things related to C-language and firmware development, I recommend the Spring Embedded Systems Conference at the 2013 DESIGN West,April 26-25 in San Jose, Ca.  Out of the 21 tracks, the ones I thinkwill have substantial firmware development content include:

Programming
Software Architecture and Design
Software Development
Debugging and Test  

Jack Ganssle will, of course, be at the conference, conducting several classes, including: Better Firmware Faster (ESC-106 ), Using standards and inspection to slash schedules and improve quality (ESC-214 ), Really real time systems (ESC-302 ), and Mars ate my spacecraft (STS-302 ).

And if you are not already aware, some of the regular contributors to Embedded.com also maintain their own Web sites where you can get in depth information on firmware development, including Jack’s Ganssle Group, MichaelBarr’s Embedded Guru Websiteand his Barr Group , and Niall Cooling’s Sticky Bits. Several new contributors to the site on embedded C programming issues include:AndrewLucas, PriyadeepKaur, Anders Lundgren and Lotta Frimanson, and ColinWalls. 

Embedded.com Site Editor Bernard Cole is also editor of the twice-a-week Embedded.com newsletters as well as a partner in the TechRite Associates editorial services consultancy. He welcomes your feedback. Send an email to , or call 928-525-9087.

See more articles and column like this one on Embedded.com.Sign up for the Embedded.com newsletters . Copyright © 2013 UBM–All rights reserved.

2 thoughts on “Firmware coding requires constant (re-)education

  1. I am firm believer in this, i think re education helps me to get all the basics updated. Every repeat reading teaches you some thing new, Thanks for sharing this article.

    Log in to Reply

Leave a Reply

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