Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
logo The Embedded Muse
Issue Number 248, November 4, 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

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

Quotes and Thoughts

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning." - Rick Cook

Tools and Tips

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

Chris Svec has written an under-the-hood look at FreeRTOS. He writes:

You might be interested in a chapter I wrote about FreeRTOS's internals for "The Architecture of Open Source Applications, Volume II", an open source book about open source software.

The chapter is free and available here.

And the book is also free.

The FreeRTOS chapter is about the guts of FreeRTOS; it is *not* about how to use FreeRTOS.

Nick Lott wrote about a nifty diagramming tool:

Just wondered if you had seen Wavedrom over at google code?

The address is and you can try it out online at

I recently needed to "sketch" up some timing information for a protocol I was documenting at work and found it the perfect tool for quickly getting a nice looking but basic timing diagram done without having to mess about actually drawing the waveforms manually.

A reader who wishes to remain anonymous had two suggestions:

I worry a bit about the increasing "cloud-iness" of our data, some of which might be sensitive or even proprietary. I guess that's why I'm reluctant to share stuff via Google Docs, Amazon Cloud Drive, and maybe even Dropbox. But then again, I have a piece of password-management software (Roboform Everywhere) that encrypts my passwords and any other info that I want "safely" to the cloud, where I can easily get to it using any browser...

I noticed that the PDF tools you mentioned are online-only. For those who prefer a tool that executes on your own PC without having to use the cloud, check out . I find it very helpful, and basically anything you can print can get turned into a .pdf file.

I asked about iPad and Android apps for electronics and firmware. Dan Swiger wrote about some for Android:

The apps I use most are: ASCII Table (yeah, there's an app for that), RealCalc (pretty decent scientific calculator with great conversions with data sizes being the most useful for me), TimeCalc, and Now and Then (basically "DateCalc"). I also use ColorNote to replace a short-term engineering notebook... I'm a poor writer (can't even read my ALL CAPS SCRIPT some days) so the swipe action is much more effective for me... talk about COOL technology: swipe! The sound meter has been useful a time or two as well, determining how loud a fan is... the app isn't good above 84dB (useless vs. my car stereo), but I suspect that to be a hardware problem. It is, however, good for lab-level fan noise. I'm in the radio business, so there are a few cell tower trackers and some GPS apps which are pretty interesting, if for nothing more than showing me the GPSs with which I integrate are of better quality than the ones in the phone.

Kyle Bostian wrote:

I'm an Android user, and I've come across several helpful apps for electronics and embedded engineering. ElectroDroid is great for reference information on connector pinouts, wire size and ampacity, and the like. It includes a nice ASCII table and calculators for several common formulas. I find myself using it when I'm away from my desk or bench, such as answering questions on the factory floor or in meetings. It's available in a free ad-supported version.

Viewing CAD data on a phone is painful but it can be useful to view a Gerber or DWG that comes in as an email attachment in a pinch. There are many choices on the DWG side, but my favorite is GstarCAD MC. It loads quickly and scrolls nicely, even on a low-end phone.

There are many HP calculator emulators available. If I'm at my desk I still use a real HP35 but if I'm anywhere else I use my phone and Free42 by Thomas Okken. It's fast and has no annoying ads. I haven't found a 16c or 12c emulator that I like but they're out there.

Nuts & Bolts is an app that has data on just what it says. I've taped a tap chart on every drill press I use but they always fall off... now, I just look at my phone. (Not electronics per se, but the real world is still held together with threaded fasteners.)

Everything else I've used, from Wifi Analyzers, to Smith Chart Apps, to Audio Analyzers, is what I would call a novelty. They might be fun to play with, but it is hard to call them useful.

What I'm Reading

A driver was cited for driving while wearing Google Glass (and speeding).

Software-controlled caches could speed processors and save power.

John Donovan has a nice look at the ultra-low power MCUs that are available.

A Response to "Failure is an Option"

Ben Meyer had this to say in response to my musings about failure last issue:

I fully agree, and as a software engineer it disheartens me that so much is done in software with such a great failure rate. We really should be doing better. Personally, I think it comes down to a matter of practicing software as a discipline instead of an art. No, that doesn't mean doing software in the way Carnegie Mellon defines "Software Engineering", which is simply not economically feasible for anyone but NASA; but it does mean:

1. Writing code with purpose, and knowing the purpose behind what you write.
2. Designing the code purposefully, not haphazardly.
3. Sticking to you guns about features and what will be done when (e.g. controlling feature creep).
4. Using a version control system so changes can be managed, even reverted when necessary.
5. Working together as a team, following the coding style of the team not your own.

Too often I run into programmers/software engineers/etc that look at programming entirely as an art. They want to do things their way and only their way. If the team has a coding standard that doesn't match their own, then they do their own - the team be damned.

Too often I run across projects that do version control by copying around directories of the software instead of using free tools like RCS, CVS, SVN, git let alone the many for purchase tools (TFS, PerForce, ClearCase, BitKeeper, etc).

With attitudes like these, and so much lack of control it's amazing that the projects that do succeed do. It's amazing companies like Microsoft have existed at all, let alone for so long. And it's amazing that the public at large (and companies in particular) allow projects to be so poor in delivery, and that companies are allowed to put things in their licensing saying they are not at fault for anything the software does (they should be when it doesn't work as advertised).

What is equally amazing is that the big open source projects that are successful share little on that list. Yes, they often share much of that list as they get going, but as they mature they quickly adopt version control systems (usually git or subversion), get their releases down to schedules, and make anyone contributing adhere to their coding standards (style, etc.). It's high time that companies started learning from projects like the Linux Kernel, QT, Subversion, Apache HTTPd, and many others.

And it's time that the software community as a whole learn to be more disciplined about what they do. There is no space for "Computer Science" in business - it's great in Academia and pure Research, but when it comes to delivering projects we really need to be doing Engineering and not Science; the big difference is practicing the art through a disciplined approach.

Of course, this will only be fixed if both software engineers push for it and follow through; and companies adopt the required practices to enable those environments as well. Without support from Management, companies have little hope of fixing these structural problems that plague the software industry.

When Faster is Slower

Phillip Armour's column (When Faster Is Slower) in the October 2013 Communications of the ACM made some great points. A quote: "Faster development tools may paradoxically increase the time to complete programming tasks."

This has been my observation. In ancient times programmers keyed their programs, one statement per card, on punched cards, which were then submitted to the computer center. A typical run had a 24 hour turnaround. No one could afford dumb mistakes with that cycle time, so the notion of "playing computer" surfaced. The developer would get a listing and execute the code in his head, very carefully, looking for mistakes.

Fast forward to today and the situation is very different.

You're sitting there, feet up on the desk, IR keyboard at hand and lots of windows open on the 24" monitor. Run into a bug, and maybe changing that ">=" to ">" will fix it. Make a change and in a few seconds you're debugging again. If lucky, the patch won't work. Did you isolate the real problem with those three seconds of thought? How do you know?

We need debug logs. When a problem surfaces, write it down. Write down what you learn from trace data, single-stepping, and other debugging strategies. When the fix is clear, don't implement it. Write it down, first, and then key it into the IDE. Now, with 30 seconds worth of thought, the odds of getting a correct fix increase.

Have you ever watched a developer spend days chasing a bug? Inevitably he'll forget what tests he's run, what variables he's looked at, and repeat the tests. A debug log makes this impossible.

Finally, go over your log every 6-12 months. Patterns will appear. Identify those, so you don't make the same mistakes again.


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

Bob Lee sent this: Do you know why surgeons like to operate on engineers? Engineers understand when you put things back together and have a few parts left over.

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.