Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
Issue Number 281, April 6, 2015
Copyright 2015 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

Editor's Notes

After over 40 years in this field I've learned that "shortcuts make for long delays" (an aphorism attributed to J.R.R Tolkien). The data is stark: doing software right means fewer bugs and earlier deliveries. Adopt best practices and your code will be better and cheaper. This is the entire thesis of the quality movement, which revolutionized manufacturing but has somehow largely missed software engineering. Studies have even shown that even safety-critical code need be no more expensive than the usual stuff if the right processes are followed.

This is what my one-day Better Firmware Faster seminar is all about: giving your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. Information here shows how your team can benefit by having this seminar presented at your facility.

Undo ad

(I had an incorrect link to this white paper in the last Muse. This one is correct).


Quotes and Thoughts

"It is not necessary to change. Survival is not mandatory." - W. Edwards Deming

Tools and Tips

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

I read Steve Leibson's Xilinx-focused blog every week. In it he recently referenced a new book about the Zynq FPGA. Adam Taylor has been exploring the Zynq and writing about his experiences. The book is a compendium of his journey and is a must-read for those interested in this device. It's only $7.50 in a Kindle edition. I bought it and am impressed: it's well-illustrated and covers a lot of material. The Zynq has twin Cortex A9s, FPGA fabric, and a lot of I/O. Adam covers both hardware design side and software.

Security talk is hot today; security engineering less so. Scott Romanowski offered a resource:

For a free resource to help get us embedded engineers thinking about security, Ross Anderson's book, "Security Engineering" (2nd edition), is free online at Each chapter of the 1000-page book is a separate PDF file.

