Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
Logo The Embedded Muse
Issue Number 238, March 18, 2013
Copyright 2013 The Ganssle Group

Editor: Jack Ganssle,
Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for noncommercial purposes. For commercial use contact To subscribe or unsubscribe go to or drop Jack an email.

Editor's Notes

The average embedded software project devotes 50% of the schedule to debugging the code. It's stunning to realize that half of the project's time is wasted fixing mistakes.

Perhaps the other half should be called "bugging."

Unfortunately that debugging just doesn't work. Most organizations ship with about ten bugs per KLOC, two orders of magnitude worse than best-in-class outfits. A focus on fixing bugs will not lead to a quality product.

How do you get projects done faster? Improve quality! Reduce bugs. This is the central observation of the quality movement. The result is a win-win-win: faster schedules, lower costs and higher quality. Firmware engineering, too, can - and must - profit from the same win-win-win.

Learn how (and far more) at my Better Firmware Faster class, presented at your facility. See


UBM (the company behind, EDN, EETimes, etc) recently did their annual survey of the embedded marketplace. I'm sure many of you responded to it. They are presenting the data in a webinar on Tuesday, March 19 at noon Eastern Time. More info here.


Quotes and Thoughts

"Engineering is done with numbers.  Analysis without numbers is only an opinion." - David Aikin

Tools and Tips

Please submit neat ideas or thoughts about tools, techniques and resources you love or hate.

John Paul wrote:

"Understand" by SciTools. I've been using this tool for just over two years and it is excellent. Especially useful when making modifications to a code base that you have little knowledge of, it helps you get a bigger picture of the code set.


What I'm Reading

Optimizing clock tree distribution in SoCs with multiple clock sinks - An interesting analysis of clocks in SoCs.

SEU Mitigation Testing of Xilinx Virtex II FPGAs - Cosmic rays and their effects on some types of FPGAs.

Power Challenges May End the Multicore Era - Is multicore doomed? This is a scary analysis of a possible near-term future. Communications of the ACM, February 2013 pg 93-102 (subscription required). And this is my analysis of the article.

Dealing With Common Code Bases

Thanks to so many who responded to Bob Lee's question about dealing with common code bases.

Chris Lawson wrote:

In The Embedded Muse 237 one of your readers asked for articles on "dealing with common code bases". The first thing that came to mind was a webinar series Gary Stringham did for the Design News (Digi-Key) Continuing Education Center. The 5-part lecture series on "Writing Reusable C Code for Embedded Systems" is archived (presentation slides and streaming audio) here.

Ian Rumley suggested LinkedIn:

On the question "on dealing with common code bases" there was a good discussion on this in the LinkedIn group "Firmware"; search for "Firmware for Product Variants." See this.

Dave Sudolcan wrote:

For Bob Lee and his search for references dealing with common code bases, Team FDI has some well crafted code that he could look at. It covers different microcontrollers, PCB's, touch screens, tool chains, etc. Pretty well organized and architected code.

Jäckle Hans had several suggestions:

Regarding the question about the common code base -- I suffer from the same problem. For a long time we have used (almost) identical copies of source files for different applications based on the same hardware. Lately, I have tried to eliminate this multiplication by using a combination of inheritance (C++) and configuration but I'm not happy with this as it adds complexity and some runtime-penalty. So I'm also interested in what my fellow readers suggest.

Lately, when looking at templates and some metaprogramming, especially the mixin pattern, I stumbled upon the term "Software product line" or "product line architecture" which seems to go into the direction I'm looking for.

This is the first paper that I read:

Another page.

And another.

A book (haven't read it).

I haven't read all of this and I'm not yet close to understand it all but maybe it could help Bob Lee in some way.

Mike Davis had some different ideas:

Regarding "Bob Lee asked about references for dealing with common code bases. I couldn't think of any; does anyone have some suggestions?", I don't know of any publications that explicitly address that question, but I can suggest two ideas:

a) Any OTS software that already solved that problem, e.g. an embedded OS, will demonstrate some simple patterns that help, like typedef-ing integer types so you can avoid compiler/processor variations in bit-width. I keep the fourth printing of uC/OS by Jean Labrosse around for such references.

b) Somewhat tangentially, and confined to C++, "Large Scale C++ Software Design" by Lakos offers some applicable abstraction techniques. Note: I find this tome hard to read, but worth the attempt, since I've found the techniques are useful beyond large scale applications.

Chris Jones also liked Gary's webinar:

One of your writers asked about dealing with common code bases. A few months ago I attended (if that is the right word) a webinar series dealing with some of those sorts of issues, titled "Writing Reusable C Code for Embedded Systems". It was November of 2012, through the Design News / Digi-Key Continuing Education Center, presented by a Mr. Gary Stringham. I thought it was an excellent overview, and some great ideas at lower levels as well.

He gave personal examples from his days working on printers. As we all can probably imagine, some code is the same for the big lasers as for small desktop models, for color as for b&w, etc. etc., but some different. Sometimes they had the same chip to run on, sometimes slight differences, and so forth. He covers a couple of different types of reuse, for example the API or library approach (not the terms he used) versus the copy and modify, etc., together with pluses and minuses of each.

Worth a read and a listen - you may have to register, but you can still get access to his slides and the audio recordings. Hopefully this link will work -- Here is a link to the first day.

