embedded software boot camp

How to Enforce Coding Standards (Automatically)

May 25th, 2011 by Michael Barr

Coding standards can be an important tool in the fight to keep bugs out of embedded software. Unfortunately, too many well-intentioned (especially, corporate) coding standards are ineffective and gather more dust than followers. The hard truth is that enforcement of coding standards too often depends on programmers already under deadline pressure to be disciplined while they code and/or to make time to perform peer code reviews. And when peer reviews are done in this scenario, they too easily devolve into compliance discussions that miss the forest for the trees.

To ensure your selected coding standard is followed and thus effective, your team should find as many automated ways to enforce as many of its rules as possible. And you should make such automated rule checking part of the everyday software build process. Ideally, you would also restrict version control check-ins to just code that has passed all the automated checks. No code that breaks any of these automatable rules should be allowed in peer code reviews. That way, code reviewers can focus their limited hours on (1) what the code is supposed to do, (2) whether it does so correctly, and (3) whether the code and comments together are easily understood by all involved.

One of the ways Barr Group has found to increase compliance with its Embedded C Coding Standard is by configuring static analysis tools we already use to automatically enforce individual rules.

Perhaps the best option is to use a static analysis tool that includes built-in support for your chosen coding standard and/or the ability to be customized to proprietary rules. LDRA‘s static analysis engine, a screenshot from which is shown in the image below, comes preconfigured to check about 80% of the “Barr Group” coding standard rules, as well as a number of other widely used coding standards.

But there are other, less expensive, options available as well. Two tools that we have used are RSM and PC-Lint from M Squared Technologies and Gimpel Software, respectively. Neither can easily and independently enforce all of our Embedded C Coding Standard rules. But used together and properly configured, these two tools offer a low-cost automated coding standards enforcement mechanism that covers a large percentage of the rules.

Configuring RSM

The following RSM outputs can be examined and configuration options set (in version 7.75) to assist in the automated enforcement of the identified rules from the Embedded C Coding Standard. Pricing for the RSM tool, which runs on Windows, Linux, and other versions of Unix (including Mac OS X), is online at http://msquaredtechnologies.com/m2rsm/order/.

Rule # Brief Description Tool Configuration Notes
1.2.a Line length limited to 80 characters. Quality Notice 1
1.3.a Braces surround all blocks of code. Quality Notice 22
1.7.c Keyword goto not used. Quality Notice 9
1.7.d Keyword continue not used. Quality Notice 43
1.7.e Keyword break not used outside switch. Quality Notice 44
2.2 Location and content of comments. Quality Notices 17, 20, 51; Options -Es -Ec -EC
3.1 Use of white space. Quality Notices 16, 19
3.5.a No tab characters. Quality Notice 30; Option -Dt
3.6.a UNIX-style (single-character) linefeeds. Option -Du
4.1.a-d Module naming conventions. Option -Rn
4.2.a Precisely one header file per source file. Option -Rn
6.1.a-e Precisely one header file per source file. Quality Notice 2; Option -l
6.2 Cyclomatic complexity of functions. Quality Notices 10, 18, 27; Option -c
6.3.b.i-iii Preprocessor macro safety mechanisms. Option -m
8.2.d If-else if statements always have else. Quality Notice 22
8.3.b Switch statements always have default. Quality Notices 13, 14, 56
8.5.a No unconditional jumps. Quality Notices 9, 43, 444

Configuring PC-Lint

In a future blog post, I will similarly identify PC-Lint configurations that can be used (in version 9.0) to assist in the automated enforcement of specific rules from the Embedded C Coding Standard. Pricing for the PC-Lint tool, which runs on Windows, Linux, and other versions of Unix (including Mac OS X), is online at http://gimpel.com/html/order.htm.

Embedded Software Training in a Box

May 6th, 2011 by Michael Barr

Embedded Software Training in a BoxI am beaming with pride. I think we have finally achieved the holy grail of firmware training: Embedded Software Training in a Box. Priced at just $599, the kit includes Everything-You-Need-to-Know-to-Develop-Quality-Reliable-Firmware-in-C, including software for real-time safety-critical systems such as medical devices.

In many ways, this product is the culmination of about the last fifteen years of my career. The knowledge and skills imparted in the kit are drawn from my varied experiences as:

This kit also–at long last–answers the question I’ve been receiving from around the world since I first started writing articles and books about embedded programming: “Where/How can I learn to be a great embedded programmer?” I believe the answer is now as easy as: “Embedded Software Boot Camp in a Box!”

Beer and Boards at ESC Silicon Valley

April 6th, 2011 by Michael Barr

