Electronic – What tools or standards can be used to improve embedded C code reliability

ccodeembeddedreliabilitystandard

I typically program PICs in C, usually for switched-mode converters. I've heard of various static analysis tools and standards like MISRA C that can be used to help improve the reliability of code. I'd like to know more. What standards or tools might be appropriate for my context?

Best Answer

Embedded code validation is tricky, especially when dealing with limited-resource parts like PICs. You often don't have the luxury of coding in test cases due to the memnry constraints of the part and the often "real-time" programming done on these sorts of devices.

Here are some of my guidelines:

  1. Write a spec if there isn't one: If you're not coding against a spec, document what your code is supposed to, what are valid inputs, what are expected outputs, how long should each routine take, what can and cannot get clobbered, etc. - a theory of operation, flowcharts, anything is better than nothing.

  2. Comment your code: Just because something is obvious to you doesn't mean that it's obvious (or correct) to someone else. Plain-language comments are necessary for both review and code maintainability.

  3. Code defensively: Don't just include code for normal inputs. Handle missing inputs, inputs that are out of range, mathematical overflows, etc. - the more corners you cover by your code design, the fewer degrees of freedom the code will have when deployed.

  4. Use static analysis tools: It can be humbling just how many bugs tools like PC-lint can find in your code. Consider a clean static analysis run as a good starting point for serious testing.

  5. Peer reviews are essential: Your code should be clean and well-documented enough that it can be efficiently reviewed by an independent party. Check your ego at the door and seriously consider any criticism or suggestions made.

  6. Testing is essential: You should do your own validation, as well as have an independent validation of the code. Others can break your code in ways you can't possibly imagine. Test every valid condition and every invalid condition you can think of. Use PRNGs and feed garbage data in. Do whatever you can to break things, then repair and try again. If you're lucky, you'll be able to run your code in debug mode and peek at registers and variables - if not, you'll need to be crafty and toggle LEDs / digital signals to get an idea of the state of your device. Do whatever is necessary to get the feedback you need.

  7. Look under the hood: Don't be afraid to look at the machine code generated by your C compiler. You may (will?) find places where your beautiful C code has blown up into tens if not hundreds of operations, where something that should be safe (since it's only one line of code, right?) takes so long to execute that multiple interrupts have fired and invalidated the conditions. If something becomes horribly inefficient, refactor it and try again.

Related Topic