Go here to sign up for The Embedded Muse.

The Embedded Muse 190 - Feb. 15, 2010

You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email at jack@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

Editor's Notes

Are you happy with your bug rates? If not, what are you doing about it? Are you asked to do more with less? Deliver faster, with more features? What action are you taking to achieve those goals?

In fact it IS possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Learn how at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm .

Every year and a half or so computation gets roughly twice as fast for a given cost. The implications of this are dizzying and so profound that they induce vertigo on first apprehension.... This breathtaking vista must be starkly contrasted with the Great Shame of computer science, which is that we don't seem to be able to write software much better as computers get much faster. - Jaron Lanier

On Language

In 2008 the Embedded Systems Conference celebrated its twentieth year. For the keynote Susan Rambo and others put together a really funny video (see www.ganssle.com/misc/esc2008.mov ) where people on the street were asked for the definition of "embedded system."

I long ago gave up describing my job at parties, instead telling folks I'm an engineer. Their eyes immediately glaze over for a moment till they turn to talk to someone, anyone, else.

I bet many of the people who don't know what "embedded" means (in the computer context) spent part of their day driving a car chock full of microcontrollers. They probably gab on a cell phone with a slew of CPUs, while their microwaves electronically count down the minutes till breakfast is cooked. A fabric of smart electronics, all enabled by embedded systems, enrich our lives. Mostly. Admittedly some just add needless complexity. But no person is untouched by the fruits of our labors.

I looked up the word "embedded" in the Oxford English Dictionary (OED), a 20 volume set which forms the definitive description of the English language. This tome was originally published in a massive effort between 1884 and 1928, and has been updated numerous times since then. (For a fascinating biography of the OED read "The Professor and the Madman" by Simon Winchester, a tale of two of the principle characters, one of whom went bonkers and cut off his... well, let's say it's not a book for the squeamish.)

The OED defines embedded as: "To fix firmly in a surrounding mass of some solid material". Apparently both embedded and imbedded are equally valid words, though the former is the more common form. Credit for the first usage goes to imbedded, which appeared in a biology book in 1778. Embedded appeared in 1794 in a text on natural history. Two hundred years ago random spelling was common and accepted, so the two words, which sound the same, received equal play till the modern era.

Subsequent OED supplementary volumes don't improve this definition. There's not a hint of any electronics context.

Of 12 on-line dictionaries I searched only Wikipedia had anything to say about embedded systems. But of course Wikipedia is more encyclopedia than dictionary, and is maintained by techies like us.

We're still working in a field whose name isn't part of the English lexicon. We can't get no respect!

Immediately following embedded in the OED comes embedlam, which means "to drive mad". Surely that's an appropriate description of the final phase of any embedded development project.

Toyota's Recent Woes

Tom Mazowiesky responded to my thoughts about Toyota: "I thought your take on the Toyota Prius was excellent. I'd like to add my two cents in. I've owned one Toyota in my life a bare bones strictly mechanical (no chips) machine so I don't have an ax to grind. What has astonished me is the incredible hit Toyota has taken in the mind of the public because of this problem. I think it reflects a growing attitude of the public, an unhealthy one in my opinion, that any product they buy will be perfect and that it proves to have a flaw that there is something fundamentally wrong with the company that built it.

"Toyota has managed to build a range of high quality products for many years with less recalls than any American manufacturer but that history counts for nothing in the face of this problem.

"I also liked your comments on the 'feel' of the brakes. As a former pilot who has some stick time on fly by wire systems, one of the criticisms the pilots hurl at engineers is trying to replicate the feel of the aircraft. This is even more critical in flying I believe, because things happen faster than in cars, you're moving in three dimensions, and small problems have a way of running your day in an airplane that would be a minor inconvenience in a car. The other criticism I had was having the software prevent the pilot from doing something 'dangerous' with the plane. While this is a good theory, there comes a time in every pilot's flying career where the unexpected happens, and you have to do something the designer of the plane did not anticipate.

"Having said that, I have to also say that the fly by wire systems I flew were very good and gave great feedback to the pilot under any conditions. These were the result of many years of development though, from the earliest analog designs to the more modern systems of today. It took a long time to get things right but that is the nature of the beast.

"Finally, your comments on getting information on the nature of the fix were also spot on. The only reason that in this case we might see some daylight is the involvement of NTSB. As you know the NTSB will write a report with all the facts and details and should also have details about the fix for the problem. They do that in the aircraft industry and the FAA will issue Airworthiness Directives mandating manufacturers and aircraft operators fix problems when they are severe enough. Hopefully the agency that does this for car safety has the same power."

Optimization

Joel Koltner said this about optimizers: "Regarding compiler optimizers... I completely agree that optimizers are often not necessary from a performance point of view (better data structures and algorithms usually make a much largely difference), and yes, they are tricky pieces of code and hence more prone to contain bugs than the rest of the compiler, but my experience is that optimizers are an *excellent* debugging tool, and here's why: Completely unoptimized code will often let the program get away with many sins including overwriting the call stack, accessing variables that 'should be' out of scope, and, yes, using variables that weren't declared volatile but should have been. How often have you heard a programmer tell you, "Yeah, I turned the optimizer on, and my code doesn't work anymore?" I claim that much of the time, it's because their own code is buggy and not that the optimizer got carried away due to its own bugginess.

"Unfortunately, a lot of novice programmer run into this problem and henceforth assume that optimizers are buggy. I once worked at a company where one of the stock interview questions was, "Have you found any bugs in your compiler? If so, how did you confirm it? If you contacted the manufacturer about it, what was their response?" ...and if they claimed they had but hadn't done anything to confirm that, yes, it really *was* the tool (e.g., by examining the assembly output), we weren't likely to hire them.

"I can't personally claim to have found any optimizer bugs, although I did find a bug in one of IAR's linkers whereby it generated CRCs incorrectly. I did confirm with the factory that it was their problem, and was then a little disappointed when they said the particular CRC generation option I was using was pretty nichey, so while they'd add it to their internal bug list, I shouldn't expect to see it fixed in the near future. Oh well."

Tools and Tips

Philippe Cau submitted some info on tools he likes: "I'm using PtrScr program to make screenshot under Windows. It is very useful when you must write some documentation or make a presentation too. Here is the URL: http://www.fiastarta.com/PrtScr/.

"About versioning, I'm using darcs (url: http://darcs.net/, it exists on many OS). My company is working with something close to CVS, but on my workstation I'm versioning all my work many times a day with darcs. It is very easy to install, and it really helps me to follow all my
code updates. It saves me many hours a week. Instead of wondering what I have broken during an update, I can follow many records I have done. Plus, I discovered an other point of view of versioning, a global point of view instead of a file point of view.

"As a PDF viewer, I' using sumatra, a light windows PDF reader (url: http://blog.kowalczyk.info/software/sumatrapdf/index.html).

"About file manager, I'm using midnight commander for Windows (old school I know, http://www.siegward-jaekel.de/mc-gb.html) but you can launch some programs like perl script directly. I'm using free commander too (http://www.freecommander.com)."

Joke for the Week

Never include a comment that will help someone else understand your code. If they understand it, they don't need you.

Never archive all the sources necessary to build a binary. Always hide them on your own disk. If they can build your binary, they don't need you.

Never complete a project on time. If you do, they will think it was easy and anyone can do it and they don't need you.

When someone stops by your office to ask a question, talk forever but don't answer the question. If they get their questions answered they don't need you.

Never discuss things in concrete terms. Always speak in abstract. If they can understand you, they don't need you.

About The Embedded Muse

The Embedded Muse is a newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. can take now to improve firmware quality and decrease development time.