Archive for March, 2009

Calling all Embedded Systems Bloggers

Wednesday, March 25th, 2009 Michael Barr

I am currently doing research for an in-depth blog post or series about the online social networking community of individuals and companies with blogs, facebook pages, twitter feeds, etc. about embedded systems development. If you are involved with any part of the online embedded systems community and think I may not have already heard of you, please reach out to me via an e-mail to mbarr@netrino.com or via twitter to @netrinomike.

Coding Standard Rule #2: Use const Wherever Possible

Tuesday, March 24th, 2009 Michael Barr

Another in a continuing series of blog posts about simple rules for keeping bugs out of embedded software written in the C programming language.

Rule: The const keyword shall be used whenever possible, including:

  • To declare variables that should not be changed after initialization,
  • To define call-by-reference function parameters that should not be modified (e.g., char const * p_data),
  • To define fields in structs and unions that cannot be modified (e.g., in a struct overlay for memory-mapped I/O peripheral registers), and
  • As a strongly typed alternative to #define for numerical constants.

Reasoning: The upside of using const as much as possible is compiler-enforced protection from unintended writes to data that should be read-only.

Coding Standard Rule #1
Coding Standard Rule #3

These rules are excerpts from the Embedded C Coding Standard book.

Coding Standard Rule #1: Always Use Braces

Thursday, March 19th, 2009 Michael Barr


This is the first in a planned series of blog posts suggesting how to reduce firmware bugs by following a set of simple C programming rules.

Rule: Braces ({ }) shall always surround the blocks of code (a.k.a., compound statements) following if, else, switch, while, do, and for keywords. Single statements and empty statements following these keywords shall also always be surrounded by braces.

Example (don’t):
if (timer.done)
// A single statement needs braces!
timer.control = TIMER_RESTART;

Example (do):
while (!timer.done)
{
// Even an empty statement should be surrounded by braces.
}

Reasoning: There is considerable risk associated with the presence of empty statements and single statements that are not surrounded by braces. Code constructs of this type are often associated with bugs when nearby code is changed or commented out. This type of bug is entirely eliminated by the consistent use of braces.

Coding Standard #2

These rules are excerpts from the Embedded C Coding Standard book.

Firmware Wall of Shame: Welch Allyn Defibrillator Recall

Tuesday, March 17th, 2009 Michael Barr

The FDA has just announced a Class I (the most serious human risk category) recall of the Welch Allyn AED 10 automatic external defibrillator (shown).

Among the reasons for the recall are the following problems that are either caused by embedded software bugs or hardware problems able to be fixed entirely through a firmware upgrade:

  • “Units serviced in 2007 and upgraded with software version 02.06.00 have a remote possibility of shut down during use in cold environmental conditions. There are no known injuries or deaths associated with this issue. The units will be updated with the current version of software.”
  • “All of the recalled units will be upgraded with software that corrects [another] unexpected shutdown problem. In the meantime … it is vital to follow the step 1-2-3 operating procedure which directs attachment of the pads after the device has been turned on. This procedure is described on the back of your device and also in the Quick Reference material inside the AED 10 case. Some pages in the user’s manual may erroneously describe or show illustrations of [a different] operating procedure… Please disregard these erroneous instructions.”

There has been at least one death at a time when the second type of unexpected software shutdown occurred. Are bugs in the embedded software to blame? Of what sort? Could the authors of that firmware be sued in relation to the death? Were they negligent? Are they sure that there are Zero Bugs (or even just fewer bugs) in the “current version of the software”?

Expect more of this type of firmware-involved death as embedded systems continue to proliferate.