Follow @jack_ganssle

Volume 3, Number 15 Copyright 1998 TGG October 5, 1998


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

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Embedded Seminar in Boston
- Thought for the Week
- Embedded Overload?
- About The Embedded Muse


Embedded Seminar in Boston


I’ll present the seminar "The Best Ideas for Developing Better Firmware Faster” in Boston on November 12. It’s aimed at the developer who is honestly looking for new ideas, but who wants to cut through the academic fluff of formal methodologies and immediately find better ways to work.

The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines.

For more information check out http://www.ganssle.com or email info@ganssle.com.


Embedded Overload?


Yesterday I returned from a four day round trip sail on a friend’s boat to New Jersey. The adventure was nothing more than a lark: traveling at a paltry 5 knots, in the cold and rain, while being bounced all over, merely to return as soon as we hit our destination. In the harsh light of day it sounds rather dreary, though in fact we had a wonderful time.

We weren’t long gone, though, before the very expensive microprocessor-controlled marine voltage regulator failed, leaving us without the ability to charge the batteries. No batteries means no cold beer, so we put into port and diagnosed a bad IC. With no spares we did manage to hot-wire around the chip and bring the regulator back on-line, but only because two thirds of the crew were EEs.

While sailing across the Atlantic a few years ago I experienced major autopilot failures. Again, as an engineer I found ways to thwart the microprocessor’s confused states.

Pity the poor sailor, though, who goes to sea without a couple of decades of microprocessor experience! I suspect most of us have been frustrated by similar tales of product failures and bugs. As embedded systems become ever more prevalent, we’re almost inundated with mysterious product bugs and failures, or just poor performance. How many times have you had to remove the batteries from an appliance to get it’s brain back together?

With desktop technology (x86 CPUs, GUIs, etc.) moving into more and more embedded applications it’s harder than ever to say what makes a product uniquely embedded. My working definition of embedded versus desktop is one of quality: we’re content (more or less) to reboot Win95 three or four times a day, but will go ballistic if the car computer requires a reset every 20 miles.

Yet every one of us has experienced, or know someone who has, the odd vehicle behavior cured by a hideously expensive replacement computer.

We cannot imagine having an implanted embedded medical device fail.

Yet last year a pacemaker’s software bugs created havoc in many patients until doctors downloaded new code into its flash memory.

We taxpayers imagine that the Navy’s ships are tolerant of the sort of heavy damage expected in warfare.

Yet (according to the comp.risks digest) the USS Yorktown suffered a total loss of propulsion when an operator entered a parameter in a control machine that resulted in a divide by zero. Some reports claim the ship was towed into port.

I predict that in the future we embedded engineers will be responsible for product quality to a degree we cannot now imagine. As our lives are ever more affected by silent embedded computation, system quality (firmware, hardware, and tolerance of failure modes) will separate winning products from losers.

The alternative is a bleak scenario of lives spent implementing work-arounds to problems, of constantly replacing appliances (suffering from Y2K firmware failures!) and downloading new fixes, and eternal frustration with the things we bought to make life easier.

Towards the end of this recent sailing trip the GPS had trouble computing our position. We started joking that it was time to put a sextant (the instrument used for hundreds of years to measure position by the stars) in a glass box with a little brass hammer, carrying the label “break glass in case of embedded systems failure”!


Thought for the Week


Why Engineers Don't Write Recipe Books:

Chocolate Chip Cookies:

Ingredients:
1.) 532.35 cm3 gluten
2.) 4.9 cm3 NaHCO3
3.) 4.9 cm3 refined halite
4.) 236.6 cm3 partially hydrogenated tallow triglyceride
5.) 177.45 cm3 crystalline C12H22O11
6.) 177.45 cm3 unrefined C12H22O11
7.) 4.9 cm3 methyl ether of protocatechuic aldehyde
8.) Two calcium carbonate-encapsulated avian albumen-coated protein
9.) 473.2 cm3 theobroma cacao
10.) 236.6 cm3 de-encapsulated legume meats (sieve size #10)

To a 2-L jacketed round reactor vessel (reactor #1) with an overall heat transfer coefficient of about 100 Btu/F-ft2-hr, add ingredients one, two and three with constant agitation. In a second 2-L reactor vessel with a radial flow impeller operating at 100 rpm, add ingredients four, five, six, and seven until the mixture is homogenous. To reactor #2, add ingredient eight, followed by three equal volumes of the homogenous mixture in reactor #1. Additionally, add ingredient nine and ten slowly, with constant agitation. Care must be taken at this point in the reaction to control any temperature rise that may be the result of an exothermic reaction.

Using a screw extrude attached to a #4 nodulizer, place the mixture piece-meal on a 316SS sheet (300 x 600 mm). Heat in a 460K oven for a period of time that is in agreement with Frank & Johnston's first order rate expression (see JACOS, 21, 55), or until golden brown. Once the reaction is complete, place the sheet on a 25C heat-transfer table, allowing the product to come to equilibrium.

PS - don't try this at home.