For novel ideas about building embedded systems (both hardware and firmware), join the 28,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'm a tool guy. Whether it's a piston ring compressor, a roaring planer or a decent IDE I've always bought the best I could afford. Actually, "always" isn't quite correct as I have succumbed to the temptation of Harbor Freight a few times. But cheap tools have always been a disappointment. There was that belt sander; it ran so hot one could hardly hold on to it. Every time I used it it ticked me off. Eventually I donated it and got a decent unit. Or the come-along that wouldn't release under load.
But a great tool makes one smile every time it's used. The Husqvarna blower. The xplorer2 replacement for that cursed Vista version of Windows Explorer.
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