Archive for March, 2009

Coding Standard Rule #6: Use C99’s Fixed-Width Integer Type Names

Tuesday, March 31st, 2009 Michael Barr

This is the sixth in a continuing series of blog posts describing simple coding rules that help keep bugs out of embedded C programs.

Rule: Whenever the width, in bits or bytes, of an integer value matters in the program, fixed width data types shall be used in place of char, short, int, long, or long long. The signed and unsigned fixed width integer types shall be as shown in the table below.

Integer Width Signed Type Unsigned Type
8 bits / 1 byte int8_t uint8_t
16 bits / 2 bytes int16_t uint16_t
32 bits / 4 bytes int32_t uint32_t
64 bits / 8 bytes int64_t uint64_t

Reasoning: The ISO C standard allows implementation-defined widths for char, short, int, long, and long long types, which leads to portability problems. Though the 1999 standard did not change this underlying issue, it did introduce the uniform type names shown in the table, which are defined in the new header file stdint.h. These are the names to use even if you have to create the typdefs by hand.

Coding Standard Rule #5
Coding Standard Rule #7

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

Coding Standard Rule #5: Only use Comments for Commenting

Monday, March 30th, 2009 Michael Barr

This is the fifth in a continuing series of blog posts describing simple coding rules that help keep bugs out of embedded C programs.

Rule: Comments shall neither be nested nor used to disable a block of code, even temporarily. To temporarily disable a block of code, use the preprocessor’s conditional compilation feature (e.g., #if 0 … #endif).

Example (don’t):
/*
a = a + 1;

/* comment */
b = b + 1;
*/

Reasoning: Nested comments and commented-out code both run the risk of allowing unexpected snippets of code to be compiled into the final executable. This can happen, for example, in the case of sequences such as the above.

Coding Standard Rule #4
Coding Standard Rule #6

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

Coding Standard Rule #4: Use volatile Whenever Possible

Friday, March 27th, 2009 Michael Barr

This is the fourth in a continuing series of blog posts describing simple coding rules that help keep bugs out of embedded C programs.

Rule: The volatile keyword shall be used whenever appropriate, including:

  • To declare a global variable accessible (by current use or scope) by any interrupt service routine,
  • To declare a global variable accessible (by current use or scope) by two or more tasks, and
  • To declare a pointer to a memory-mapped I/O peripheral register set (e.g., timer_t volatile * const p_timer ).

Reasoning: Proper use of volatile eliminates a whole class of difficult-to-detect bugs by preventing the compiler from making optimizations that would eliminate requested reads or writes to variables or registers that may be changed at any time by a parallel-running entity.

Anecdotal evidence suggests that programmers unfamiliar with the volatile keyword think their compiler’s optimization feature is more broken than helpful and disable optimization. The authors suspect, based on experience consulting with numerous companies, that the vast majority of embedded systems contain bugs waiting to happen due to a shortage of volatile keywords. These kinds of bugs often exhibit themselves as “glitches” or only after changes are made to a “proven” code base.

Coding Standard Rule #3
Coding Standard Rule #5

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

New Mobile Phone OS Market Share Data

Thursday, March 26th, 2009 Michael Barr

Fast Company magazine yesterday reported the latest statistics on mobile web browsing. Not surprisingly, people with iPhones are the dominant users of mobile Internet.

Included in the article are statistics about the market for mobile phone operating systems. The shakeup in the OS market share mix over the past six months (August 2008 to February 2009) are nothing short of astonishing:

  • iPhone up from 10% to 50%
  • RIM down from 32% to 21%
  • Windows Mobile down from 30% to 13%
  • Palm down from 19% to 7%
  • Android up from 0% to 5%

Clearly, Windows Mobile and Palm OS are really taking it on the chin from iPhone and Android.

Now if Apple could just get their task priorities right so I could listen to music without hiccups while browsing…

Coding Standard Rule #3: Use static to Enforce Encapsulation

Thursday, March 26th, 2009 Michael Barr

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

Rule: C’s static keyword shall be used to declare all functions and variables that do not need to be visible outside of the module in which they are declared.

Reasoning: C’s static keyword has several meanings. At the module-level, global variables and functions declared static are protected from inadvertent access from other modules. Heavy-handed use of static in this way thus decreases coupling and furthers encapsulation.

Coding Standard Rule #2
Coding Standard Rule #4

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