Barr Code
Michael Barr, an internationally recognized expert on embedded computer design, writes about firmware architecture and development processes that help keep bugs out of embedded systems.
Return to Embedded.com home page.
Trends in embedded software design
Michael Barr
5/2/2012 7:38 PM EDT
As the magazine that catered to embedded systems programmers closes, the future lies in less hands-on programming and more auto-generated code.
I've been hearing the 32-bitters are taking over story for over 15 years now, but the number of ...
Building reliable and secure embedded systems
Michael Barr
3/20/2012 5:49 PM EDT
Neither reliability nor security can be tested, debugged, or patched into a product. They must be designed into embedded systems from day one.
For security to be built-in it has to be underlying, OS-supported functionality, not something ...
Combining C's volatile and const keywords
Michael Barr
2/24/2012 12:25 PM EST
Does it ever make sense to declare a variable in C or C++ as both volatile (in other words, "ever-changing") and const ("read-only")? If so, why? And how should you combine volatile and const properly?
@dave brown: Let me first give you a pointer to one of Linus Torvald's rants against "volatile": ...
Firmware forensics: best practices in embedded software source-code discovery
10/27/2011 10:41 AM EDT
Remember unintended acceleration? Here's what NASA should have examined in Toyota's software.
Adopting a common vehicle hardware and software 'platform+kernel' that is certified and utilized ...
Five dangerous coding standard rules
Michael Barr
9/7/2011 10:40 PM EDT
Don't follow these five dangerous coding standard rules… TODO.
I am not related to Mr. Barr, but man, Ramig972. That stinger really hurt, what has this guy done to ...
How to enforce coding standards automatically
Michael Barr
7/27/2011 1:24 PM EDT
Coding standards are an important tool for fighting bugs. Unfortunately, too many well-intentioned coding standards gather more dust than followers. Automatic enforcement points the way to greater compliance.
I don't understand the rule 4.2.d - "No header file shall contain a #include statement." If you ...
Michael Barr
5/11/2011 6:44 PM EDT
What sorts of things should you (or should you not) put in a C language .h header file? When should you create a header file? And why?
I totally disagree with the last rule "DON'T expose the internal format of any module-specific data ...
Unintended acceleration and other embedded software bugs
Michael Barr
3/30/2011 11:37 AM EDT
Despite the redactions, we can still learn some interesting facts about Toyota's embedded software and NASA's technical review of the same.
Sure you want these things, but are you prepared to pay for them? Every car could have a titanium ...
Social networking for engineers
Michael Barr
2/10/2011 3:16 PM EST
Not all engineers hate Twitter. Many use social media site wisely. Michael Barr, a former editor in chief of Embedded Systems Programming, is an experienced user of social media and offers this guide to social media for the busy engineer.
Sorry hit the submit button too early. I wanted to thank Michael for inspiring me to try this ...
Five more top causes of nasty embedded software bugs
Michael Barr
11/2/2010 10:32 PM EDT
What do memory leaks, deadlocks, and priority inversions have in common? They’re all Hall of Famers in the pantheon of nasty firmware bugs.
@Duane - lone programming is of course bad news. One tip; write a module's code in one language, and ...


