You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com.
Best in class teams deliver embedded products with 0.1 bugs per thousand lines of code (which is two orders of magnitude lower than most firmware groups). They consistently beat the schedule, without grueling overtime.
Does that sound like your team? If not, what action are you taking to improve your team's results? Hoping for things to get better won't change anything. "Trying harder" never works (as Harry Roberts documented in Quality Is Personal).
Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it’s not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See http://www.ganssle.com/onsite.htm.
Two more videos are available. Episode 8 is about using two GPIO bits to simulate an I2C interface, and then a simple protocol analyzer to decode the serial stream. It's a very cheap way to create debug and logging info. All of the code is included.
Episode 9 is a short video about using Ada on a microcontroller. I talk to a lot of people who complain Ada is only viable on big processors, but it actually works really well even in smaller systems. All of the tools are free.
|Quotes and Thoughts|
"When test is the principal defect removal method during development, corrective maintenance will account for the majority of the maintenance spend." Girish Seshagiri
|Tools and Tips|
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.
One respondent to the survey indicated in the comments that he uses, among other tools, uncrustify to clean up the source. This is one of the most powerful and configurable pretty printers around. There are about 450 configuration options and almost, unfortunately, no documentation. Several configuration files are included; defaults.cfg lists all of the options, and that file seems to be about all there is for a user's manual.
Uncrustify will adjust spacing, tabs, brace placement, spaces around operators and much more. It can change a multi-line function declaration so the parameters are all vertically aligned. One of the included configuration files will change source to resemble K&R style.
It runs in a Windows/Linux command shell and is breathtakingly fast. I ran it against an 8000 line C source file and the execution time was perhaps a quarter second on a Windows 8.1 six-core machine.
My philosophy about pretty printers is that one should type in correctly-formatted code, rather than entering a mess and counting on a tool to clean things up. But no one is perfect and there's no reason not to use the computer to fix our occasional mistakes. And, we're often confronted with legacy or inherited code; it's a waste of expensive engineering time to manually reformat that.
|Results of Firmware Standard Survey|
In Muse 265 I asked people to complete a very short survey about which firmware standards, if any, they use. About 500 responded, and here's the results.
It was common for people to indicate they used MISRA with some modifications and/or exceptions. A few use MISRA combined with other standards. In both of these cases I called the standard used "MISRA-modified."
In some cases just a single respondent used a standard. These were: EN50128, Google Coding Standard, SLI-4, K&R, and DO-178B (which isn't a standard). In other cases six or fewer people were using one; these are CERT, Netrino and mine. None of these are reflected in the results below as they are in the noise.
So here's the data:
Almost 70% do use a firmware standard, which does not mirror what I see in my travels. It's possible there is a selection bias at work.
There were a lot of interesting comments; alas, far too many to include. Here are some highlights:
All new code is written to the standard but depending on the project, even some old code is updated. If project is large and requires an in-depth study of the old code for its reuse anyway, it makes sense to update formats, naming and comment. If the project is just to add a small feature or update to an old project, then we don't update the format. It is much less frustrating to support code that was created under a good standard too!
Standards, for us, are more about producing consistent code amongst developers, code that avoids easy mistakes and code that can be used across different platforms - this makes MISRA very useful indeed. Lots of rules seem excessively prohibitive but with a bit of digging and research, their place can be understood. C is not a language for show-offs. You may know a quirky, succinct C snippet that achieves the same job in half the number of lines but if no other developer can follow it, or it is prone to common C pitfalls, then you've not saved any time. MISRA has helped us churn out reams of, honestly, dull code but this is code that *works*.
We use the tool QAC. No deviation/approval process as it is a small team. Deviations required by low level hardware, processor access or conflict between tool and compiler are 'tagged' using the tool syntax tags so they are partially hidden for convenience. In this way non compliant lines are annotated in code with the tool summary showing them. Code changes can be checked to '100%' compliance without wading through known non-compliances.
I use MISRA as a "best practices" guide. Much of the code I work with is legacy, and the effort to bring it into MISRA compliance can not be justified. However as I work with the code--modifying it, extending it--I use MISRA as a guide to write the best possible code I can.
I use MISRA as a guideline - it helps what I call "responsible engineering" in that MISRA makes you think "am I doing this in a responsible way?". And I care more about that than blindly following obtuse rules. Any monkey can blindly follow rules - but an engineer THINKS about what he/she is doing. And, an engineer can COMMUNICATE what he/she thought and did.Some of these rules also make the basis of some interesting interview questions to separate the can-code'ers from the engineers with real talent.
With multiple resources working on a single project, it becomes difficult to train each of them into using the standard. Some of them are engrossed in solving multiple bugs that they forget to follow the standard and instead become very defensive in coding to such a limit that they are not even ready to add comments in fear that this would introduce more bugs in a working code. :)
We use a variety of standards over a variety of programmes, coding and general development Many are specific to the company I work for but can be traced to many other 'standards'. Most standards will add an overhead initially, but finding a bug/issue during code review is just so much cheaper than doing so when the product is in service. I could go on for ages arguing about many of the points made, but to pick up of just a few:
My engineering department has a sort of "coding standard" written years ago, but no one follows it. The department belief is that standards destroy a software engineer's creativity.
I design small embedded products that use primarily PIC controllers with firmware written in assembler. Although I try to use the best practices that I read about, I am not aware of a firmware standard that is applicable to code written in assembler. That said - I'd like to be shown that I am wrong about this and that there is indeed a standard that I can learn from and use.
We are currently developing all safety related code in assembly to avoid the "certified compiler" unavailability on our microcontrollers. All the code is reviewed by other department colleagues and submitted to third party assessors.
I've been doing embedded design for 20 years and the team has always been at most 2 people. The need for a formal standard has not shown itself. I have looked at them and have always found them to be too subjective, full of exceptions and lacking in realistic reasoning.
This is largely a DO-178 shop, so we're obligated to have some kind of coding standard. The one commonly referenced is an internal document of some 30 pages; incorporating some prohibitions of DO-178 (recursion comes to mind), some style points (indenting), but nowhere as involved as MISRA. So: throw in a pile of college-hires, and the code ranges from wretched to perverse... They used to bring in veteran contractors like myself for "verification" once the early hw/sw integration was done, but that's a little late for any process effect. And, I'm seeing bug rates in the 1% range for this "integrated" code; granted, lots of silent bugs, but frightening nonetheless.
Picked at random from the survey respondents, Scott Becker won a copy of Software Engineering for Embedded Systems.
|Thoughts on Software Engineering|
Some readers had great comments about software engineering which they kindly allowed me to share.
Jerry Trantow wrote:
Ray Keefe wrote
After we emailed back and forth a bit, Ray added this:
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intents of this newsletter. Please keep it to 100 words.
|Joke For The Week|
Note: These jokes are archived at www.ganssle.com/jokes.htm.
From Jordin Kare:
If you connected every electrical device in the world end to end...
...you'd have a World Series.
|Advertise With Us|
Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at firstname.lastname@example.org.
|About The Embedded Muse|
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at email@example.com.
The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at firstname.lastname@example.org for more information.