For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
FSMs and Tools
Summary: Automate everything. Especially brain-dead stuff like standards checks.
I'll present my Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. The early registration discount ends January 20.
A great tool makes you more efficient and productive.
Tools coupled to a disciplined process are even better.
Four decades in this industry have taught me a few truths. One is the importance of using coding standards. I have yet to see companies consistently generating best-in-class code unless it's done to a standard.
One friend takes pride in the fact that no one can tell who wrote different sections of his company's products, since everyone does it all to an in-house standard. That sort of mirrors the notion of egoless programming originally promoted by Jerry Weinberg.
Until recently the use of standards was pretty spotty. MISRA-C (http://www.misra.org.uk/), though, has started to change that. I run into a lot of companies today that embrace at least a substantial subset of MISRA.
Lots of standards exist. CERT (https://www.securecoding.cert.org/confluence/display/seccode/CERT+Secure+Coding+Standards) has one for secure programming. The F-35 (http://www.jsf.mil/downloads/documents/JSF_AV_C++_Coding_Standards_Rev_C.doc) has its own (called the JSF standard, for Joint Strike Fighter). Barr Group, too, publishes one (http://www.barrgroup.com/Coding-Standard-Muse) as does NASA's JPL (http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf). But most people use manual inspections to enforce the rules, which is a ludicrous activity since it can be automated. Any time a tool can do something, you must use a tool to do that activity. When it comes to checking code against a standard, there really aren't many tools around, which seems sort of whacky considering how much time they could save.
PC-Lint (http://www.gimpel.com/html/index.htm) will check code against the MISRA rules, or at least most of them (some are hard to enforce statically).
C++ Test by Parasoft (http://www.parasoft.com/jsp/products/cpptest.jsp?itemId=47) can check your code against rules you define. But I've yet to meet anyone in the embedded world who uses it.
One very cool tool that seems to fit the needs of this industry is Testbed by LDRA (http://ldra.com/en/products-a-services/ldra-tool-suite/ldra-testbedr). What I like about this product is that it includes around twenty different software standards spread over 1000+ rules. You can tell it to check against a standard, or some mix rules from a number of standards. As the following screen shot shows, one can just select all MISRA-C, or select your own rule set.
The agile community demands we automate our tests, which is great advice (when possible). Similarly, we should automate everything that can be delegated to the mindless yet never bored computer.
Published May 24, 2012