Tweet Follow @jack_ganssle

Embedded Muse 83 Copyright 2003 TGG March 25, 2003


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

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- Power Problems
- Joke for the Week
- About The Embedded Muse


Editor’s Notes


The next Better Firmware Faster seminars will be in Chicago on April 15 and Baltimore/Washington on April 17 – see http://www.ganssle.com/classes.htm for more information.

I often do this seminar on-site, for companies with a dozen or more embedded folks who’d like to learn more efficient ways to build firmware. See http://www.ganssle.com/onsite.htm.

The last issue’s Thought For The Week was a funny story about the creation of C and Unix, and alleged that Thompson, Ritchie and Kernighan had perpetrated these programs as a hoax. I received several hundred emails from readers wondering if the press had caught on to this important story. Well, it was a joke! So I apologize for the confusion, and have renamed that section of the Muse “Joke for the Week”, to help avoid mix-ups in the future.

My comments about making C a safer language sparked some interesting replies. Dave Feustel suggested looking into Cyclone, which is a safe dialect of C. More info is available at: http://www.research.att.com/projects/cyclone/.

Les Hatton wrote to correct my comment that his book “Safer C: Developing Software for High-Integrity and Safety-Critical Systems” is out of print. Turns out it’s published by McGraw-Hill UK and is available there. Non-UK readers can order it through http://www.oakcomp.co.uk/TP_Books.html, and http://www.amazon.co.uk, (but intriguingly, not at www.amazon.com). Recommended.


Power Problems


I’m quite happy with my Linksys router/firewall, but a recent spate of brownouts here left it alive on the LAN side but dead to the net. Cycling power, that old standby virtually everyone in a technological civilization knows about and practices much too frequently, brought it back to life.

Fact is, brownouts are an increasingly important design parameter. The headlines fairly shout about energy shortages: increasing fuel oil prices, continued unrest and now war in the Middle East, a nuclear North Korea that is so short of electricity most people are back to kerosene lights. Even Venezuela, a country traditionally noted for cheap oil, is today saving power by delivering AC at slightly less than the 60Hz customers expect. Clocks lose 150 seconds a day as a result.

Designing brownout tolerant embedded systems is not trivial, though today there are plenty of great power management and reset clamp devices that ease the process. Good design is important, as are exhaustive tests that prove the system works properly over a range of inputs. Modern embedded systems are just too complex, with too much hard-to-model hardware/firmware interaction, to expect reliability without realistic testing. This means you’ve got to pound on the product, and look for every possible failure mode. If you’ve written code to preserve variables around brown-outs and loss of Vcc, and don’t conduct a meaningful test of that code, you’ll probably ship a subtly broken product.

In the past I’ve hired teenagers to mindlessly and endlessly flip the power switch on and off, logging the number of cycles and the number of times the system properly comes to life. Though I do believe in bringing youngsters into the engineering labs to expose them to the cool parts of our profession, sentencing them to mindless work is a sure way to convince them to become lawyers rather than techies.

Better, automate the tests. The Poc-It, from Microtools (www.poc-it.net – please discount the quote there as I have no connection to the company) is a cool $300 device that helps test power-fail circuits and associated code.

The Poc-It brainlessly turns your system on and off, counting the number of cycles. Another counter logs the number of times a logic signal asserts after power comes on. So, add a bit of test code to your firmware to drive a bit up when (and if) the system properly comes to life. Set the Poc-It up to run for a day or a month; come back and see if the number of power cycles is exactly equal to the number of successful assertions of the logic bit. Anything other than equality means something is dreadfully wrong.

Even better, power your test system from a Poc-it driving a Variac, so you can simulate brownouts.

Recommended.


Joke for the Week


A hardware engineer, a software engineer, and their project manager are taking a walk outdoors during their lunch break when they come upon an old brass lamp. They pick it up and dust it off. Poof -- out pops a genie.

"Thank you for releasing me from my lamp-prison. I can grant you 3 wishes. Since there are 3 of you I will grant one wish to each of you."

The hardware engineer thinks a moment and says, "I'd like to be sailing a yacht across the Pacific, racing before the wind, with an crew entirely comprised of members of the opposite sex."

"It is done", said the Genie, and poof, the hardware engineer disappears.

The software engineer thinks a moment and says, "I'd like to be riding my Harley with a gang of members of the opposite sex throughout the American Southwest."

"It is done", said the Genie, and poof, the software engineer disappears.

The project manager looks at where the other two had been standing and rubs his chin in thought. Then he tells the Genie, "I'd like those two back in the office after lunch."