You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com.

• Editor's Notes
• Embedded Video
• Quotes and Thoughts
• Tools and Tips
• Row Hammer
• The Final Say on MISRA
• Flash Schedules
• Obsolescence
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

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 https://www.ganssle.com/onsite.htm.

A lot of people have been asking for a public version of my seminar in the Fall. Where (in the USA) would you like to see it? Email Marybeth with your suggestions. Sorry, due to the volume of emails she won't be able to reply. We'll pick a location and let everyone know in the next issue.

Bertrand Meyer's latest book is about Agile methods. I have reviewed it here.

In Muse 251 I reviewed the DMMCheck, a $38 mini-calibration lab for multimeters. Here's a video version.

Edward's Law states: "Sociological problems do not always have technological solutions."

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

Tony Whitley found a Windows GUI for Uncrustify:

Ed Sutter has been improving his free uCon mega-Hyperterminal:

Using DDR3 memory? If so, be aware of an effect called row hammer. If many accesses are made to the same row in memory between refresh cycles, it's possible that data in adjacent rows can be corrupted.

This is pretty scary, as a lot of algorithms do massive numbers of reads to small ranges of memory. Image processing, filters, and similar algorithms read sequential locations many times in a short amount of time. Considering the speed of modern processors and the relative infrequent refreshes, it's likely that an innocuous-looking bit of code could cause serious data corruption. ECC helps but once there are more errors than can be corrected it falls apart. Generally an uncorrectable ECC error would cause an interrupt, and in an embedded device there's usually no way to resume the calculation. Most likely the OS will restart the application.

I'm told row hammer will not be an issue in DDR4 devices.

Chris Hills wrote:

Old-timers remember the pre-Flash days, when firmware lived in EPROMs. Compile the code. Test it. Ship it. Bugs? The customer lived with them until we were able to Fedex new chips. In many products replacing the chips required a very expensive service call. Bosses had low tolerance for bugs. Fortunately programs were much smaller in those days, and easier to get right.

Today Flash means we never have to say we're done. Consumers are encouraged to frequently check for firmware updates. Is your router acting strangely? Download new code. The BIOS interacts with some peripheral? Get thee to the vendor's web site for a firmware update.

Launching an interplanetary science mission? Why not use a 2 year coast phase to cheat the schedule? Every brand-new PC's software is hopelessly outdated the minute a consumer opens the box. And more than a few embedded apps get shipped long before their time, buggy and incomplete.

UPS takes 5 days to ship a package across country. Does your company use that week to play with the schedule? Ship it, sure, but then use a heroic sprint to really finish the code and email updates?

I know of only one case where this approach was totally successful. We sent a big system to the Middle East by ocean-going ship, a 30 day trip we used to finish the software. But (fortunately) the ship sank, providing us a much-needed couple of extra months of development time. Rumors that a software engineer was seen on the dock the night before sailing were denied.

But you can't count on those kinds of providential events. Be suspicious if the boss adds "ship sinks" to week 32 of the Pert chart.

75 miles south of London a 1000-year-old castle still stands. No longer home to kings and bishops, Amberley Castle is now an upscale hotel whose amenities must be seen to be believed. Several years ago we stayed there, for a single night only as their eXtreme Pricing model would quickly bankrupt us.

A millennia after being built the castle now has broadband! The juxtaposition of technology left me speechless. A portcullis and wi-fi. Parapets guarded by ultrasonic sensors. Digitally-synthesized telephone ringer near an old bronze chapel bell. Armored knights brandishing swords replaced by suited hotel guests wielding Blackberries while engaged in titanic boardroom clashes.

King Arthur needed wi-fi.

Mark Twain's "A Connecticut Yankee in King Arthur's Court" (a must read) describes a reverse juxtaposition. An engineer, bonked on the head in an accident, awakes in the sixth century just outside Camelot. In this case he imports not technology but a head full of skills. Our protagonist quickly manufactures guns, the telegraph and explosives, nearly dominating a great swath of merry old England while exposing Merlin as a bumbling charlatan.

One Star Trek episode exploited a similar theme. The usual complicated wrangling with the space-time continuum strands crewmember Leonard Vincent in the 1500s. Kirk muses aloud, wondering if Mr. Vincent became Leonardo da Vinci. Can you imagine what fun we'd have cast adrift in the distant past with 21st century engineering knowledge? And how frustrating to be unable to find the components we'd want, and to see our friends sicken and die from diseases that would be so easily treated by the medicines we take for granted.

In our industry the passage of just a few decades unleashes revolutionary change. My son and I once visited The Guitar Center. As he looked for a bass I wandered around, admiring the flashy electronics. Arrays of multicolored LEDs winked at me. Graphic displays flashed equalization settings. Oddly, the most expensive amplifiers had just a couple of simple controls, with none of the gaudy displays of the cheaper alternatives.

One had its back off. Peeking in I saw 6 vacuum tubes, valves to our British friends, though I'd assumed both of those monikers had long faded from memory. 6 tubes! We digital engineers can't design anything with less than a couple of million transistors. The amp, though modern, uses technology computer people discarded long ago. To me those tubes looked about as ancient as a castle's crumbling walls.

Our electronic creations are ephemeral. Like gnats flitting through a castle's gardens they speed through a lifecycle measured in days. Many of our products are obsolete before being shipped. My astonishment at finding the comparatively-young vacuum tube still extant reflects on the rate of technology obsolescence.

20 years ago I tossed my old Tektronix 545 scope. A 100 pound thing of beauty it used unconscionable amounts of power, too much bench space, and was far too slow for digital work. A fast analog Tek scope replaced it. That was eventually superseded by an Agilent MSO, which in turn was made obsolete by a much faster and snazzier Agilent.

Amberley Castle squats solidly on its massive foundations as it has for 50 generations. It'll probably last another millennia. But 10 years from now the Wi-fi antennas that adorn the courtyards will be gone, replaced by some other technology, one whose lifespan may be even shorter. I suspect that in some not-too-distant time budding Hendrixes will find that audio engineers have built silicon solutions far superior to tube amps. The last tubes will sit beside 545s, PDP-11s, and Altair 8800s in museums.

In this field the only constant, the bedrock of our expectations and experience, is change. Change keeps the business exciting. We're always learning new things.

But sometimes I envy those masons of old, whose creations were used for tens of scores of years. Wouldn't it be cool if in our dotage the gadgets we built were still valuable to someone?

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.

Note: These jokes are archived at www.ganssle.com/jokes.htm.

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. .

The Embedded Muse is Jack Ganssle's newsletter. 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.