Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
Issue Number 267, August 18, 2014
Copyright 2014 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com
   Jack Ganssle, Editor of The Embedded Muse

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

Contents
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 http://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.

Embedded Video

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

Quotes and Thoughts

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

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.

Tony Whitley found a Windows GUI for Uncrustify:

I have just stumbled on Uncrustify myself, via http://universalindent.sourceforge.net/ which is a GUI front end for Windows which makes setting the configuration options a lot easier. It also gives you a bunch of other beautifiers to play with, for C and other languages.

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

Maybe I'm old-school, but as much as the UART is old, its still an important interface for embedded development IMHO.
I add just about anything (within reason of course) that folks ask for, plus whenever I need something unique, I write it into the tool so it is at least somewhat generically useful. There's no monetary motivation here, but clearly the benefit on my side is that it gets tested and matured much faster and usually in ways I had not thought about.

Anyway, here are a few examples of recent features I've added either for myself or for others asking for it...

  • AUXCOM command to coordinate scripts with external devices, like ARDUINO

  • Coordinate several uCon connections with events

  • SOCKET command to allow scripts to interact with UDP/TCP servers

  • WOL (Wake-On-Lan) script command to wake up a hibernating networked system with WOL capability.

  • Inline Signaling puts changes to DSR/CTS/DCD/RI & BREAK in the text stream

  • HTTP server access to the terminal connection

  • Lua scripting

  • Etc...

Row Hammer

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.

Steve Leibson does a good job explaining it here.

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

The Final Say on MISRA

Chris Hills wrote:

I have done two papers on implementing MISRA-C:2012 for a MISRA-C workshop. The first does hammer home the point that if MISRA-C is inappropriately implemented it will do as much harm as good to a project. Both explain why deviations are important and that 100% compliance to MISRA-C is a Bad Thing ™. Properly implementing MISRA-C in fact requires rule deviations.

The two papers are here along with another one on why Requirements are required. MISRA-C is only useful if you have a decent process and requirements so you know what it is you are supposed to be building in the first place.
Regards

Flash Schedules

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.

Obsolescence

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.

Amberly Castle

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?

Jobs!

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 www.ganssle.com/jokes.htm.

John Black sent this link to a story of missing engineering humility.

Advertise With Us

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at info@ganssle.com.

About The Embedded Muse

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. 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 info@ganssle.com for more information.