Archive for April, 2009

Embedded Systems Conference Wrap-Up

Tuesday, April 7th, 2009 Michael Barr

I spent last week in San Jose, at the Embedded Systems Conference (ESC). As I have come to expect (this was my twelfth consecutive year as a speaker), the event remains the place for embedded systems developers to be. There is no other similar event for learning about the latest processors, middleware and programming techniques; running into old friends and making new friends; and meeting with vendors past and possibly future. Everybody who’s anybody in the embedded systems community is typically at this key trade show.

This 21st ESC was smaller than those of the past few years. Vendor booths mostly filled the main hall at San Jose’s McEnery Convention Center, as well as the area outside the main hall entrance. But that makes the total square footage much smaller than in recent years. Recall that ESC moved from San Jose to San Francisco for a few years because McEnery was insufficient (and everyone abhorred the “tennis bubble” expansion floor)–ESC only came back to the Silicon Valley proper after McEnery was expanded via the adjacent Marriott hotel and conference center. This shrinkage seems to be recession-related as I am told that “cancellation revenues” (i.e., payments by vendors who had previously committed to renting space but didn’t show) hit record levels.

However, overall attendance “felt” healthy. All of the paid courses were well attended (e.g., my course on Embedded C Coding Standards drew over 120 people to a room set with 100 chairs). And thanks to the “more intimate” venue consolidation, booth traffic on the show floor seemed quite reasonable. I am told that over 3,000 of the free “Engineer Survival Kit” bags were given out to an estimated 5,000 overall show-floor attendees.

Netrino had a huge presence at the show this year, including a booth.

In addition to my three paid courses, two Netrino staff engineers and I also made three “open to the public” presentations in the ESC Theater on the show floor. These more theatrical productions (Adventures in Satellite TV Piracy, RTOS MythBusters, and This Code Stinks–The Worst Embedded Code We’ve Ever Seen) were almost as much fun to create as they were to deliver. All three were quite popular with 200-250 attendees, including many standing around in the surrounding aisles. Everyone I talked with thought they were educational and fun at the same time–which is exactly what we were aiming for. These events and our booth worked nicely to drive traffic to each other, making it a great show for us all around.

David Markey has a nice wrap-up of the show floor games and goodies in his blog at Product Design & Development. Elsewhere, TechInsights has a page of links to vendor announcements of new products, services, partnerships, and initiatiatives.

Of the announcements, Microsoft’s renewed focus on embedded systems as an important category and a shift in the way they are approaching the market was the most interesting to me. I heard through the grapevine that Microsoft is noticing their past large Windows CE and XPE customers tend not to be sticky (i.e., top 10 customers shift every year). And their positioning seems to be maturing with an aim toward changing that. I like the clarity and coherence of Microsoft’s embedded product rearrangement, which–because of the “POSReady” and “NavReady” packages, in particular–reminds me quite a bit of Sun’s Java 2 Micro Edition horizontal+vertical arrangement of a few years back.

Coding Standard Rule #10: Don’t Use the Comma Delimiter Within Variable Declarations

Monday, April 6th, 2009 Michael Barr

Rule: The comma (‘,’) operator shall not be used within variable declarations.

Example (don’t):

char * x, y;   // did you want y to be a pointer or not?

Reasoning: The cost of placing each declaration on a line of its own is low. By contrast, the risk that you’ve made a mistake and the compiler or a maintainer won’t understand your intentions is high.

Coding Standard Rule #9

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

Coding Standard Rule #9: Don’t Create Function-Like Macros

Friday, April 3rd, 2009 Michael Barr

Rule: Parameterized macros shall not be used if an inline function can be written to accomplish the same task.


#define MAX(A, B)   ((A) > (B) ? (A) : (B))     // Don’t do this ...inline int max(int a, int b)           // ... if you can do this instead.

Reasoning: There are a lot of risks associated with the use of preprocessor #defines, and many of them relate to the creation of parameterized macros. The extensive use of parentheses (as shown in the example) is important, but does not eliminate the unintended double increment possibility of a call such as MAX(i++, j++). Other risks of macro misuse include comparison of signed and unsigned data or any test of floating-point data. The C++ keyword inline was added to the C standard in the 1999 ISO update.

Coding Standard Rule #8
Coding Standard Rule #10

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

Coding Standard Rule #8: Don’t Mix Signed and Unsigned Data

Thursday, April 2nd, 2009 Michael Barr

Rule: Signed integers shall not be combined with unsigned integers in comparisons or expressions. In support of this, decimal constants meant to be unsigned should be declared with a ‘u’ at the end.

Example (don’t):

uint8_t a = 6u;
int8_t b = -9;

if (a + b < 4)
// This correct path should be executed
// if -9 + 6 were -3 < 4, as anticipated.
// This incorrect path is actually executed
// because -9 + 6 becomes (0xFF – 9) + 6 = 252.

Reasoning: Several details of the manipulation of binary data within signed integer containers are implementation-defined behaviors of the C standard. Additionally, the results of mixing signed and unsigned data can lead to data-dependent bugs.

Coding Standard Rule #7
Coding Standard Rule #9

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

Coding Standard Rule #7: Don’t Mix Bit-Wise Operators and Signed Data

Wednesday, April 1st, 2009 Michael Barr

Rule: None of the bit-wise operators (i.e., &, |, ~, ^, <<, and >>) shall be used to manipulate signed integer data.

Example (don’t):

int8_t  signed_data = -4;
signed_data >>= 1; // not necessarily -2

Reasoning: The C standard does not specific the underlying format of signed data (e.g., 2’s complement) and leaves the effect of some bit-wise operators to be defined by the compiler author.

Coding Standard Rule #6
Coding Standard Rule #8

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