Go here to sign up for The Embedded Muse.

Embedded Muse 205 Copyright 2011 TGG March 7, 2011

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 .

I'll be offering a two-day version of this class in Brazil in March. There's more information here: http://www.temporealeventos.com.br/?area=123-projetando-sistemas-embarcados-com-jack-gannsle-no-brasil-aos-Programadores-e-engenheiros-desenvolvedores-lideres-que-atuam-em-projetos-de-sistemas-embarcados .

Scott Nowell had an interesting observation about the consulting survey: "I also find it very interesting that most engineering contractors charge less than their plumber, electrician and auto shop. Really the same cause though. Those are usually multi-person operations with overhead."

Mike Barr has been digging through NASA's analysis of unintended acceleration in Toyotas, and has an interesting take on it here: http://embeddedgurus.com/barr-code/2011/03/unintended-acceleration-and-other-embedded-software-bugs/ .

VDC is running their annual survey of the wonderful and wacky world of embedded systems. You can take the survey by going to this address: http://j.mp/gdJVA3 . There are some freebies; the first 400 respondents who complete the survey will receive the choice of a $10 Amazon.com gift certificate or a $10 donation to FIRST (a charitable organization helping to promote the sciences to the next generation of engineers and developers). All respondents (including the first 400) who complete the survey will receive:

- Entry into the grand prize drawing for an Apple iPad 2;
- Immediate access to a summary of VDC's 2010 Embedded Engineering Survey results at the end of the survey; and
- A summary of the 2011 2010 Embedded Engineering Survey findings once the survey is complete later this year.

Quotes and Thoughts

Harold Hallikainen sent this:

"Do things as simple as possible, but not simpler."

My corollary to this is "The ideal design has zero parts."

Tools and Tips

The tool tips keep pouring in! Keep `em coming.

Graham Whaley writes: "On a similar vein to the LOGIC little logic analyser, I surveyed the market for small cheap units a few years back, and we decided on the LOGICPORT - http://www.pctestinstruments.com/ It is a 34 channel logic analyser that uses time compression to store samples in its rather small buffer, so if you have a slow moving signal you can get quite long traces. It will also go up to 200MHz external clocked, or 500MHz internally clocked. We find it invaluable for I2S and SPI issues, and it also has CAN, I2C, SPI and RS232 decoders built into the software. I can recommend this unit."

Scott Whitney also likes the LogicPort: "The info about the Saleae logic analyzer was a good tip. I also wanted to point out another option, slightly more expensive but with more channels. It's called the LA10343 LogicPort, and is a 34 channel analyzer via USB connection, with 500MHz timing mode or 200MHz state mode. http://www.pctestinstruments.com/index.htm ,

"The cool thing about it is that it provides complex triggering, and directly decodes CAN, I2C, SPI, and RS232 data streams. It uses clever data compression, essentially recording just changes on each pin, rather than the state of each pin at every clock. You can order it with a trigger output - highly recommended if you work with mixed signals and want to see an analog waveform in relation to some digital pattern. Of course, as parts shrink, it's getting harder and harder to clip onto the signals you need, but the grabbers that you can get with this product are very high quality."

John Johnson reports: "Someone in the FPGA/Verilog/VHDL newsgroups decided to survey tools, i.e. editors and IDEs, for VHDL (Verilog?). The results are published at: http://www.vhdleditor.com/ ."

Local Knowledge

The reefs in the Eastern Bahamas and Turks and Caicos are treacherous and poorly charted. We have taken our sailboat to these remote areas many times. Navigation marks are non-existent, GPS coordinates suspect, and some of the charts are based on surveys 150 years old. Guidebooks compiled by experienced people help us find our way, and we estimate depths by reading the water color. But some channels are much too intricate and convoluted; safe passage requires hiring a pilot, generally a wizened older fellow who has spent a lifetime moving vessels through these reefs. The pilot's mental chart is precise, necessary, and yet utterly unquantifiable.

Sailors call this type of insight "Local Knowledge". It's far more useful and accurate than any combination of sophisticated charting, electronics or satellite imagery. My home port is on the Chesapeake Bay; all ships moving on that large body must, by law, employ a pilot during the transit. These folks are so highly trained and tuned to the Bay that their "final exam" before getting pilot qualifications is to draw a chart of the Bay, with all marks and beacons, shoals and channels, from memory. Yet their knowledge is more accurate than the chart they draw, since, as in Mark Twain's Mississippi days, channels change and shift. These experts watch the water every day and are tuned into current conditions, not those codified on a chart issued months or years in the past.

Centuries of experience has proven the value of Local Knowledge. I'm astonished that we techies don't understand how important Local Knowledge is to any viable organization.

Here in Maryland in recent months several defense contractors have let a number of engineers go. That boom and bust cycle is endemic to defense. I remember when the local Westinghouse plant had so many layoffs they issued phone-book-sized bound volumes of resumes that were circulated to local businesses. Other industries suffer similar fates.

Clearly, companies sometime have no choice but to make painful cuts. Cost management is, after all, central to making profits, and profit is the cornerstone of capitalism.

But dumping engineers for any reason leads to a critical loss of Local Knowledge. For better or worse, none of our work products is a "this is why I made this decision" document. A schematic, VHDL equations, or even a pretty well-commented source file all give a how-it-works view of the system, never any insight into the blind alleys we wrestled with and eventually bested while developing the product. Some companies have created wikis to codify this sort of Local Knowledge, but I know of very few that have been particularly successful.

I've asked automotive companies how they preserve their experience. 100 years of engineering experience has disappeared as the workers leave in periodic mass layoffs or simply retire. I'm told there's no central book documenting design decisions. Remember the Pinto? A badly-placed fuel tank led to tragic deaths and costly lawsuits. That expensive lesson is preserved, apparently, only in the heads of the engineers. Who are all presumably long retired by now.

One outfit I know has a 75 year-old engineer on staff simply to answer customer questions about a product sold a quarter century ago that is still in use. He's hardly overworked, taking only a handful of calls per day. Cost effective? That's hard to say since the direct revenue traceable to his work is probably zero. But what a fantastic way to attract and keep customers! Once in a while developers working on current products hit him with a question; his knowledge of the products and the industry, his Local Knowledge, helps the younger crowd avoid expensive mistakes.

What's the answer? Is cost containment, often implemented by dumping older folks, ultimately a costly or even suicidal approach?

Jobs!

Let me know if you're hiring firmware or embedded designers. 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

Pete Bartram sent this:

A wife asks her husband, a software engineer: "Could you please go shopping for me and buy one carton of milk, and if they have eggs, get six." A short time later the husband comes back with six cartons of milk. The wife asks him, "Why did you buy six cartons of milk?" He replied, "They had eggs."

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.