It really looks like I’ve picked the wrong year to miss ESC Silicon Valley (due to a schedule conflict). (The last time I wasn’t at ESC, it was 1997 and White Zombie was still together. The first thing I’d really liked to have seen is Steve Wozniak‘s keynote speech. The second thing I’m really sad to miss is the just announced “Beer and Boards” party/giveaway.

Beer and Boards sounds really fun. Here’s how it works: Every “All Access” attendee will get to choose one of three free development kits to take home:

Once you select your preferred kit you will receive information on the time and place for the relevant Beer and Boards party, at which you will get to drink free beer at a special meet-and-greet with one of your kit’s designers to talk about your new kit and its capabilities. Three boards spread out over three days.

Nerds drinking beer! I love it. What will they think of next?

Before you register for this year’s ESC, be sure to check out my earlier post Save Big on Embedded Systems Conference Registration. Also, remember to use the promo code BARR20 to save an additional 20% off registration and be entered to win a free seat at a future Embedded Software Boot Camp or one of 20 free copies of the Embedded C Coding Standard.

Save Big on Embedded Systems Conference Registration

March 21st, 2011 by Michael Barr

The big Embedded Systems Conference 2011 Silicon Valley show opens six weeks from today. This should have been my fourteenth consecutive year as a speaker, but I have an unfortunate calendar conflict that first week of May.

Judging from the speaker and course lineups, it looks like it’s going to be a really great ESC conference again this year. I strongly encourage you to go if you can. Here are five great reasons to register ASAP:

#1: IT’S CHEAPER THIS WEEK! – The current early registration pricing expires this Friday, March 25. Registering now will save you $400 off the onsite price of the All Access, 4-Day, and 3-Day Conference Passes or $200 off a 1-Day Pass. (Note there are also group discounts available.)

#2: USE PROMO CODE “BARR20” TO SAVE AN ADDITIONAL 20%! – During the registration process there is a place to enter a “Promo Code”. No matter what conference package you select, you will receive an additional 20% off the price if you use my special code “BARR20”. For the All Access Conference Pass that’s an additional $479 discount on top of the $400 above. Wow!

#3: GRAND PRIZE: FREE SEAT AT EMBEDDED SOFTWARE BOOT CAMP – Many people have told me that their company only has a set amount of budget for training and conferences per year and that the Embedded Systems Conference and Embedded Software Boot Camp have to compete for those funds. Well, now you can have your cake and eat it to. One lucky ESC conference attendee will be selected at random to also attend the Embedded Software Boot Camp for free (minimum $2,995 value). (To be entered to win, you must use the “BARR20” promo code when you register.)

#4: 20 RUNNER-UP PRIZES: EMBEDDED C CODING STANDARD BOOK – Twenty lucky ESC conference attendees will be selected at random to receive a print copy of the Embedded C Coding Standard book. (To be entered to win, you must use the “BARR20” promo code when you register.)

#5: THE CONFERENCE CONTENT – Use the ESC Schedule Builder to choose from hundreds of training sessions by dozens of expert speakers spread across 25 technical tracks. To this depth and breadth of topics this year are added the 6th Annual Multicore Expo and Texas Instrument’s Technology Day 2011 programs. Wow!

Do Inline Function Bodies Belong in C Header Files?

March 21st, 2011 by Michael Barr

Earlier today I received the following question by e-mail from Brazil:

I am trying to conform to the rules in your Embedded C Coding Standard book and I just ran into what may be a problem with Rule 6.3.a. Instead of using function-like macros, I’m using inline functions, as you recommend. However, my compiler (avr-gcc) gives an error when I declare a function to be inline at both header and source file. If I put both the inline declaration and function body inside the header file it works fine. This fixes my compiler problem, but isn’t it a bad practice to place code inside the header file?

This is a good question, as it seems at first to be about a conflict between the Embedded C Coding Standard and what I refer to as “Generally Accepted Programming Principles” (i.e., GAPP not GAAP). It’s also approaching a frequently asked question, so I thought it’d also be good to share my e-mailed answer here.

The inline keyword is a part of the C++ programming language that was added late to C (in C99). In C++, most programs are built out of classes–with best practice dictating one header file per class definition. Any C++ function may be declared inline. But if the inline function is a public member function (a.k.a., public method) of the class it is necessary to place the code for the inline function inside the header file. This is so that all of the other modules that use the class can see the code they need to have placed inline by the compiler.

Of course, placing the body of any function inside a header file conflicts with GAPP for the C programming language. Here’s how you should decide what to do:

IF the inline function is a “helper” function that’s only used inside one C module, THEN put it in that .c file only and don’t mention it in the header file. This is consistent with Rule 4.2.c, which says that “The header file shall identify only the [functions] … about which it is strictly necessary for other modules to know.”

IF, however, the inline function operates on the abstract data type defined in the header file and must be visible to two or more modules, THEN put the body of the inline function inside the header file. There is no rule in the Embedded C Coding Standard that strictly prohibits this, so there is no conflict.

See my earlier post What Belongs in a C .h Header File? for additional suggestions concerning header file contents.