An Update on Toyota and Unintended Acceleration

In early 2011, I wrote a couple of blog posts (here and here) as well as a later article (here) describing my initial thoughts on skimming NASA’s official report on its analysis of Toyota’s electronic throttle control system. Half a year later, I was contacted and retained by attorneys for numerous parties involved in suing Toyota for personal injuries and […]

Read More

Trends in Embedded Software Design

In many ways, the story of my career as an embedded software developer is intertwined with the history of the magazine Embedded Systems Design. When it was launched in 1988, under the original title Embedded Systems Programming (ESP), I was finishing high school. Like the vast majority of people at that time, I had never heard the […]

Read More

Building Reliable and Secure Embedded Systems

In this era of 140 characters or less, it has been well and concisely stated that, “RELIABILITY concerns ACCIDENTAL errors causing failures, whereas SECURITY concerns INTENTIONAL errors causing failures.” In this column I expand on this statement, especially as regards the design of embedded systems and their place in our network-connected and safety-concious modern world. […]

Read More

Combining C’s volatile and const Keywords

Does it ever make sense to declare a variable in C or C++ as both volatile (i.e., “ever-changing”) and const (“read-only”)? If so, why? And how should you combine volatile and const properly? One of the most consistently popular articles on the Netrino website is about C’s volatile keyword. The volatile keyword, like const, is a type […]

Read More

Don’t Follow These 5 Dangerous Coding Standard Rules

Over the summer I happened across a brief blog post by another firmware developer in which he presented ten C coding rules for better embedded C code. I had an immediate strong negative reaction to half of his rules and later came to dislike a few more, so I’m going to describe what I don’t […]

Read More

How to Enforce Coding Standards Using PC-Lint

In an earlier blog post, I introduced the concept of automatic enforcement of coding standards by stating 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. … To ensure your selected coding standard is followed, and […]

Read More

Is “(uint16_t) -1″ Portable C Code?

Twice recently, I’ve run across third-party middleware that included a statement of the form: uint16_t variable = (uint16_t) -1; which I take as the author’s clever way of coding: 0xFFFF I’m not naturally inclined to like the obfuscation, but wondered if “(uint16_t) -1″ is even portable C code? And, supposing it is portable, is there […]

Read More

How to Enforce Coding Standards (Automatically)

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 […]

Read More

Do Inline Function Bodies Belong in C Header Files?

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 […]

Read More

What NHTSA/NASA Didn’t Consider re: Toyota’s Firmware

In a blog post yesterday (Unintended Acceleration and Other Embedded Software Bugs), I wrote extensively on the report from NASA’s technical team regarding their analysis of the embedded software in Toyota’s ETCS-i system. My overall point was that it is hard to judge the quality of their analysis (and thereby the overall conclusion that the […]

Read More