(Thanks to Bruce Schneier's blog for that link.)

David Meekhof suggested checking out Unity for building tests:

Regarding your comment on there being few Automated Embedded Test tools out there, check out the free "Unity" tool at

My friend Mark Vandervoord (a.k.a. "Dr. Surly") is one of the co-developers of it, and it is featured in James Grenning's book: They are launching not-free webinars:

More people have suggested screen capture tools. Amir Marandi wrote:

In "Tools and Tips" many times snagit, snipit, dropbox, and Window screen capture have been mentioned but nobody mentioned "Greenshot". It is an excellent software and freeware. It does rectangle, windowed, and full screen capture with a nice set of highlighting and annotation.

I have used it for many years. Please give it a try.

Les Hildenbrandt suggests a built-in tool:

On the snipping tool, I hope this is not too obvious. In windows, <SHIFT> print screen captures the entire desktop, but <ALT> print screen only captures the currently active window.

John Johnson suggested:

For basic & simple image editing, i.e. cropping screen capture, I use Paint.NET.

CNET: Paint.NET is a full-featured image editing program ...
Wikipedia: Paint.NET is a freeware raster graphics editor software for Microsoft Windows ...

Diego Serafin suggests a different sort of tool for pasting:

Pure Text is a tiny application sitting silent on the desktop bar (reminds me of a TSR, Terminate and stay resident of old DOS days…). When you copy some text or excel cells using CTRL-C, using Windowskey-V instead of CTRL-V to paste it removes all formatting leaving only the “pure text” hence the name.

I found this little tool just *great* when working on excel sheets full of data to move around or when pasting text between word documents with totally different formatting/font/highlighting/whatever, or doing the “unpredictable results copy” from excel to word or vice-versa.

Richard Tomkins had four suggestions:

Microsoft OneNote (Windows icon) + S

Screenshot Captor



On "Done"

In the last Muse I wrote about the notion of "done" in projects. Readers had comments. Phil Matthews wrote:

In high school I had a friend who was a brilliant cartoonist, usually on the blackboard (remember them?). Whenever he did a cartoon he would first stare at the space where the drawing would go for several minutes, then quickly draw in the lines accurately and perfectly. The first draft was the finished article. I asked him about this once and he told me, "I do the cartoon completely in my head first and then project it onto the paper. When I'm drawing I'm just tracing the lines".

There is a similar story in "The Shipping News", where the main character, Quoyle, commissions a boatbuilder to build a small wooden boat for him. After several visits he is dismayed to see no progress, nothing even started. The boatbuilder assures him the boat is nearly finished, in his head. Once the boatbuilder is satisfied with every detail, he starts shaping the wood and boat goes together very quickly. (I thought you might appreciate that Jack, since you are a sailing person).

I believe this way of thinking has merit for writing software, although from experience I know it is hard to justify a lot of time with no obvious output to managers. It doesn't mean you don't do testing. However, when it comes to testing, the software is more likely to work first time and have fewer bugs. The other extreme is continuous hacking and testing with plenty of output but no clear definition of when it is finished (been there, done that too!).

Howard Speegle contributed this:

Like the programmer you mentioned, I also like to work out everything in my mind before coding and the path between knowing what to do and actually walking the defined path can be tedious, as you noted.

However, you also dropped a comment about management "lopping off" some of the schedule. In my experience, most employees do their best to estimate the time it will take to do something based on their estimate of the degree of complexity involved and the amount of new knowledge that will be required. This is the estimate they give to management. It does not include "Oh, by the way"s or the frequent, "Could you work this in for me?", and certainly not the "lopping off" bit.

When the schedule extends past the calendar date management has passed on without adjusting for past history regarding the lack of correlation between that individual's estimates and actual calendar days spent since start of the project, guess who is blamed? For some reason, many managers appear to think that programmers can be forced to be more productive through clever manipulation by management. They also seem to share the curious notion that they can ask for additional tasks to be completed during the project that will not affect the time required to complete the project.

Some of the worst examples of this idiocy I have encountered were practiced by some of the same people who had experienced the problem from the other end. Perhaps our concepts of management and labor need to be re-examined?

Every manager needs a sign on his office wall that reads, "No problem" does not mean that it will not require time and money to implement your request. It simply means that the person sees no technical difficulty in complying.

Daniel Wisehart uses some agile ideas:

On "Is it Done Yet?" I feel the pressure--and shame--from making bad time estimates myself and I now see people who work for me painting themselves into the same corner.

Automated testing would be helpful but a lot of testing software has more bugs than the DUT, simply because the testing software is thrown together fast and dirty. Much of the debugging we do when a test shows errors, is figuring out that the test gave the wrong inputs or expected the wrong result.

What I find helps a great deal is pulling the question back to a scope and a timeframe where an engineer can see all of the factors involved: "What can you deliver this week?" and "If that goes well, what can you deliver next week?" Then it is up to me to see the rate at which we are making progress, the difficulty of the tasks ahead and be the fool to estimate the time until task completion, but only with the details of how I arrived at that estimate. Since my company does a good bit of research, the people asking for the estimates have to understand the consequences of not even knowing yet what all of the difficulties are.

More About Discipline... and MISRA C

Responding to some comments in Muse 279 about discipline in software engineering, Chris  Hills wrote:

I have to agree with the comments on discipline in the newsletter.

In particular those by Dave Telling. I too had a technical military background as did my father who was involved in the design of aircraft jet engines, who also said that discipline was one of the most important traits in design. Short cuts in jet engine design could be fatal! Having discipline makes life a lot easier as many things can be done properly and automatically. Couple this with a good process and things become very efficient; things just work and you get fewer errors (bugs).

As for his comments on MISRA-C: Overall they [the MISRA-C rules] work. He mentioned relaxing some of them. Yes this is required! There are only 10 Mandatory rules. The MISRA-C team recognised that not all the rules are appropriate 100% of the time in fact my first conference presentation after the launch of MISA-C:2012 was Why MISRA-C might kill your project!

It is because many just see MISRA-C as a tick box and do not apply it with care, relaxing rules (with written justifications or deviations) as needed. If you apply 100% of the MISRA-C rules 100% of the time you get MISERY-C but you have only yourselves to blame. This second paper does explain how to implement MISRA-C:

One of the main problems is no one really understands C. I covered this in the presentation MISRA-C Curse or Cure: Ask any set of programmers which book to use to learn C and most will say K&R despite it being published over 26 years ago before ISO C90, C99 and C11. It is also about 1/3 the page count of the current C standard (and has smaller pages). ISO-C** is a language definition like a dictionary yet very few programmers have even seen a copy let alone own one. So where did programmers learn their C? By word of mouth? Trial and error? From a book that only covers a fraction of the standard? Also as the Curse or Cure paper points out static analysis (lint) was invented in 1976 and intended to be part of the compile chain. It is also usually rule 1 in the programmers 10 commandments. How many programmers have the discipline to run static analysis before every compile and if not why not? We are back to discipline again.

I have not seen a survey or study about how developers learned C, but admit to having a copy of K&R here, in addition to many other books about the language. Chris is right about the standard; few software engineers I've talked to have a copy of any of the C standards.

The C standards are outrageously expensive and drearily dull. They are available on-line for free from some sites, but I don't know if these infringe a copyright. Wikipedia links to drafts that are very close to the final versions; for instance, a draft of C99 is available here. Though they are impossible to read straight-through, it's useful to look at different sections from time to time to improve your skills.

Some argue that they write with a simpler subset of the language to avoid corner cases that a language lawyer might use. I agree; for example, code is clearer when parenthesis are used instead of the arcane precedence rules. Some things might surprise, though. Do you know why the following probably won't work?

if  ((i >= 0) || ((i++) <= value)) /*  code */;

C99 standard explains why: the logical OR operator will not evaluate the second part of the decision if the first part is TRUE, so the postincrement won't happen.

BRM wrote:

This is a big area for me. I think too often the entire Computer Programming Field (Software Engineers, Programmers, etc) view it too much as "art" and therefore write off anything related to "discipline" as interfering with the "art". Thereby, it only perpetuates the problem. The challenge is that I think the field needs to simply "grow up" and mature. The field - in all forms - is relatively new compared to any other similar field, even Electrical Engineering, it's closest relative and sibling. Developers need to realize that it is not an "art"; but it's a disciplined, pragmatically driven field where code-styles need to be enforced, and if you don't like it, then oh well, get in line and do the job; where code logic structures need to be done and enforced such that best practices are performed and bring out the best software with deterministic outcomes and nothing is left to chance. And the list goes on. I've probably written to you about this prior as well. Sadly it will probably be another several decades before these things really come to pass; and sadly too often we just limp about when we could be fixing the broken bones in our collective bodies of software.

Computer Approximation Resources

John Hart's Computer Approximations is my go-to source of polynomial coefficients for all sorts of mathematical operations. Michael Taylor has some useful thoughts:

The book Computer Approximations by John Hart is available as a reprinted edition from Krieger Publishing, ISBN-10:0-88275-642-7 ISBN-13: 978-0882756424 and Amazon. The reprint is dated 1978, rather than 1968 for the original Wiley printing. It apparently contains some (minor) corrections. The biggest benefit is besides being cheaper than used copies of the original edition in many cases, it is printed on acid-free paper so hasn't turned yellow, and as still available
("in-print") as new, including from Amazon for ~$85 USD.

That all said, I would suggest anyone wanting to learn about computing approximations techniques would be better served by Elementary Functions: Algorithms and Implementation 2nd ed. by Jean-Michel Muller (2005) which gives a state-of-the-art perspective, yet is still largely accessible to the software professional without an advanced mathematics background. Given that it is nearly half the price (~47 USD at Amazon) and far more up-to-date discussing contemporary processors and operating systems it is easy to recommend as a very suitable alternative or rather replacement to Hart's Computer Approximations. It is more theoretical than Hart, but given the availability of freely available (and often multiple public domain) implementations of varying quality in this age, the understanding is perhaps more scarce than the techniques or implementations.

Jean-Michel Muller, also has a second related but different book on floating point arithmetic itself, Handbook of Floating-Point Arithmetic (2009). This is the best technical background on floating point mathematics that I know of. It also is one of the few detailed written explanations on floating point numbers, arithmetic, and techniques that covers that revised IEEE 754-2008 floating point specification. It also covers floating point arithmetic in hardware, though at the theoretic, rather than concrete level (it is not a Verilog/VDHL cookbook of techniques). Highly recommended for anyone in scientific programming or needs to really understand floating point calculations.

The description of Elementary Functions sounds wonderful, and I have ordered a copy.

Wanted: Employees Who Can Do Everything

A reader who wishes to remain anonymous complained about a job posting in the last Muse:

We in the embedded systems world are used to what I call cross-domain job requirements. The job posting in Muse 280 is an example of cross-domain job requirements.

In in the embedded systems we blend technologies from electrical engineering, mixed signal, high-speed digital, VHDL, software design aka firmware, PCB layout with balanced impedance traces, RF, etc. And this blend of cross domain skills is sometimes executed well.

Sometimes not.

Though from an IT / software perspective, this article and the comments which follow illustrate this trend.

Re: excerpt from job posting for a web developer
* Writing back-end Ruby code
* Turning PSDs into beautiful UIs

A quote about job descriptions from that article got my attention: "Managers just don’t have the time to put them together."

I'd argue that the most important role of a manager is in finding, retaining and motivating people. A manager without time to put a job description together is simply not doing his or her job.


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. There is no charge for job ads.


Joke For The Week

Note: These jokes are archived at

Kevin Clark sent this amusing screen shot:


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.