Tweet Follow @jack_ganssle

Embedded Muse 147 Copyright 2007 TGG August 6, 2007

You may redistribute this newsletter for noncommercial purposes. For commercial use contact

EDITOR: Jack Ganssle,

- Editor’s Notes
- Dependable Software
- Tools and Tips
- Jobs!
- Joke for the Week
- About The Embedded Muse

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 .

Have you missed the Muse the last two months? Don’t worry, none have gone out! I can partly blame a crazy travel schedule, but the real culprit is my ISP’s shutting down the majordomo software that drives the newsletter. They’re not too happy about the load from the Muse’s 20,000 readers, so I’ve been porting it to a new server, using an entirely new bit of software for managing subscriptions and the dissemination of the newsletter. Please let me know if you experience any problems. Subscribe and unsubscribe techniques have changed; new procedures are at the end of this Muse.

Talking about travel, I’ll be speaking at the new Embedded Systems Conference in Bangalore, India in October, the always-fun East coast show in Boston in mid-September, and at Oredev in Malmo, Sweden in November. In addition, Omniscient International is sponsoring the class in Singapore and Malaysia in October (see

There’s a good, short, introduction to the Personal Software Process (Watts Humphrey’s well-known answer to the existential question “what can I do to take personal responsibility for my development skills?”) starting on page 45 here: . Recommended.

Here’s a fun question: how big is a bacterium compared to the line widths on a silicon chip? For an interesting analysis see Max Maxfield’s blog entry at . According to Wikipedia a virus, much smaller than bacteria, is around 20 to 300 nm in size, which is pretty close to typical chip geometries.

Dependable Software

There’s an interesting free 168 page report called “Software for Dependable Systems: Sufficient Evidence?” available from (registration required). Unfortunately it’s looonnng and would have been twice the book if half the size. In it a large group of authors investigate what makes software reliable. One unsurprising conclusion that we all know but don’t think about enough, is that good code has three principles:

- simplicity
- separation of concerns – loose coupling and independence
- localization of failure

Noble goals all, but difficult to achieve.

Chapter one, which explores the issues behind dependable software, is fascinating. Succeeding chapters aren’t, as they offer vague ideas that don’t translate into useful software engineering practices.

One quote that really struck a chord was this: “It is important, therefore, to distinguish the requirements of a software system, which involve properties in the physical world, from the specification of a software system, which characterizes the behavior of the software system at its interface with the environment. When the software system is itself only one components of a larger system, the other components in the system (including perhaps, as explained above, the people who work with the system) will be viewed as part of the environment.”

And, later: “One fundamental aspect of a systems perspective, as outlines in the early sections of this chapter, is paying attention to this distinction. Indeed, many failures of software systems can be attributed exactly to a failure to recognize this distinction, in which undue emphasis was placed on the specification at the expense of the requirements. The properties that matter to the users of a system are the requirements; the properties the software developer can enforce are represented by the specification; and the gap between the two should be filled by the properties of the environment itself.”

Note that the words requirements and specifications are distinct. In the software community we tend to use them interchangeably even though they are completely different concepts. Requirements define how a system interacts with the real world; they are the clearly-itemized benefits realized by the customer. Specifications define the way the system operates.

Tools and Tips

John Johnson sent the following:

“I looked over your list of tools and did not see much in the way of tools for hardware design specifically simulation tools.
As we know, an understanding of hardware, both analog and digital is very important to anyone who works with embedded systems, even a programmer who never touches a soldering iron.

“Here are a couple of links to what I think are good (and free) tools:



“LTspice/SwitcherCAD III:

“The last one is geared to promote components manufactured by Linear Technologies but I have found that spice models available on ohter manufacturer's websites will work in LTspice. This was borne out in a recent seminar in Toronto sponsored by Linear Technology where Mike Englehart, the designer responsible for LTspice, spoke about 3rd party models as well giving a good overview of the tool.”


Joke for the Week

For all you folks who have difficulty converting units:

Ratio of an igloo's circumference to its diameter = Eskimo Pi

2000 pounds of Chinese soup = Won ton

1 millionth of a mouthwash = 1 microscope

Time between slipping on a peel and smacking the pavement = 1 bananosecond

Weight an evangelist carries with God = 1 billigram

Time it takes to sail 220 yards at 1 nautical mile per hour = Knotfurlong

16.5 feet in the Twilight Zone = 1 Rod Serling

Half of a large intestine = 1 semicolon

1,000,000 aches = 1 megahurtz

Basic unit of laryngitis = 1 hoarsepower

Shortest distance between two jokes = A straight line

453.6 graham crackers = 1 pound cake

1 million- microphones = 1 megaphone