Carol Markert sent this:

Although it has been several years since I read this book, I remember it being very interesting and it spurred me to give a presentation to our engineering group.

"Software Product Lines, Practices and Patterns" by Paul Clements & Linda Northrop. Luckily, it is still in print.

Manju Harapanahalli has a Windows/Linux-like solution:

We have solved a similar problem, by breaking down the code in to .dll on windows and .so files on linux. Each platform or processors has a .dll or .so file and a main program/ application which loads .dll based on the platform or processor the software runs on

This link will be a good starting point.

Benjamen Meyer also suggests Linux:

Per the "Dealing with Common Code Bases", I think the best reference out there would be the structure of the Linux Kernel. It perhaps does more of these things than any code base out there, and does it very well - supporting more processors than any other operating system kernel, having more features to choose from (at compile time) than any other operating system kernel, and supporting more hardware in its own code base than any other operating system kernel. I'm sure it will be hard to find a book about it, but why not look at one of the most successful software projects in the world that does those very things? I'm sure we could all learn a bit; and may be one day Linus or one of his lieutenants will write a book about it and what they have learned over the years as the project grew.

Vishwanatha M S wrote:

Many of us are aware of the organization AUTOSAR (AUTomotive Open System ARchitecture).

The idea is to have common architecture among automotive OEMs and suppliers. It has a pretty good set of APIs from application software through hardware drivers.

There are, however, many disadvantages. Notably bloated code, not clear non-functional requirements such as timing etc.

The specification set is available for free. But to claim AUTOSAR conformance, one has to be a member.

Nevertheless, this is a good beginning in architecting a software platform.

Embedded Blogs

We live in an age of gushing information, where anyone with a computer can be a publisher, and too many are. It's impossible to follow all of the useful web sites out there! But it's important to stay up with developments and thoughtful postings. My approach is to devote a bit of every Monday morning (when not traveling) to the sites I find most useful.

I don't follow any video blogs, even though some are great. They're just too time-consuming; it's much faster to read than to watch. And it's even faster to skim the written word to see if a posting is worth my time than to do the same for a video. Dave Jones has a very popular video blog,for example, and I wish I had to time to tune in.

I also skip audio podcasts for the same reason. The upside of working from home is no commute, but if I did drive to work I'd fill that time with some of the podcasts that are available. One fun one is the Amp-Hour.

Here are the blogs and magazines I check out each Monday:

  • IEEE Spectrum magazine. Occasionally there's a fascinating article. Few are directly applicable to my work. The site does have an embedded corner, but it's usually pretty devoid of interesting content.

  • Though Embedded Systems Design magazine folded last year, this site continues to provide the same content.

  • Embedded Technology Journal. I skip the "Fish Fry" podcast (and don't get the odd name it has), but find a lot of the written content worthwhile.

  • ACM Queue - The content changes very slowly but there's often something of interest about general software engineering.

  • Low-Power Design. The main page is entirely press releases, but the contributors are often interesting. I've been following Steve Leibson's writing since long before there was an Internet.

  • Microcontroller Central. Like so many sites it can have a lot of chaff, but there's usually something of interest.

  • The CPU Shack. Completely useless from a keeping-up-with-technology standpoint. It's a weekly posting of a bit of historical CPU information. I'm fascinated with the history of technology in general, and of the silicon industry in particular, so find this a great site.

  • All Programmable Planet. Another UBM-owned site aimed at the niche market of programmable logic. I keep hoping for more in-depth tech reporting, but there is a useful posting from time to time.

  • Better Embedded Systems. The content changes very slowly, but when it does it's always worthwhile.

  • EE Web. This is a very useful site. There's a lot of marketing blather, though I find enough useful product announcements to keep reading it. The site also does a lot of basic EE instruction. Much of that is elementary, but some is useful. Count on a fair number of self-serving "articles" written by vendors about their own products. Some of those would be great if they were more in-depth.

  • Embedded in Academia. John Regehr, an associate professor at the University of Utah, has done some really important work which is highlighted in this blog. It's updated frequently, though sometimes with trip/vacation reports with pretty photos that aren't useful to embedded people.

  • VDC Research. This site often has useful info on the business side of electronics.

  • Chip Overclock. It's hard to say why I read this, but the quality of the writing is so high that I keep coming back.

  • Software Safety. This is Bob Paddock's blog. It's more often than not not about software safety. Lately Bob has been posting a lot about licensing engineers. It seems that here in the USA many state governments are out to make it illegal to be called an engineer if you're not licensed. Here in Maryland you need a license just to cut hair, so their efforts will probably succeed.

  • EDN. This is one of the oldest electronics publications, and still full of great content.

  • Threat Post. This is a laundry list of recent security breaches. It's updated many times a day. Depressing, really, when one sees how poor computer security remains.

  • SemiWiki. Lots of useful content about what's happening in the semi industry. I find none of the articles explore the subjects in enough detail, but with 450 mm wafers not too far off and 14 nm geometry coming soon it's important to stay connected to the fab world.

  • xkcd. Funny tech comics.

What are your favorite sites?


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

From Dick Selwood:

I am sick and tired of this machine
I wish that they would sell it
It never will do what I want
But only what I tell it

Advertise With Us

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at

About The Embedded Muse

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at

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 for more information.