The Embedded Muse

------------------------------------------------------------
Volume 3, Number 18   Copyright 1998 TGG   December 15, 1998
------------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Embedded Seminar in San Jose
- Engineering Insights
- Thought for the Week
- About The Embedded Muse


Embedded Seminar in San Jose
----------------------------
I'll present the seminar "The Best Ideas for Developing Better Firmware
Faster" in San Jose on February 18, 1999. 

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. If you're interested reserve early as these
seminars fill completely.

For more information check out http://www.ganssle.com or email
info(aatt_sign)ganssle.com. 


Engineering Insights
--------------------
This issue's theme is contributed by Robert Herold, and is used with his
kind permission. Thanks also to Don Jackson who brought this to my
attention and who keyed it in.

ENGINEERING INSIGHTS: Making Life Easier
By Robert Herold

Usually during the course of a day, I encounter something that is
bothersome or just not quite right. The radio in my car is too close to the
cupholder, so whenever I put down my coffee, the station gets switched from
Howard Stern to Rush Limbaugh. Loading a new bottle into the office water
cooler inevitably spills a few drops on the carpet. The sandwich guy asks
my views of mustard versus mayonnaise despite having heard the full details
just seconds earlier.

Porting operating systems to different hardware architectures is no
different. Every system from the Rockwell AIM-65 through the Power
Computing PowerTower Pro dual 225 MHz 604e has quirks that must be dealt
with. Perhaps someday we'll design a system that's perfect, fast, reliable,
and easy to write software for. If whoever builds it needs some unsolicited
advice, I have a list...

LOGIC DESIGN

* Put in a software-readable version number. For chips, put in a read-only
register. For circuit boards, dedicate a few I/O bits somewhere and put in
some pull-up/pull-down resistors to make a unique identification possible.
For I/O devices, put it wherever it's convenient. Whenever a change is
made, even one that doesn't affect the operation of the software, change
the version. Someday you'll be glad you did, bit it for manufacturing test,
field service, consumer recall, hardware debug, user interface, or geek
fascination with frivolous detail.

* Avoid write-only bits in registers -- let software read back what was
written earlier. Avoid bits that mean different things when read and
written -- chew up a little decode space instead and put them in separate
registers.

* Design registers that can have individual bits modified in a single
operation. This really helps when there's more than one bus master mucking
about the system, in that register updates don't need to be protected with
a software semaphore lock. My favorite example is the 6522 VIA registers --
the most significant bit controls whether you're setting or clearing, and
the rest of the bits have a one wherever a bit is to be modified and a zero
wherever a bit is to remain unchanged.

* Document what you design, preferably in a way that someone besides you
can understand. Describe not only what it is, but also what it's for.
Anyone who's taken a tour through a data book for a modern VGA graphics
controller can appreciate this. Better yet, include some real (that is,
actually compiled, run, and debugged) source code that uses your design.
Keep the documentation available even after you stop selling the part. Make
the documentation easy to get -- and free.

* Avoid timing dependencies. Any synchronous protocol or continuous input
data stream is an exception of course, but even there you can help by
providing a bit of buffering in your hardware. Putting a 5-million
transistor 225 MHz screamer into an interrupts-disabled spin loop waiting
for a few microseconds to pass before writing to the floppy controller
again due to some empirically observed resistance to being written faster
is not the best use of available MIPS.

SYSTEM DESIGN

* Make physical RAM contiguous. It's just easier that way.

* For multiprocessor systems, it's nice to be able to direct I/O interrupts
to different processors to distribute the load. Also, it's nice to be able
to turn off all I/O interrupts to all processors in a single operation and
to turn them back on later, while still allowing interprocessor interrupts.

* For CPUs, it would be nice to separate I/O interrupts from interprocessor
interrupts; having a different pin, a different interrupt vector, and a
different interrupt enable is ideal.

* Resources that are duplicated across different parts of the system should
have support for synchronizing their state. For instance, the PowerPC has a
time base register and a pin for enabling it. Without that pin (or without
any means of actually controlling the pin), it's impossible to ensure the
time base register has the same value on all processors.

* For debugging, provide a means of doing a nonmaskable interrupt to all
processors, preferably from an optional switch, and also from a
software-accessible register. If this is a recoverable interrupt in the
CPU, all the better. This will make OS designers everywhere think of you
fondly every time the system locks up and they can push a button and get to
a kernel debugger.

* Noncoherent caches aren't a good idea. A simple OS may be able to deal
with caches that aren't coherent with DMA accesses, but anything beyond DOS
or the maces will have major conniptions.

* Plan for bugs. Leave a couple of I/O pins around to let you control a PAL
later, so you can do a quick turn on your design to fix the bug in the new
improved gizmo that replaces the no-longer-manufactured old gizmo.

* Let the OS designer have one bit of visible I/O somewhere. A place for a
two-pin header where an LED can be hooked up will do. Alternatively,
provide a place to hook up a logic analyzer.

* Expansion buses should be self configuring (for example, NuBus) or
software configurable (for example, PCI). For an example of how not to do
this, see ISA, SCSI, or IDE.

PHYSICAL DESIGN

* Make the case easy to open. See the Mac IIci for an example.

* Put upgradable stuff where you can get at it. For an example of how not
to do this, try adding RAM to a Power Macintosh 8500.

* Use the circuit board silk-screen for user documentation. If you've made
the mistake of requiring jumpers, describe the jumper options right on the
board.

* If you must have jumpers, put an extra one or two on unused pins. Not
everyone lives ten minutes from Fry's Electronics.

* Use the circuit board silk-screen to make it easier to debug or probe.
Label the chips with real names instead of "U24." Then tag every tenth pin
with its pin number. This helps anyone poking around with a scope probe,
and besides, its cool to personalize what that black plastic behemoth is
doing millions of times a second. While you're at it, label some test
points for clocks and interesting logic lines.

* If you must use screws, use the same kind everywhere. If they must be
different lengths, at least make them the same thread. Make sure your
design holds together if any one given screw is mission, because that screw
always falls off the desk and take a four-hour vacation somewhere.

* Make it quiet. Otherwise, you can't use it while your spouse is sleeping.

* Avoid sharp edges. I hate bleeding on my motherboard.

* Connectors should be keyed. If not, the WILL be plugged in backwards. Lay
out pins in connectors so that when they're plugged in backwards, smoke
doesn't appear.

* Why is it that whenever I plug in the little twisted wire power LED, it's
always the wrong polarity? Label the pins, preferably with the wire color
that they're supposed to take. Alternatively, given the vagaries of wire
color selection by LED vendors, label the pins minus and plus, and I'll
just assume that the black wire goes to minus.

* If it's different, use different connector. I'm sure many parallel
printers have been plugged into the SCSI ports on the back of Macintoshes
everywhere. And in ancient times, 9-pin monitor cables were plugged into
serial ports.

* If it's different, make it obvious that it's different. Can you tell the
difference between a 3.5-volt DIMM and a 5-volt DIMM? Why aren't they
labeled? For that matter, why aren't SIMMs and DIMMs labeled in the first
place? Not everyone knows how to read DRAM part numbers.

PEOPLE IN GLASS HOUSES SHOULDN'T THROW STONES

Hardware designers who read this article may react defensively and start
writing their own list about operating system design. They're right to do
so -- we're by no means perfect. 


Thought for the Week
--------------------
Two mathematicians were having dinner in a restaurant, arguing about the
average mathematical knowledge of the American public. One mathematician
claimed that this average was woefully inadequate, the other maintained
that it was surprisingly high.

"I'll tell you what," said the cynic, "ask that waitress a simple math
question. If she gets it right, I'll pick up dinner. If not, you do." He
then excused himself to visit the men's room, and the other called the
waitress over.

"When my friend comes back," he told her, "I'm going to ask you a question,
and I want you to respond 'one third x cubed.'  There's twenty bucks in it
for you."  She agreed.

The cynic returned from the bathroom and called the waitress over.  "The
food was wonderful, thank you," the mathematician started.  Incidentally,
do you know what the integral of x squared is?"

The waitress looked pensive; almost pained. She looked around the room, at
her feet, made gurgling noises, and finally said, "Um, one third x cubed?"

So the cynic paid the check. The waitress wheeled around, walked a few
paces away, looked back at the two men, and muttered under her breath, "
..plus a constant." 



About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.

The Embedded Muse

------------------------------------------------------------
Volume 3, Number 17   Copyright 1998 TGG    October 26, 1998
------------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

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


Embedded Y2K
------------
There I tremble to even broach the subject of embedded Y2K - an area where
wise men fear to tread - so many people contact me about their concerns
about this that I feel compelled to state my beliefs.

First, we know, for sure, that a huge number of products currently in
factories and consumers' greedy hands use embedded computers of some sort.

Second, some of these are date-dependent. Millions of date chips (used
mostly in embedded systems) were shipped that have an inherent Y2K problem,
as they used only two digits to represent the year. Some amount of the code
and hardware is therefore surely broken.

Third, we have a date certain, a deadline no amount of marketing spin can
push back, when the problem will appear.

Fourth, 80% of embedded system projects are delivered late. The
software/firmware industry is notoriously unreliable in meeting deadlines.

So, it seems to me there's little likelihood the Y2K problem will be
adequately addressed by Jan 1, 2000. We'll surely see things fail.

What I don't know is the magnitude of the problem. If your kids' electronic
toys stop working, the resulting tantrums won't make the economies of the
world collapse. Many embedded systems are unimportant gadgets used by
people who expect to frequently replace electronics. Maybe the landfills
will groan under the weight of discarded techie-toys, as the economy is
buoyed when folks race to replace their failed electronics.

But will the electric power grid shut down, or will planes fall out of the
sky? This seems unlikely.

More interesting is the possibility of compounding failures. For example, a
tiny glitch somewhere might interrupt deliveries to a factory. Since
Just-In-Time deliveries have eliminated inventory buffers, that glitch may
shut down an entire plant, which in turn may cascade to more and more
shutdowns. We know that the economy is so complex that small forces can
result in totally unpredictable - and severe - results.

I suspect that huge single point failures won't be much of an issue, but
think we'll see lots of small issues crop up. Hopefully these will damp
out, like little wildfires that never combine to incinerate the entire
forest. But I think our world is so interdependent that no one can predict
the non-linear way these small problems could combine to cause chaos.

There's good news, though, indicated in this recent submittal to the Risks
digest (Forum On Risks To The Public In Computers And Related Systems):

Whisky tipplers can rest easy after the announcement last week that a
technological crisis that had threatened to halt the flow of Scotch has
been narrowly averted. Burn Stewart Distillers, whose brands include
Tobermory Single Malt and Wallace Liqueur, has declared that its computer
systems will be millennium compliant by the end of the year.

Although the whisky industry is steeped in tradition, it relies heavily on
computers to control many aspects of production and marketing. Burn Stewart
alone sells about 18 million bottles a year to 500 major customers. Failure
to deal with the millennium bug - which threatens global computer meltdown
due to an inability to recognise the date change from 1999 to 2000 - could
result in widespread disruption of the distilling, bottling and marketing
processes.  

(Reused without explicit authorization under blanket permission granted for
all Risks-Forum Digest materials.  The author(s), the RISKS moderator, and
the ACM have no connection with this reuse.)


Thought for the Week
--------------------
Come listen to a story 'bout a man named Jed,
A poor college kid, barely kept his family fed,
But then one day he was talking to a recruiter,
Who said, "they pay big bucks if ya work on a computer..."
Windows, that is... PC's... Internet...
 
Well, the first thing ya know ol' Jed's an engineer.
The kinfolk said, "Jed, move away from here".
They said "California is the place ya oughta be",
So he packed up his disks and moved to Silicon Valley...
Intel, that is... Pentium ... big amusement park...
 
On his first day at work, they stuck him in a cube.
Fed him lots of donuts and sat him at a tube.
They said "your project's late, but we know just what to do.
Instead of 40 hours, we'll work you 52!"
OT, that is... unpaid... no personal days...
 
The weeks rolled by and things were looking pretty bad.
Schedules started slipping and some managers were mad.
They called another meeting and decided on a fix.
The answer was simple... "We'll work him 66!"
Tired, that is... stressed out... no social life...
 
Months turned to years and his hair was turning gray.
Jed worked very hard while his life slipped away.
Waiting to retire when he turned 64,
Instead he got a call and escorted out the door.
Laid off, that is... de-briefed... unemployed...
 
Now the moral of the story is listen to what you're told,
Companies will use you and discard you when you're old.
So gather up your friends and start up your own firm,
Beat the competition, watch the bosses squirm.
Millionaires, that is... Bill Gates... Steve Jobs...
Y'all come back now... ya hear'



About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.

The Embedded Muse

------------------------------------------------------------
Volume 3, Number 16   Copyright 1998 TGG    October 12, 1998
------------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Embedded Seminar in Boston
- Thought for the Week
- Embedded Overload, Take 2
- Free Technical Training
- About The Embedded Muse
Embedded Overload, Take 2
-------------------------
Last issue's rant against poorly designed consumer embedded systems brought
a number of replies. One of the more interesting ones came from Bob
Blumenscheid of Grammar Engine, Inc. (a maker of ROM emulators):

Hi Jack,
I feel the same way when it sometimes takes all my knowledge of how my
computer and office network works to get a document to print.  My latest
frustrating experience with a PC peripheral was with a "Talk with me Barbie
(tm)", last year's big seller on remainder last weekend to make room for
this year's toys.  This Barbie has an IR sensor concealed in a locket in
her neck.  She can have girls' names, birthdays, personal info and other
details from Barbie software downloaded via serial port to an IR port in a
Barbie computer. She then makes personal comments when you press her button.  

After putting in Barbie's batteries (4 button cells and a AAA in each thigh
- Are all Dads embarrassed around naked Barbies?)  I had the classic
Windows experience: everything configured correctly, but nothing worked.
Barbie would not download.

After an hour of checking baud rates and serial drivers, I discovered the
problem was unclear documentation. If someone had just said to me: "Before
downloading, place Barbie in IR receive mode by pressing and holding the
button on her back" I'd have been in home territory. But I only got it
working after replaying and listening closely about 15 times to the 5-step,
spoken only .wav instructions on the CD-ROM.  

So the good news is my daughter still thinks I'm a hero, and I'm available
as a consultant if Mattel wants to know why embedded Barbie bombed. And for
the first time, a woman has said to me "We have a problem - click on my
help button."


Free Technical Training
-----------------------
Techonline - at http://www.tolu.com - offers a number of free training
courses that may be of interest to y'all. 

Currently they have the following online:
-Theory and Practice of Technical Standards
-Understanding Wireless Communications
-Overview of Digital Signal Processing
-xDSL: Digital Subscriber Lines Explained 
-Analog Devices DSP Development Environment


Thought for the Week
--------------------
You'll find a very irreverent but amusing "The Ten Commandments for C
Programmers" at:

http://lglwww.epfl.ch/~wolf/c/ten_commandments.html


About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.

The Embedded Muse

-----------------------------------------------------------
Volume 3, Number 15   Copyright 1998 TGG    October 5, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Embedded Seminar in Boston
- Embedded Overload?
- Thought for the Week
- 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(aatt_sign)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.



About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.




The Embedded Muse

-----------------------------------------------------------
Volume 3, Number 14   Copyright 1998 TGG    August 18, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Embedded Seminar in Chicago
- More Embedded Resources
- A Budding Programmer
- Thought for the Week
- About The Embedded Muse


Embedded Seminar in Chicago
---------------------------
My September 16 seminar "The Best Ideas for Developing Better Firmware
Faster" in Chicago is booking up. For more information check out
http://www.ganssle.com or email info(aatt_sign)ganssle.com. 


More Embedded Resources
-----------------------
Andre Felipe Machado passed along this URL:
http://www.ultracad.com/tech.htm, which has an index of app notes for
creating circuit boards for high speed systems. There's some interesting
advice here, well worth a gander.

Another resource is www.sigcon.com. This is Dr. Howard Johnson's home page.
He's the author of the best book about designing high speed circuits
around: High-speed Digital Design, a Handbook of Black Magic (ISBN
0-13-395724-1). On the site you can sign up for his email newsletter.


A Budding Programmer
--------------------
Recently my 11 year old son told me he'd like to learn to program
computers. I was stumped for a bit trying to decide what language to teach
him.

C? No way. C is a bit like UNIX. You can do all sorts of cool things in it,
but you need to know everything to do anything. 

Visual Basic? VB is a wonderland to play in. It takes little effort to
build cool Windows apps. But VB's environment has all of the evils of the C
language. You spend an eternity clicking on "property" menus to get things
to work right. 

Eventually I uncovered a musty old copy of MTBASIC, a DOS Basic that
supports unstructured, GUIless programming that came out of my youth. We
fired it up and had a working "Hello world" program in seconds. No
configuration issues, and no language impediments to learning. 

For an older person, one who is willing to dedicate some serious time to
learning programming, surely C and C++ are logical choices. But their
obscure syntax and quirky environments do seem to widen the gulf between
programmers and non-programmers. Basic and Fortran did bring programming to
the masses; there was a time when most college students got some exposure
to writing code. 

I did discover that the perils of programming are innate, built into our
DNA. He struggled with a bit of code, wanting to show it off to the girl
who lives on the boat next door. She arrived; with "no time to test" (a
phrase this industry seems to take as a mantra) the demo collapsed entirely. 

Ah, a chip off the old block!


Thought for the Week
--------------------
For fans of the Lord of the Rings trilogy:

Recently one of my friends, a computer wizard, paid me a visit. As we were
talking I mentioned that I had recently installed Windows 98 on my PC, I
told him how happy I was with this operating system and showed him the
Windows 98 CD. Too my surprise he threw it into my micro-wave oven and
turned on the oven. Instantly I got very upset, because the CD had become
precious to me, but he said: 'Do not worry, it is unharmed.' After a few
minutes he took the CD out, gave it to me and said: 'Take a close look at
it.' To my surprise the CD was quite cold to hold and it seemed to be
heavier than before. At first I could not see anything, but on the inner
edge of the central hole I saw a inscription, an inscription finer than
anything I have ever seen before. The inscription shone piercingly bright,
and yet remote, as if out of a great depth:
5E6F7D78E78BEDE8209450920F923A40EE10E58E132

'I cannot understand the fiery letters,' I said. 'No but I can,' he said.
'The letters are Hex, of an ancient mode, but the language is that of
Microsoft, which I shall not utter here. But in common English this is what
it says:

One OS to rule them all, 
One OS to find them,
One OS to bring them all and in the darkness bind them


About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.





The Embedded Muse

-----------------------------------------------------------
Volume 3, Number 13   Copyright 1998 TGG     August 3, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Embedded Seminar in Chicago
- Peopleware
- Thought for the Week
- About The Embedded Muse


Embedded Seminar in Chicago
---------------------------
I'm conducting a full-day embedded seminar in Chicago, near O'Hare airport,
on September 16. It's called "The Best Ideas for Developing Better Firmware
Faster". For more information check out http://www.ganssle.com or email
info(aatt_sign)ganssle.com. 


Peopleware
----------
An old farmer and a young farmer are standing at the fence talking about
farm-lore, and the old farmer's phone starts to ring. The old farmer just
keep talking about herbicides and hybrids, until the young farmer
interrupts "Aren't you going to answer that?"

"What fer?" Says the old farmer.

"Why, 'cause it's ringing. Aren't you going to get it?" says the younger.

The older farmer sighs and knowingly shakes his head. "Nope". he says. Then
he looks the younger in the eye to make sure he understands, "Ya see, I
bought that phone for MY convenience".

Most of us regard the ringing phone as an emergency. Drop whatever you're
doing and grab it! Stop all conversation, abandon the meeting, and respond
to what is all too often some salesman pushing cheap phone services.

We know better than that. Interruptions are one of the most effective
productivity killers around. 

For my money the most important work on software productivity in the last
20 years is DeMarco and Lister's Peopleware (1987 Dorset House Publishing,
NY NY). For a decade the authors conducted coding wars at a number of
different companies, pitting teams against each other on a standard set of
software problems. The results showed that, using any measure of
performance (speed, defects, etc.) the average of those in the 1st quartile
outperformed the average in the 4th quartile by a factor of 2.6. 

Surprisingly, none of the factors you'd expect to matter correlated to the
best and worst performers. Even experience mattered little, as long as the
programmers had been working for at least 6 months.

They did find a very strong correlation between the office environment and
team performance. Needless interruptions yielded poor performance. The best
teams had private (read "quiet") offices and phones with "off" switches.
Their study suggests that quiet time saves vast amounts of money.

Think about this. The almost minor tweak of getting some quiet time can,
according to their data, multiply your productivity by 260%! That's an
astonishing result. For the same salary your boss pays you now, he'd get
essentially 2.6 of you. 

The winners - those performing almost 3 times as well as the losers, had
the following environmental factors:

                     1st Quartile   4th Quartile
Dedicated workspace        78 sq ft   46 sq ft
Is it quiet?               57% yes    29% yes
Is it private?             62% yes    19% yes
Can you turn off phone?    52% yes    10% yes
Can you divert your calls? 76% yes    19% yes
Frequent interruptions?    38% yes    76% yes

Too many of us work in a sea of cubicles, despite the clear showing how
ineffective they are. It's bad enough that there's no door and no privacy.
Worse is when we're subjected to the phone calls of all of our neighbors.
We hear the whispered agony as the poor sod in the cube next door tries to
work it out with his spouse. We try to focus on our work... but being human
the pathos of the drama grabs our attention till we're straining to hear
the latest development. Is this an efficient use of an expensive person's
time?

Yet the cube police will rarely listen to data and reason. They've invested
in the cubes, and they've made a decision, By God! The cubicles are here to
stay!

This is a case where we can only wage a defensive action. Educate your boss
but resign yourself to failure. In the meantime, take some action to
minimize the downside of the environment. Here are a few ideas:

* Wear headphones and listen to music to drown out the divorce saga next door.

* Turn the phone off! If it has no "off" switch, unplug the damn thing. In
desperate situations attack the wire with a pair of wire cutters. Remember
that a phone is a bell that anyone in the world can ring to bring you
running. Conquer this madness for your most productive hours.

* Know your most productive hours. I work best before lunch; that's when I
schedule all of my creative work, all of the hard stuff. I leave the
afternoons free for low-IQ activities like meetings, phone calls, and
paperwork.

* Disable the email. It's worse than the phone. Your two hundred closest
friends who send the joke of the day are surely a delight, but if you
respond to the email reader's "bing" you're little more than one of NASA's
monkeys pressing a button to get a banana. 

* Put a curtain across the opening to simulate a poor man's door. Since the
height of the cube rather low, use a Velcro fastener or a clip to secure
the curtain across the opening. Be sure  others understand that when it's
closed you are not willing to hear from anyone unless it's an emergency. 


Thought for the Week
--------------------
Jim Chase created an object-oriented version of the data type presented in
the last issue. Here it is, with some additions suggested by other readers:

type
SoftwareProfessional = class
{
     double   salary;
     long     lunches;
     float    jobs;
     char     unstable;
     void     work;
     volatile short_temper;
     union    none;
     enum     workdays{mon,tues,wed,thurs,fri,sat,sun};
};

EnhancedSoftwareProfessional = class(SoftwareProfessional)
{
        int     rovert;
        long    hair;
        void    other_humans;
};


About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.





The Embedded Muse

-----------------------------------------------------------
Volume 3, Number 12   Copyright 1998 TGG      July 21, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Embedded Seminar in Chicago
- Embedded E-Newsletters
- Decision Making Reviews
- Thought for the Week
- About The Embedded Muse


Embedded Seminar in Chicago
---------------------------
I'm conducting a full-day embedded seminar in Chicago, near O'Hare airport,
on September 16. It's called "The Best Ideas for Developing Better Firmware
Faster", and is for 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(aatt_sign)ganssle.com. 


E-newsletters
-------------
I've recently found out about a couple of other E-newsletters on embedded
systems. 

The Embedded Processor Watch from Microdesign Resources is an independent
journal dedicated to reporting and analyzing advances in microprocessors
for embedded systems, information appliances, consumer electronics,
industrial control, and real-time systems. 

The editorial staff specializes in 32-bit & 64-bit microprocessor hardware,
and also covers CPU support logic and digital signal processor (DSP) chips.
Embedded Processor Watch does not accept advertising and is not affiliated
with any microprocessor vendor. 

Anyone may subscribe to this newsletter and receive timely news and
information on microprocessors. Only the editors of Embedded Processor
Watch may post messages. To subscribe, please send email to
join-embedded(aatt_sign)list.MDRonline.com. You do not need to enter anything into
the subject or body of the email.

Another newsletter is Embedded-Info, a free, monthly bulletin from Applied
Microsystems Corporation for engineers working on the design, debug and
test of embedded systems. Embedded-Info focuses on new technologies and
industry trends in embedded systems development.

To subscribe to Embedded-Info: Send E-mail to "majordomo(aatt_sign)amc.com" with
"subscribe embedded-info" as the entire body of the message (nothing in the
subject line).


Decision Making Reviews
-----------------------
Michael Ham, of MetaWare Incorporated (http://www.metaware.com), and I have
corresponded about issues related to decision making. Engineering is all
about inventing solutions to problems, which involves lots and lots of
decisions. He wrote a review of several books and products, which follows.

I have to admit being less than sanguine about the software products,
though, having had rather poor-to-mixed results with the various packages
I've tried over the years. My experience is that we often know what result
we want before creating the various matrices, and tend to use the tools to
justify our wish. Perhaps, emotional beings as we are, we mostly shoot from
the hip and then use a perverse sort of logic to rationalize our decision.

So, on with Michael's reviews:

We all make decisions, and we all can recall some spectacularly bad
decisions (not necessarily our own, of course): Ford Motor Company's Edsel,
the Cuban invasion at the Bay of Pigs, the decision to break into the
Democratic headquarters in Watergate, the new Coca-Cola, and so on.

_The Logic of Failure: Why Things Go Wrong and What We Can Do to Make Them
Right_; by Dietrich Dorner; Hardcover; $22.50.

Dorner's readable and intriguing book describes some examples of how
individuals and groups follow what seems like a logical series of simple
decisions to arrive ultimately at undesired and sometimes catastrophic
results. One major reason for this is that few people are actually trained
in decision-making techniques. Most of us, being self-taught, succumb to
common errors that produce bad decisions--just as self-taught golfers or
swimmers make common mistakes that limit how well they can do in those sports.

Of course, we hope that, over time, experience will improve the quality of
our decision-making. Research shows, however, that learning from experience
is neither automatic nor easy. To learn from experience requires deliberate
effort--for example, implementing the decision in a way that will provide
feedback so that the success of the decision can be evaluated.

_Decision Traps: Ten Barriers to Brilliant Decision-Making and How to
Overcome Them_; J. Edward Russo, Paul J.H. Schoemaker; Paperback; $9.90

Help is available. _Decision Traps_ breaks the decision-making process into
four phases--framing the decision, gathering information and estimates,
coming to a conclusion, and learning from experience--and for each phase
describes the most common errors and how to avoid them. The book also
examines how group decision-making works (or fails)--a useful section if
you, like most of us, are involved in group decisions.

Because the book specifies a definite process in reaching decisions, it
provides a way of evaluating decisions beyond looking at the result: you
can look at the process by which the decision was made. This is important
because in the real world, results are often skewed by chance factors. For
example, consider a hamburger restaurant that becomes a hit because it
sells a patron a winning lottery ticket, and another that fails because a
big and highly publicized recall of contaminated meat discourages people
from eating hamburger--in each case, chance factors greatly influenced the
outcome and masked whether the decision to open the restaurant was sound or
not. Of course, some people operate on the idea that all their successes
are due to skill, their failures to bad luck. Someone having this view will
learn very little from experience.

"BestChoice 3"; Logic Technologies, 800/776-3818 (Fax: 619/389-1185); DOS,
Software Package; $99.00

Decision-making often involves selecting one of several options, with no
one option a clear winner because each involves trade-offs. When there are
more than two options, more than one criterion for selection, and more than
one person involved in making the decision, the process becomes difficult
to manage. An inexpensive software package is available that makes this
task easy. 

BestChoice 3 takes a list of options (for example, a list of possible
product features) and criteria (for example, development cost, customer
appeal, competitive necessity) and prepares a decision list for each person
who will participate in the decision. Using this list, the decision maker
compares only two options at a time, and for only one criterion at a time.
The software then combines all the choices for all decision makers and
displays the result, with the options ranked by a total "score." You can
assign different weights (importance) to each criterion and even to each
decision maker. And the structure of the program allows easy "what if?"
scenarios: What if development cost were not given so much weight? What
would the marketing group decide by itself? 


Thought for the Week
--------------------
struct SoftwareProfessional
{
     double   salary;
     long     lunches;
     float    jobs;
     char     unstable;
     void     work;
};


About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.






-----------------------------------------------------------
Volume 3, Number 11   Copyright 1998 TGG      July 6, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Embedded Seminar in Chicago
- Hardware Helpers
- Thought for the Week
- About The Embedded Muse


Hardware Helpers
----------------
In the last few issues of the Muse readers have been sharing ideas of how
we can improve system debuggability when designing the hardware. A number
of folks sent more thoughts along, which are listed here.

Thanks for all of your feedback, and please do keep those ideas and
comments coming!



From: Tom Evans
It is fairly cheap to add a four-input comparator (LM139) that monitors the
on-board supplies, including any Maxim-generated RS232 voltages. Rig it up
to drive a bi-colour LED green when everything is OK (the power-on
indicator) and red when there's a fault. It can also be an input into the
power-on-reset logic, or can be monitored via an I/O pin (if the CPU can
run with some voltages bad).

I've always used a "CPU LED", which is turned on when the OS (or scheduler
or event-loop or polling-loop or whatever) finds something to do and is
turned off when there's nothing to do. In one project where a lot of work
has to be done in a few interrupt service routines, they also turn the LED
on. I also arrange to briefly flash the same LED at about a 2Hz rate from
the real-time interrupt. It is amazing the programming bugs this simple
addition shows up. Simply measuring the average voltage across this LED
gives a good indication of CPU utilisation. If it is a bi-colour LED it can
indicate error conditions or different processes (say interrupt or
mainline) so you can see where it was just before the watchdog bites.

If the power supply is on the same board as the logic, run the 5V rail from
the supply through a short, heavy link that is soldered in after the supply
has been tested. This also provides a place for installing a "calibrated
0.1 ohm resistor" (a length of wire-wrap wire) for when you need to measure
the current.


From: Alan Walker
When designing a PCB, make sure to leave enough clearance around any
components that you may eventually want to socket.  This is especially
important on boards with processors in PLCC packages where you may need to
use an emulator.

At assembly time, make sure all components which are attached to the PCB
via screws or through panels, are secured prior to soldering.  Soldering
before tightening everything down is an easy way to break a trace.

Bring out the reset line to small switch or jumper that can be installed on
your development boards.  This makes is easier to issue a hardware reset.

Some of the better schematics I have seen show the pinout for SOT-23s,
transformers, and other non-standard parts on the page where the part is
used.  For some of the larger packages you may want to add pin numbers to
the silkscreen.


From: Pascal Dornier
To add off-page references to OrCAD schematics, use OrTie (shareware,
http://www.pcengines.com/orcad.htm).

To analyze ISA and PCI buses, test adapters are available at low cost, e.g.
through Halted Specialties or Emulation Solutions.

To minimize the number of samples on PCI bus analysis, add a D-FF that
delays FRAME# by one clock -> FRAME2#. Program the logic analyzer to
capture those samples where either FRAME# low, FRAME2# high, or TRDY# and
IRDY# low.

If your embedded PC does not have a full bus available, at least provide a
subset of the 8 bit ISA bus so you can hook up a monochrome video card, a
keyboard, a hard disk and a POST code display.

The same "escape hatch" can also be used for in-circuit programming of
soldered-in flash EPROMs. A control line from the off-board flash can
disable the on-board flash, and execute an alternate BIOS running on a
separate (socketed DIP) flash EPROM.


From: Keith Hutchin
When using multiple bench supplies to power a system, be very careful to
check the connections before switching them on.... at one company I used to
work for, the Technical Director was showing a client around and decided to
demonstrate the new system we were designing. The system was designed
around Eurocards in a 6 foot tall 19" Rack cabinet. He connected up the two
bench supplies (incidentally, both manufactured by his other personally
owned company) and powered them both up. One was 24v (aatt_sign) 24A, the other 5V (aatt_sign)
24A. Guess what happened when the logic supply was fed with 24v with 24A
behind it .... yes, LOTS of smoke ! He destroyed 6 months work in about 10
seconds flat. The client thought it was highly amusing, but did not place
any orders with us. I wonder why !

When using a CAD system to design a PCB, be wary when copying blocks of
circuitry if they have already been assigned signal names - you could end
up with a lot of circuitry all 'bussed' together instead of being discreet
circuits. I know of at least one instance of this.

Be careful when specifying magnification factors on PCB artwork, I have
seen an expensive urgent PCB arrive from the manufactures, only to find
that it was double the expected size as the wrong magnification factor was
written on the film.


From: Carl Farrington
Some of the engineers I work with have started adding tick-marks on the
silk screen for every fifth pin on large parts.  It makes it SO much easier
to find pin 143...


Thought for the Week
--------------------
Two Digits for a Date
(to the tune of "Gilligan's Island," more or less)

Just sit right back and you'll hear a tale
Of the doom that is our fate.
That started when programmers used
Two digits for a date.
Two digits for a date.

Main memory was smaller then;
Hard disks were smaller, too.
"Four digits are extravagant,
So let's get by with two.
So let's get by with two."

"This works through 1999,"
The programmers did say.
"Unless we rewrite by then
It all will go away.
It all will go away."

But Management had not a clue:
"It works fine now, you bet!
A rewrite is a straight expense;
We won't do it just yet.
We won't do it just yet."

Now when 2000 rolls around
It all goes straight to hell,
For zero's less than ninety-nine,
As anyone can tell.
As anyone can tell.

The mail won't bring your pension check
It won't be sent to you
When you're no longer sixty-eight,
But minus thirty-two.
But minus thirty-two.

The problems we're about to face
Are frightening, for sure.
And reading every line of code's
The only certain cure.
The only certain cure.

[key change, big finish]
There's not much time,
There's too much code.
(And Cobol-coders, few)
When the century is finished with,
We may be finished, too.
We may be finished, too.

Eight thousand years from now I hope
That things weren't left too late,
And people aren't then lamenting
Four digits for a date.
Four digits for a date.


About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.









The Embedded Muse

-----------------------------------------------------------
Volume 3, Number 10   Copyright 1998 TGG      June 15, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Hardware Helpers
- Thought for the Week
- About The Embedded Muse

Hardware Helpers
----------------
Last issue I gave a few ideas of how we can improve system debuggability
when designing the hardware. A number of folks sent more thoughts along,
which are listed here.

Thanks for all of your feedback, and please do keep those ideas and
comments coming!


From: Leonard Picone
Make control registers in an ASIC readable.  I'm currently working on a
project with write only control registers and have seen them in the past as
well.


From Ed Sutter
On the schematics, add some comments...
  a. For all off-page routes, provide some comments on what page the route
goes to.  Some CAD packages apparently do this automatically, but I haven't
seen it.  I spend a lot of time just trying to find routes on schematics.
  b. For a part that has the Vcc and GND pins invisible on the schematic,
provide a comment indicating which pins are connected to where.
  c. For each complex part on a schematic, comment on physically where pin
#1 is and what direction the pin numbering is in (CW or CCW).

Provide convenient clip-lead access to all distinct power points, to
include ground.

Provide a watchdog timer and make it disable-able!  What I recommend is
that the input pin that must be toggled by firmware be optionally (via
jumper) tied to a hardware pin that should always be toggling (ALE on x86
for example). This provides the firmware guy with something that will keep
the watchdog happy when necessary, but still provides a hardware watchdog.

If the application has "leftover" communication ports, make them
accessible! For example, some CPUs have two UARTs and only one is needed
for the design. At least provide easy access to the TX, RX and GND pins so
that a Maxim part can be glued down for a spare debug port.


From: Steve Leibson
Like ground, put the board's master clock on a pin that's easy to grab.
Makes things much easier to scope or trace on an analyzer.

Always check a bare PC board fresh from the fab for a short between Vcc and
Ground. Because there are so many access points for these two "nodes,"
they're the easiest to short. If there is a short, connect the bare board
to a honking power supply and run some current through the short. You'll
either blow it or you'll be able to find it using the "burn your finger"
heat test. Either way, you'll locate the short.

Either install a signal LED for each power supply directly on the board (so
you'll know they're on) or install a small connector and develop a standard
power-monitor clip with the required LEDs and resistors so you can be sure
that all of the power supplies are connected properly and that they're
turned on.


From: Miguel Flores
Put reference designators in some sort of logical order on the board so you
can find them. It's also helpful to include an assembly drawing in the
schematic package in case the silk-screen is too dense.

For firmware, any sort of diagnostic I/O signal or LED should be dynamic,
not static, so you can tell if the CPU has halted or is stuck in a loop.

Label switches and jumpers used for configuration (such as I/O bus address)
with a legend on the silk-screen.

Make all connectors keyed so there is no guessing about which way the cable
is supposed to go.


From: Jim Thomas 
Make lots of narrow memory-mapped control/status ports instead of a few
wide ones (address space is cheap!). I am always flabbergasted to get a
board that has two or three 16-bit wide memory-mapped control ports, each
containing four of five different functions.  I hate having to be careful
not to accidentally clear an interrupt when I'm trying to toggle an LED.
It is better to wire different functions to different addresses.  That way,
the programmer can turn LED's on and off with wild abandon, never worrying
about accidentally toggling the card's bus lock bit.  

As an added bonus, this approach can use far fewer pins on a PLD (if that's
where the control registers reside).  Four data bits and four address bits
will control sixteen 4-bit registers, for a total of 64 control bits.
Doing this with four 16-bit wide registers (each register having many
functions) would require 16 data and two address bits.  Do the arithmetic!
And it's a ton easier to program.


From: Scott Finneran
Add a couple of spare I/O bits to the design that firmware folks can use to
instrument their code. If space (and decode logic) permits, include an
entire 8 bit register connected to a row of .1 spaced vias or headers.
Software state-machines can output their current "state" to this port which
can be captured with a logic analyser. This has the advantage of not
effecting timing as serial debug messages tend to do. Make it separate to
any status LEDs.

If you are including a serial port for debugging, make sure that it has
interrupt capability, nothing slows down software when debugging (causing
it's own set of problems) than polling a serial port. 

Don't just provide a GND post/test-point. Also include one for Vcc close
by. This allows easy connection of the old single input, 1-bit trace memory
logic analyser (the logic probe). Many simple "did it happen or not"
problems can be solved using one of these babies without tying up the heavy
artillery.

Two words: Flashing LEDs. 

Four words: and lot's of 'em. 


From: Jeff Corwin
Put an LED on a spare I/O output pin as a "confidence" indicator for the
users. In my most recent project, a remote control interface for some
broadcast equipment, I have a LED which flashes at a 1 second rate. Since
there is no user interface for these boxes, seeing the LED's flash every
second (synchronously, from a signal from the master unit) let's our
maintenance engineers know at a glance that the system is working.


From: David Timmins
When tracking a PCB that has non-power pin of an IC tied high or low, don't
use the pin as a convenient way to get the supply to the other side of the
pins, say, by tracking the supply through the pin and out the other side. I
call this "tracking through" and it makes debugging the PCB harder if that
pin needs to be wired to somewhere else.

When powering up a new PCB for the first time, meter out the power supply
pins from the power connector to some of the ICs on the PCB to make sure
that it is tracked correctly and that power connector hasn't been put on
the wrong way round. This can save you the time and embarrassment of
blowing up the PCB before you even start to debug it.
(Editor's Note: I like to power boards from a current-limited lab supply
that has an ammeter. I look at the current from time to time to make sure
I'm not doing anything expensively stupid... Jack).

Don't parallel inputs unless you have to, as it increases the load on the
device driving them and slows the circuit down. For example, if you are
using a 3 input NAND gate as an inverter, tie the two unused inputs high
rather than connect all three inputs to the signal.



Thought for the Week
--------------------
Alcohol and calculus don't mix.  Never drink and derive.


About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.





The Embedded Muse

-----------------------------------------------------------
Volume 3, Number 9   Copyright 1998 TGG        May 26, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Hardware Helpers
- Thought for the Week
- About The Embedded Muse


Hardware Helpers
----------------
Hardware designers who build our embedded systems daily make design
decisions that impact the debuggability of the product. Don Jackson
suggested that we collect ideas that hardware engineers can use to ease the
burden of testing both the hardware and the firmware. 

Here's a few; feel free to send more along!

- Put a nice ground clip on the board to ease the hassle of connecting a
scope or logic analyzer.

- Avoid tying signals directly to Vcc! Use a pull-up resistor instead so
you can probe the node, make changes to it, and run experiments. 

- Pull-up resistors, though, create no end of problem with some debug
tools. The tools may load signals differently than the CPU, so use a low
value (say, 10k) rather than 100k or more.

- Add a couple of spare I/O bits to the design that firmware folks can use
to instrument their code. A bit of code can toggle the bits up and down,
allowing simple performance measurements and the like.

- Leave margin in your timing! An extra 5 nsec or so on the read and write
timing - and ESPECIALLY in the wait circuit timing (if used) - will sure
make emulators and other tools work more reliably.

- Similarly, orient the CPU chip so it's possible to connect an emulator.
Sometimes the target board is so buried inside of a cabinet that access is
limited at best; most emulator pods have form factors that favor a
particular direction of insertion.

- If you're using a processor that supports on-chip debugging (BDM, JTAG,
etc.), then by all means install the debug connector on the board - even if
you're planning to use a full-blown emulator. The connector's cost
approaches zero, and may save a project suffering from tool-woes.

- A spare serial port sure opens debugging options. A variety of free
software monitors exist (see the Simtel archives on the net); all require
the use of a serial link.

- Never forget that one of the most useful chunks of hardware is a spare
timer or two, for running an RTOS or simply doing some sequencing. 



Thought for the Week
--------------------
The tech support problem dates back to long before the industrial
revolution, when primitive tribesmen beat out a rhythm on drums to
communicate:

This fire help. Me Groog
Me Lorto. Help. Fire not work.
You have flint and stone?
Ugh
You hit them together?
Ugh
What happen?
Fire not work
(sigh) Make spark?
No spark, no fire, me confused. Fire work yesterday.
*sigh* You change rock?
I change nothing
You sure?
Me make one change. Stone hot so me soak in stream so stone not burn Lorto
hand. Small change, shouldn't keep Lorto from make fire.
*Grabs club and goes to Lorto's cave*
*WHAM*WHAM*WHAM*WHAM*




The Embedded Muse

-----------------------------------------------------------
Volume 3, Number 8   Copyright 1998 TGG       April 9, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Editor's Notes
- An Embedded History - Part 2
- Thought for the Week
- About The Embedded Muse

Editor's Notes
--------------
I'm doing my "The Best Ideas for Developing Better Firmware Faster" seminar
in Dallas on April 23. A few seats are still available. More info follows
in this newsletter, or pop me an email. 

If your email in-box is like mine,  you're overwhelmed by mail from
recruiters looking for good people - or, ANY sort of people - for embedded
work. A recent call caught me short when a fellow wondered if The Embedded
Muse or the seminar series was a front for generating names to pass to
recruiters. Perhaps it's time to state my policy: the mailing list is never
sent to anyone under any circumstances. Further, commercial messages are
never accepted. On those rare occasions I discuss a particular product,
it's because I have found the product to be interesting, and wish to share
my thoughts. The vendors are a wonderful source of information, but this
forum is for rants and ramblings, not commercials.

TEM 19 talked about the issue of Discipline in firmware engineering, which
prompted a lot of response from readers. Almost concurrently a couple of my
articles in Embedded Systems Programming magazine discussed why a firmware
development standard is so important. If you'd like a firmware standard,
feel free to download one you can customize for your own needs from
www.ganssle.com/misc/ssm.zip. Once unzipped it's a Word 7 document.


An Embedded History - Part 2
----------------------------
TEM issue 16 contained the start of a personal history of the embedded
systems industry. Response was so favorable here's the next installment.

We left our story with the Intellec 8, an 8008-based development system
that used nothing more than an ASR-33 as both "mass storage" (via the paper
tape), and console. 

I worked for a company that built grain analyzers - a scanning
monochrometer beamed a spectrum of IR light at a sample of grain - wheat,
barley, and the like. Detectors sampled the reflected IR, amplified it by
numerous orders of magnitude, and digitized the signal before sending it to
the 8008-based controller. The first computerized version had a 4k program
- unbelievably tiny by today's standards, huge by those of the day. It took
16 ROMs (1702s, the only game in town at the time, had a whopping 256 byte
capacity) to store the 4k of code. No kidding.

Even with the dawn of the microprocessor age our code was as riddled with
bugs as today - probably more so. The problems were much more tractable
back then, as the limited address space and exclusive use of assembly
language eliminated any possibility of building really complex systems,
though we did have to implement all calculations in floating point, and
even ran a least squares regression to calibrate the system, all within
that 4k.

For debugging purposes, we cabled the Intellec 8's bus back to our own
computer's backplane, and let the Intellec's CPU take charge of our
peripherals. We edited, assembled, and linked on that Intellec, and then
loaded and debugged the code.

Building a program was a nightmare, though in those days having exclusive
access to ANY computer seemed pretty wonderful. Load the editor paper tape.
Enter and edit the program. Punch a tape of the source program (all
assembly, of course). Load the assembler tape. The assembler was a three
pass nightmare - you had to run the source tape through three times before
it spit out a binary tape. Then, load the linker and each binary tape.

The 4k program required 3 days to assemble and link. Three days. Needless
to say, one reassembled only rarely.

The Intellec had a simple monitor (much like a scaled down version of the
PC's DEBUG utility) that let you set two software breakpoints. We'd load
the binary and debug, making changes to the machine code with each bug fix.
The monitor didn't have a mini-assembler, so we quickly learned all of the
machine codes for the 8008's instruction set - not much of a feat when you
consider how limited that set was.

Sometimes we could patch right on top of the code. When the change was too
big, we'd patch a jump to a "patch area", and hand assemble new code in
there. With each change we'd make a careful record on the source listings.

After a day of debugging, we'd have lots of changes (hey - we were kids at
the time, with no concept of software engineering!). We'd punch a tape of
the current memory image and go home, reloading it the next day to pick up
from the same spot. Only infrequently would we edit in changes and go
through the pain of a total reassembly. 

Development was incredibly slow. Every aspect of the process was buggy. At
the time even Intel didn't understand how to program 1702s, so they'd
frequently drop bits. We spent months perfecting the algorithm in concert
with them.

Despite the troubles things worked, and we delivered hundreds of units over
a couple of years. Time moved on and we later used better processors and
algorithms; people left the company, replaced with others not familiar with
the older products. 

The original units used an iterative regression, which, if it didn't
converge within 20 minutes, displayed "HELP" in the seven segment LEDs.
I'll never forget some years later a technician came in, ashen faced, and
told me "I've been trying to repair this ancient unit, and after I fiddled
with it for a while it started displaying a panicked HELP message!"


Embedded Seminar! Dallas
------------------------
I'm conducting a full-day embedded seminar in Dallas on April 23. It's
called "The Best Ideas for Developing Better Firmware Faster", and is for
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(aatt_sign)ganssle.com. 


Thought for the Week
--------------------
SILICON VALLEY LINGO:

"percussive maintenance" - the fine art of whacking a device to get it working

"prairie dogging" - in companies where everyone has a cubicle  -- something
happens and everyone pops up to look.

"blowing your buffer" - losing your train of thought.

"yuppie food coupons" - twenty dollar bills from an ATM.

"treeware" - manuals and documentation.

"beepilepsy" - afflicts those with vibrating pagers characterized by sudden
spasms, goofy facial expressions and loss of speech.

"cobweb" - a WWW site that never changes.

"high dome" - egghead, scientist, PhD.

"elvis year" - the peak year of popularity, as in "1993 was Barney the
dinosaur's elvis year".

"generica" - fast food joints, strip malls, sub-divisions, as in "we were
so lost in generica that I couldn't remember what city it was".

"irritainment" - annoying but you can't stop watching, e.g. the O.J. trial.

"meatspace" - the physical world (as opposed to the virtual), also "carbon
community".

"silliwood" also "hollywired" - the coming convergence of movies,
interactive TV and computers



About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.




The Embedded Muse

-----------------------------------------------------------
Volume 3, Number 7   Copyright 1998 TGG      March 20, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Editor's Notes
- Discipline? Bah Humbug!
- Thought for the Week
- About The Embedded Muse


Editor's Notes
--------------
I'm doing my "The Best Ideas for Developing Better Firmware Faster" seminar
in Dallas on April 23. More info follows in this newsletter, or pop me an
email. 

The Embedded Systems Conference will be in Chicago at the end of the month.
Consult www.embedded.com for more information. I'll be giving the keynote
speech so come on by and heckle!

If you're a vendor of development tools or other products aimed at the
embedded market, you'll be interested to note that Embedded Systems
Programming is now doing their annual Buyer's Guide, a listing of all such
products and companies. This year they're accumulating product data
electronically. Contact me or twhittingham(aatt_sign)mfi.com for more info.


Discipline? Bah Humbug!
-----------------------
Recently I was giving a seminar to a crowd of 30 or so embedded folks, when
several in the class got into a quite animated discussion of the concept of
a disciplined firmware engineering process. I was rather surprised to find
a small contingent that was quite dedicated to creation of firmware by
anarchy. Design? Reviews? Nah. Hack it out, see what happens, and make lots
of changes during debug and integration.

By and large the firmware community is much more casual about software than
business programmers. After almost half a century of programming history
the COBOL/FORTAN/Desktop crowd has painfully learned reasonable ways to
create code. Not that they are entirely successful, but it seems the formal
practice of true software ENGINEERING is much more prevalent there than in
the embedded world.

Now, this is not a rant against embedded developers. In every group I speak
to there's a division between those in love with chaos, a majority who'd
genuinely like to find ways to work better but don't know where to turn,
and a small minority who adopt and practice effective software engineering. 

DISCIPLINE is the watchword for effective firmware development. Resist the
temptation to take the shortcuts that are so appealing, especially in the
heat of schedule pressure.

The subject came up again in the last week or two. My most recent column in
ESP discussed firmware software standards. Without a decent standard, one
adhered to by the entire team, decent software is quite impossible. An
avalanche of feedback from readers ran the gamut of praise to condemnation.
A surprising number of replies were of the sort: "hey, I write code my own
way and the hell with everyone else". Again, without DISCIPLINE firmware
projects will ultimately fail. Maybe heroics will save project A, but B, C
or D will collapse.

Many developers fear the fancy methodologies promoted by legions of gurus.
Frankly, so do I. If you're working on projects that run millions of lines
of code, a complex trademarked methodology is probably essential. Most of
the rest of us, though, develop products with 10,000 to a couple of hundred
thousand lines of code. There are a lot of simple, practical things we can
do without buying into the latest oh-so-complex methods. 

Watts Humphrey has studied many of these issues and concluded that changing
an entire organization from one that practices chaotic software development
to one that uses a more disciplined process is difficult. Worthwhile, for
sure, but perhaps being too ambitious is the road to ruin. His book "A
Discipline for Software Engineering" (1995 Addison-Wesley, ISBN
0-201-54610-8) is his vision of an alternative. He suggest that we each,
individually, learn and adopt some relatively simple practices that will
yield greatly improved productivity with far fewer bugs.

His book is a "must read" for all of us. It's not easy. It demands
attention and practice. I do highly recommend it for thinking developers
looking for ways to work smarter.


Embedded Seminar! Dallas
------------------------
I'm conducting a full-day embedded seminar in Dallas on April 23. It's
called "The Best Ideas for Developing Better Firmware Faster", and is for
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.

Here are a few comments from recent attendees:
- Thanks a lot for a great seminar.  We really 
  enjoyed it!   We're already putting to use 
  some of the ideas you gave us. J. Sarget, CSC

- I would like to thank you for the excellent 
  seminar. I just completed a major project and 
  your discussion was right on line. Steve Smith, IBM

- Thank you so much for a great class!! Dana 
  Woodring, Northrup Grumman

- I learned quite a bit and remembered a few things I 
  had forgotten over the years. Pete 
  Ackers, Compusolve

For more information check out http://www.ganssle.com or email
info(aatt_sign)ganssle.com. 


Thought for the Week
--------------------
Remember When?

Computer was something on TV
From a science fiction show
A window was something you hated to clean
And ram was the cousin of a goat

An application was for employment
A program was a TV show
A cursor used profanity
A keyboard was a piano

Memory was something that you lost with age
A CD was a bank account
And if you had a 3 1/2' floppy
You hoped nobody found out

Compress was something you did to the garbage
Not something you did to a file
And if you unzipped anything in public
You'd be in jail for a while

Log on was adding wood to the fire
Hard drive was a long trip on the road
A mouse pad was where a mouse lived
And a backup happened to your commode

Cut you did with a pocket knife
Paste you did with glue
A web was a spider's home
And a virus was the flu

I guess I'll stick to my pad and paper
And the memory in my head
I hear nobody's been killed in a computer crash
But when it happens they wish they were dead



About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.





The Embedded Muse

-----------------------------------------------------------
Volume 3, Number 6   Copyright 1998 TGG      March 11, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Editor's Notes
- Embedded Rules of Thumb
- Thought for the Week
- About The Embedded Muse


Editor's Notes
--------------
I'm doing my "The Best Ideas for Developing Better Firmware Faster" seminar
in Dallas on April 23. More info follows in this newsletter, or pop me an
email. 

The Embedded Systems Conference will be in Chicago at the end of the month.
Consult www.embedded.com for more information. I'll be giving the keynote
speech so come on by and heckle!

A lot of readers contributed fantastic "dumb mistakes" to this newsletter
over the course of quite a few issues. Now I'd like to start something a
bit different - Embedded Rules of Thumb. A handful are listed in the next
section, and I invite y'all to contribute more.

Most professions have "rules of thumb" that are shortcuts, really - quick
ways to understand something, or to make decisions without doing a lot of
analysis. Architects, for example, rarely compute floor loading when
designing a house. Instead they know that a 10 foot unsupported span needs
a certain beam configuration. Doctors know that when your temperature
exceeds normal by 2 or three degrees you're most likely sick; when it's 10
degrees high it's time for intensive care.

We embedded folks often skip the analysis of complex problems and shoot
from the hip. That's often not a bad approach when such a decision is
grounded in experience, and when a precise answer isn't required. To do
this effectively we develop rules of thumb. Instead of re-inventing the
rules all the time, I'd like to share some of mine and hope that others
will contribute.

None of these numbers are meant to be particularly accurate; they're more
guidelines to help our intuition. "Sanity checks", if you will, that let us
come up with quick answers or check ones resulting from detailed analysis.


Embedded Rules of Thumb
-----------------------
When specifying a system, we know that it's pretty much impossible to
guesstimate the size of a function if it'll be more than around 50 lines of
code. Therefore, A document that contains one line of "function xxx is 50
lines of code" per line will be around - or at least - 1 page per 2500
lines of estimated code.

A line of code typically costs $10 to $20 done to commercial standards. So,
that one page spec document represents something like $25-50k worth of
development.

Software emulations of floating point math on an 8 bit processor will take
around 1 msec per operation. Trig and other complex math is slower.

RS-232 characters take about 1 msec per character at 9600 baud.

Figure on about 5 bugs per 100 lines of code... if you're a careful coder.

Around 20% of your code will be junk. It might work, but it'll be
bug-ridden and a pain to complete.

The speed of light in wire or on a PCB trace is about 2 nsec per foot.


Embedded Seminar! Dallas
------------------------
I'm conducting a full-day embedded seminar in Dallas on April 23. It's
called "The Best Ideas for Developing Better Firmware Faster", and is for
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(aatt_sign)ganssle.com. 


Thought for the Week
--------------------
Top 20 Replies by Programmers when their programs do not work:

20. "That's weird..."
19. "It's never done that before."
18. "It worked yesterday."
17. "How is that possible?"
16. "It must be a hardware problem."
15. "What did you type in wrong to get it to crash?"
14. "There is something funky in your data."
13. "I haven't touched that module in weeks!"
12. "You must have the wrong version."
11. "It's just some unlucky coincidence."
10. "I can't test everything!"
 9. "THIS can't be the source of THAT."
 8. "It works, but it hasn't been tested."
 7. "Somebody must have changed my code."
 6. "Did you check for a virus on your system?"
 5. "Even though it doesn't work, how does it feel?
 4. "You can't use that version on your system."
 3. "Why do you want to do it that way?"
 2. "Where were you when the program blew up?"
 1.  "I thought I fixed that."



About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.





The Embedded Muse

-------------------------------------------------------
Volume 3, Number 5   Copyright 1998 TGG   March 4, 1998 
-------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Editor's Notes
- An Interview with Bjarne Stroustrup
- About The Embedded Muse

Editor's Notes
---------------
Today's issue of the Muse is a bit off-format. Somehow, from somewhere,
propagated over the ether of the net in an unending stream of anonymity,
the following interview appeared in my IN-box. 

Though the article is a joke, it reinforces my concerns with using any new
language for embedded work. Till a standard exists, and till a cadre of
well trained programmers are at hand, it's risky to bet on any new lingo.

C++ brings many potential benefits to the embedded world, as well as its
own set of baggage. A recent article in Embedded Systems Programming
magazine addressed some of these issues and discussed an alternative -
EC++, a version designed specifically for embedded systems where a lighter
footprint is essential. EC++ preserves most of the neat stuff about C++
while stripping out high-overhead things like multiple inheritance. 

So, since the issue of languages seems to bring out the flame wars... and
since it's dangerous to take ourselves too seriously, here it is:


An Interview with Bjarne Stroustrup
-----------------------------------
Interviewer:  Well, it's been a few years since you changed the world of
software design, how does it feel, looking back?

 Stroustrup:  Actually, I was thinking about those days, just before you
arrived.  Do you remember?  Everyone was writing 'C' and, the trouble was,
they were pretty damn good at it. Universities got pretty good at teaching
it, too.  They were turning out competent - I stress the word 'competent' -
graduates at a phenomenal rate.  That's what caused the problem.

Interviewer:  Problem?

Stroustrup:  Yes, problem.  Remember when everyone wrote Cobol?

Interviewer:  Of course, I did too

Stroustrup:  Well, in the beginning, these guys were like demi-gods.  Their
salaries were high, and they were treated like royalty.

Interviewer:  Those were the days, eh?

Stroustrup:  Right.  So what happened?  IBM got sick of it, and invested
millions in training programmers, till they were a dime a dozen.

Interviewer:  That's why I got out.  Salaries dropped within a year, to the
point where being a journalist actually paid better.

Stroustrup:  Exactly.  Well, the same happened with 'C' programmers.

Interviewer:  I see, but what's the point?

Stroustrup:  Well, one day, when I was sitting in my office, I thought of
this little scheme, which would redress the balance a little.  I thought 'I
wonder what would happen, if there were a language so complicated, so
difficult to learn, that nobody would ever be able to swamp the market with
programmers?'  Actually, I got some of the ideas from X10, you know, X
windows.  That was such a bitch of a graphics system, that it only just ran
on those Sun 3/60 things. They had all the ingredients for what I wanted.
A really ridiculously complex syntax, obscure functions, and pseudo-OO
structure.  Even now, nobody writes raw X-windows code.  Motif is the only
way to go if you want to retain your sanity.

Interviewer:  You're kidding...?

Stroustrup:  Not a bit of it.  In fact, there was another problem.. Unix
was written in 'C', which meant that any 'C' programmer could very easily
become a systems programmer.  Remember what a mainframe systems programmer
used to earn?

Interviewer:  You bet I do, that's what I used to do.

Stroustrup:  OK, so this new language had to divorce itself from Unix, by
hiding all the system calls that bound the two together so nicely.  This
would enable guys who only knew about DOS to earn a decent living too.

Interviewer:  I don't believe you said that...

Stroustrup:  Well, it's been long enough, now, and I believe most people
have figured out for themselves that C++ is a waste of time but, I must
say, it's taken them a lot longer than I thought it would.

Interviewer:  So how exactly did you do it?

Stroustrup:  It was only supposed to be a joke, I never thought people
would take the book seriously.  Anyone with half a brain can see that
object-oriented programming is counter-intuitive, illogical and inefficient.

Interviewer:  What?

Stroustrup:  And as for 're-useable code' - when did you ever hear of a
company re-using its code?

Interviewer:  Well, never, actually, but...

Stroustrup:  There you are then.  Mind you, a few tried, in the early days.
 There was this Oregon company - Mentor Graphics, I think they were called
- really caught a cold trying to rewrite everything in C++ in about '90 or
'91.  I felt sorry for them really, but I thought people would learn from
their mistakes.

Interviewer:  Obviously, they didn't?

Stroustrup:  Not in the slightest.  Trouble is, most companies hush-up all
their major blunders, and explaining a $30 million loss to the shareholders
would have been difficult. Give them their due, though, they made it work
in the end.

Interviewer:  They did?  Well, there you are then, it proves O-O works.

Stroustrup:  Well, almost.  The executable was so huge, it took five
minutes to load, on an HP workstation, with 128MB of RAM.  Then it ran like
treacle.  Actually, I thought this would be a major stumbling-block, and
I'd get found out within a week, but nobody cared.  Sun and HP were only
too glad to sell enormously powerful boxes, with huge resources just to run
trivial programs.  You know, when we had our first C++ compiler, at AT&T, I
compiled 'Hello World', and couldn't believe the size of the executable.
2.1MB

Interviewer:  What?  Well, compilers have come a long way, since then.

Stroustrup:  They have?  Try it on the latest version of g++ - you won't
get much change out of half a megabyte.  Also, there are several quite
recent examples for you, from all over the world.  British Telecom had a
major disaster on their hands but, luckily, managed to scrap the whole
thing and start again.  They were luckier than Australian Telecom.  Now I
hear that Siemens is building a dinosaur, and getting more and more worried
as the size of the hardware gets bigger, to accommodate the executables.
Isn't multiple inheritance a joy?

Interviewer:  Yes, but C++ is basically a sound language.

Stroustrup:  You really believe that, don't you?  Have you ever sat down
and worked on a C++ project?  Here's what happens: First, I've put in
enough pitfalls to make sure that only the most trivial projects will work
first time.  Take operator overloading.  At the end of the project, almost
every module has it, usually, because guys feel they really should do it,
as it was in their training course.  The same operator then means something
totally different in every module.  Try pulling that lot together, when you
have a hundred or so modules.  And as for data hiding.  God, I sometimes
can't help laughing when I hear about the problems companies have making
their modules talk to each other.  I think the word 'synergistic' was
specially invented to twist the knife in a project manager's ribs.

Interviewer:  I have to say, I'm beginning to be quite appalled at all
this.  You say you did it to raise programmers' salaries?  That's obscene.

Stroustrup:  Not really.  Everyone has a choice.  I didn't expect the thing
to get so much out of hand.  Anyway, I basically succeeded.  C++ is dying
off now, but programmers still get high salaries - especially those poor
devils who have to maintain all this crap.  You do realize, it's impossible
to maintain a large C++ software module if you didn't actually write it?

Interviewer:  How come?

Stroustrup:  You are out of touch, aren't you?  Remember the typedef?

Interviewer:  Yes, of course.

Stroustrup:  Remember how long it took to grope through the header files
only to find that 'RoofRaised' was a double precision number?  Well,
imagine how long it takes to find all the implicit typedefs in all the
Classes in a major project.

Interviewer:  So how do you reckon you've succeeded?

Stroustrup:  Remember the length of the average-sized 'C' project? About 6
months.  Not nearly long enough for a guy with a wife and kids to earn
enough to have a decent standard of living.  Take the same project, design
it in C++ and what do you get?  I'll tell you.  One to two years.  Isn't
that great?  All that job security, just through one mistake of judgment.
And another thing.  The universities haven't been teaching 'C' for such a
long time, there's now a shortage of decent 'C' programmers.  Especially
those who know anything about Unix systems programming.  How many guys
would know what to do with 'malloc', when they've used 'new' all these
years - and never bothered to check the return code.  In fact, most C++
programmers throw away their return codes.  Whatever happened to good ol'
'-1'?  At least you knew you had an error, without bogging the thing down
in all that 'throw' 'catch' 'try' stuff.

Interviewer:  But, surely, inheritance does save a lot of time?

Stroustrup:  Does it?  Have you ever noticed the difference between a 'C'
project plan, and a C++ project plan?  The planning stage for a C++ project
is three times as long.  Precisely to make sure that everything which
should be inherited is, and what shouldn't isn't.  Then, they still get it
wrong. Whoever heard of memory leaks in a 'C' program?  Now finding them is
a major industry.  Most companies give up, and send the product out,
knowing it leaks like a sieve, simply to avoid the expense of tracking them
all down.

Interviewer:  There are tools...

Stroustrup:  Most of which were written in C++.

Interviewer:  If we publish this, you'll probably get lynched, you do
realize that?

Stroustrup:  I doubt it.  As I said, C++ is way past its peak now, and no
company in its right mind would start a C++ project without a pilot trial.
That should convince them that it's the road to disaster.  If not, they
deserve all they get. You know, I tried to convince Dennis Ritchie to
rewrite Unix in C++.

Interviewer:  Oh my God.  What did he say?

Stroustrup:  Well, luckily, he has a good sense of humor.  I think both he
and Brian figured out what I was doing, in the early days, but never let
on.  He said he'd help me write a C++ version of DOS, if I was interested.

Interviewer:  Were you?

Stroustrup:  Actually, I did write DOS in C++, I'll give you a demo when
we're through.  I have it running on a Sparc 20 in the computer room.  Goes
like a rocket on 4 CPU's, and only takes up 70 megs of disk.

Interviewer:  What's it like on a PC?

Stroustrup:  Now you're kidding.  Haven't you ever seen Windows '95? I
think of that as my biggest success.  Nearly blew the game before I was
ready, though.

Interviewer:  You know, that idea of a Unix++ has really got me thinking.
Somewhere out there, there's a guy going to try it.

Stroustrup:  Not after they read this interview.

Interviewer:  I'm sorry, but I don't see us being able to publish any of this.

Stroustrup:  But it's the story of the century.  I only want to be
remembered by my fellow programmers, for what I've done for them.  You know
how much a C++ guy can get these days?

Interviewer:  Last I heard, a really top guy is worth $70 - $80 an hour.

Stroustrup:  See?  And I bet he earns it.  Keeping track of all the gotchas
I put into C++ is no easy job.  And, as I said before, every C++ programmer
feels bound by some mystic promise to use every damn element of the
language on every project.  Actually, that really annoys me sometimes, even
though it serves my original purpose.  I almost like the language after all
this time...

Interviewer:  You mean you didn't before?

Stroustrup:  Hated it.  It even looks clumsy, don't you agree?  But when
the book royalties started to come in...  well, you get the picture...

Interviewer:  Just a minute.  What about references?  You must admit, you
improved on 'C' pointers...

Stroustrup:  Hmm.  I've always wondered about that.  Originally, I thought
I had.  Then, one day I was discussing this with a guy who'd written C++
from the beginning.  He said he could never remember whether his variables
were referenced or dereferenced, so he always used pointers.  He said the
little asterisk always reminded him...

Interviewer:  Well, at this point, I usually say 'thank you very much' but
it hardly seems adequate...

Stroustrup:  Promise me you'll publish this.  My conscience is getting the
better of me these days...

Interviewer:  I'll let you know, but I think I know what my editor will say...

Stroustrup:  Who'd believe it anyway?  Although, can you send me a copy of
that tape?

Interviewer:  I can do that...



About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.

 



The Embedded Muse

-----------------------------------------------------------
Volume 3, Number 4   Copyright 1998 TGG   February 17, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Editor's Notes
- A Personal Embedded History - Part 1
- Embedded Seminar in San Jose
- Thought for the Week
- About The Embedded Muse


Editor's Notes
--------------
I'm doing my "The Best Ideas for Developing Better Firmware Faster" seminar
in San Jose on February 26. More info follows in this newsletter, or pop me
an email. A few seats are still available.

Today the 4000th subscriber to this newsletter signed up. I appreciate
everyone's continued interest and support! Please feel free to send
embedded stories and hints that you'd like to share with your fellow readers. 

Recent news indicates Sun is ready to introduce (reintroduce?) Embedded
Java in late March. Though I'm convinced that current embedded languages
(C, C++) serve us poorly, I have to admit to being skeptical about Java's
future in this market. It is a fascinating departure in programming
paradigms, in some ways drawing on the best from C, Forth, and from
object-oriented practices. The embedded community is, however, conservative
to the extreme and tends to adopt new languages only very slowly. Until
Java solves its various technical woes, and until a cadre of trained
embedded Java folks appear, I suspect it will be a technology without an
application. 

We must, however, keep a close eye on Java's progress. Who knows what
as-yet-unknown force may drive us into adoption of embedded Java tomorrow?

Finally, a number of people have been asking for the Muse to publish a
personal embedded history I worked on under a different venue some years
ago. Here's part one of a rambling story, to be continued erratically as
time permits. Feel free to send your own stories along for reposting if
appropriate.


A Personal Embedded History - Part 1
------------------------------------
In the blink of an eye our children grow into adults, middle age suddenly
assaults us while we're still wrestling with becoming (more or less)
responsible citizens, and the technology of yesterday ages, becomes
obsolete, and then forgotten. Once in a while it's important to step back,
take a breath, and remember where we've been. 

The embedded industry lacks a coherent record of its history. Most of us
are too busy designing systems to undertake the role of industry historian,
but, still - we're often interested in where we've been. 

In 1971 Intel shocked the electronics world with the announcement that the
4004, a 4 bit microprocessor, was now available as a component. A confirmed
18 yr old computer geek at the time, I remember the press hoopla well.
Frankly, most engineers just did not believe the announcement. Computers
cost tens of thousands of dollars. A computer on a chip? Clearly unlikely,
if not impossible. (Now, in February 1998, a generation and more after
Intel's announcement, postings in comp.arch.embedded reveal the formation
of a "4004 Enthusiasts Group". Yesterday's impossible technology reverts to
the stuff of nostalgia.)

Time proved that such an advance was indeed possible. A year or so later
Intel's 8008 hit the market. This part generated much more enthusiasm than
its predecessor. An 8 bit computer just might be able to do something
useful. After all, DEC's PDP-8, a well-accepted "serious" computer, had a
word 12 bits long.

The 8008 was an 18 pin chip that needed three different voltages to run. As
I recall, +5, -9, and +12 were all needed, plus a two phase clock input.
This didn't leave many pins for the address and data bus! Intel decided to
multiplex data and address on the same pins, an approach later used on
their 8085 and 8088 as well. It's only recently that high pin count surface
mount devices from Intel have come with separate busses. The chip used PMOS
technology, which has long since been supplanted by NMOS and finally CMOS.

In 1972 no one dreamed that large microprocessor programs would be
important. The 8008 had only 14 address lines, limiting its address space
to a measly 16 Kb. It would be tough to write a device driver in 16 Kb now,
but back then we were thrilled to have so much memory. In fact, memory was
so expensive that none of the 8008 systems I worked on ever used more than
12 kb. Typical static RAMs were 256 bits to 1k bits per part; dynamic
devices weighed in with all of 4k. The 1702 EPROM (256 bytes) ran at an
astonishing 1.3 microseconds.

The 8008 had a hardware stack, a 7 word-deep stack built into the silicon.
You could push or call up to seven levels deep but that was it. Finding
code that pushed just once too many times was a nightmare we fought
constantly.

Through the luck of being in the right place at the right time I managed to
land an engineering job while barely in college. No one had a clue how to
program these beasts; I knew as little as anyone but was cheap and
available. The company I worked for started a major project around the 8008.

Our development environment was an Intellec 8, a computer Intel built
around the 8008. It had a modular bus with 18 slots, so given enough money
you could populate the computer with a whopping 16 k of RAM. We built an
extender to connect the Intellec's bus to the backplane in the system we
were designing, building what in effect was a crummy bus-level emulator.
Our product measured protein content in grains - wheat, soybeans - by
looking at how the sample absorbed IR light.

Booting the Intellec 8 was one of those rare "pleasures" computer folks no
longer have to hassle with. Its front panel was covered with switches.
You'd key in a boot loader in binary, instruction by instruction, and then
hit the EXECUTE button. If your fingers set all the switches perfectly the
teletype would read in a paper tape loader program. A single bit error
required reentering all of the hundreds of switch settings. 

A later upgrade put the boot loader in ROM. Then all one had to do was
enter the binary for a JMP 0000 to start the code. I still remember those
codes: 01000100 00000000 00000000.

Our only I/O device, other than the lights and switches on the Intellec's
front panel, was a not-so-trusty ASR-33 teletype. There were no CRT
monitors in those days. Operating at a blinding 10 characters per second,
this mechanical beast was no doubt the cause of many ulcers and crimes of
frustration. The teletype needed 8 seconds to print one line of output.

The ASR-33 included a paper tape punch and reader. Tape was our storage
media - neither tape nor disks came along till much later. All of our
programs, both binary and source, were stored on paper tape.

Needless to say, high level languages were just not feasible. We did have
one brief flirtation with PL/M, cross compiling on a mainframe and
downloading the resulting tape to the Intellec. The compiler was
notoriously unreliable so we eventually switched to assembly language.

More later...


Embedded Seminar! San Jose
------------------------------------------------------
I'm conducting a full-day embedded seminar in San Jose on February 26. It's
called "The Best Ideas for Developing Better Firmware Faster", and is for
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(aatt_sign)ganssle.com. 


Thought for the Week
--------------------
Jake is struggling through a bus station with two huge and obviously heavy
suitcases when a stranger walks up to him and asks "Have you got the time?"

Jake sighs, puts down the suitcases and glances at his wrist.  "It's a
quarter to six," he says.

"Hey, that's a pretty fancy watch!" exclaims the stranger.

Jake brightens a little.  "Yeah, it's not bad.  Check this out" - and he
shows him a time zone display not just for every time zone in the world,
but for the 86 largest metropolis.  He hits a few buttons and from
somewhere on the watch a voice says "The time is eleven 'til six" in a very
West Texas accent.  A few more buttons and the same voice says something in
Japanese.  Jake continues "I've put in regional accents for each city". The
display is unbelievably high quality and the voice is simply astounding.
The stranger is struck dumb with admiration.

"That's not all", says Jake.  He pushes a few more buttons and a tiny but
very high-resolution map of New York City appears on the display.  "The
flashing dot shows our location by satellite positioning," explains Jake.
"View recede ten", Jake says, and the display changes to show eastern New
York state.

"I want to buy this watch!" says the stranger.

"Oh, no, it's not ready for sale yet; I'm still working out the bugs", says
the inventor.  "But look at this", and he proceeds to demonstrate that the
watch is also a very creditable little FM radio receiver with a digital
tuner, a sonar device that can measure distances up to 125 meters, a pager
with thermal paper printout and, most impressive of all, the capacity for
voice recordings of up to 300 standard-size books, "though I only have 32
of my favorites in there so far" says Jake.

"I've got to have this watch!", says the stranger.

"No, you don't understand; it's not ready -"

"I'll give you $1000 for it!"

"Oh, no, I've already spent more than -"

"I'll give you $5000 for it!"

"But it's just not -"

"I'll give you $15,000 for it!"  And the stranger pulls out a checkbook.

Jake stops to think.  He's only put about $8500 into materials and
development, and with $15,000 he can make another one and have it ready for
merchandising in only six months.

The stranger frantically finishes writing the check and waves it in front
of him.  "Here it is, ready to hand to you right here and now.  $15,000.
Take it or leave it."  Jake abruptly makes his decision. "OK", he says, and
peels off the watch.  They make the exchange and the stranger starts
happily away.

"Hey, wait a minute", calls Jake after the stranger, who turns around
warily.  Jake points to the two suitcases he'd been trying to wrestle
through the bus station.  "Don't forget your batteries."


About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.





The Embedded Muse

-----------------------------------------------------------
Volume 3, Number 3   Copyright 1998 TGG    January 30, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Editor's Notes
- Magic and Delays
- More Dumb Mistakes
- Embedded Seminar in San Jose
- Thought for the Week
- About The Embedded Muse


Editor's Notes
--------------
I'm doing my "The Best Ideas for Developing Better Firmware Faster" seminar
in San Jose on February 26. More info follows in this newsletter, or pop me
an email.

The folks at Miller Freeman have asked me to give the keynote speech at the
Embedded Systems Conference on March 31 in Chicago. These conferences are
always a ton of fun; I look forward to seeing some of you all there.


Magic and Delays
----------------
Miguel Flores contributed a "Dumb Mistakes" piece (following) about the
perils of using "magic numbers", in this case in delay routines. It's scary
how many times people get into trouble with delays, and also with constants
tuned to "make the damn thing work". In his case both conditions combine to
form a disaster.

If you've been in this business for a while you've surely seen the perils
of delay routines. It's almost amusing, in a bittersweet way, to watch
programmers wrestle with delays, tuning them to get the system working. 

Magic numbers are all too often the shortcuts we use to dodge deep
understanding of a problem. We tune a delay, or a constant, coming up with
a bit of what is truly magic just to get it out the door.

If we, the people developing the system, don't have a deep understanding
for the reasons behind EVERY DESIGN DECISION WE MAKE then we're surely
invoking magic, just as much as the necromancer of old. Magic numbers are
as effective as Tarot cards. 

Remember the old adage: problems that magically go away have a habit of
magically reappearing.

Understand before coding. Magic has no place in embedded systems.


More Dumb Mistakes
------------------
From Miguel Flores

Here is one I had to solve recently that has a good lesson.  The boards I
mentioned above have an ISA bus interface with the host PC.  We have a
message protocol for sending messages between the host and the board's
microcontroller.  The traffic across the ISA bus is controlled by a
hardware register containing status bits for words coming and going, and a
ready bit.  The ready bit is supposed to indicate that the board is ready
to do ISA bus data transfers and is tied to an I/O pin on the
microcontroller.  The board has an interrupt for data coming, and one for
data going.

The host PC uses a Unix OS, and when the system is booted, a driver for our
boards will perform a hardware discovery routine to learn what hardware is
installed on the ISA bus.  This routine consists of resetting the board,
waiting a *magic* delay, then trying to send a message to the board over
the ISA bus.  In theory, the ISA status register on the board eliminates
any timing or execution speed dependencies.

That's the theory.  In practice, the I/O pins from the microcontroller are
bi-directional.  After reset the I/O pins are tri-stated and act as inputs.
 This includes the ISA ready bit I/O.  It is pulled up to inactive so at
reset it goes inactive (not ready for ISA I/O).  The original developer (in
fairness, under considerable schedule pressure) got this whole scheme to
work with a little extra (read: magic) delay in the Unix driver after it
resets the board.  Fine, ship it.

So, next, we make a new version of one of these boards, and eliminate a 15
MHz clock circuit used to drive the microcontroller.  Instead, we use an
external 10 MHz clock which is used elsewhere on the board anyway.  The
microcontroller runs slower, but it is still fast enough to do its work.
This should not affect the ISA bus messaging since it uses that ISA bus
status register.  Well, by now you can guess that the Unix driver could not
find the slower board after reset.

Puzzled, I first supplied the board with a 15 MHz clock where the 10 MHz
should go.  This would make the board run like it used to when it worked.
OK, binary search.  Try 12.5 MHz.  Works.  Try 11.5 MHz.  Works.  Try 10.5
MHz.  Fails.  Try 10.6 MHz.  Works.  Oh no, a timing dependency.  In comes
the o-scope and some instrumented firmware and printed copies of I/O drivers.

To make a long story short, the board's ISA ready register was being set
within the first couple dozen instructions after reset (about 50
microseconds), even though the firmware was not ready until 5 milliseconds
later (what with interrupt vectors and all).  The magic delay in the Unix
driver was not long enough for the slower microcontroller clock speed, so,
the first word on the ISA bus after reset goes into the bit bucket.  The
board runs, but Unix can't talk to it.

The assembly language start up routine for the firmware, copied from other
projects, assumed it knew the I/O configuration of the microcontroller, and
set the direction of the I/O pins without first initializing the data that
would be driven on the output pins.  This included the ISA ready bit in the
wrong state.  This explained the need for the magic Unix driver delay after
reset.

The lesson here is to not make or impose any unnecessary assumptions about
the hardware or software.  The start up firmware has nothing to do with any
of the microcontroller I/O's, so don't mess with them.  And further, make
sure the I/O data has been initialized before driving the output pins. Good
thing this equipment is not connected to any mechanical stuff. Finally, if
you need magic to make your system work (like our magic delay in the Unix
driver), then you don't fully understand how or why it works.


Embedded Seminar! San Jose
------------------------------------------------------
I'm conducting a full-day embedded seminar in San Jose on February 26. It's
called "The Best Ideas for Developing Better Firmware Faster", and is for
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(aatt_sign)ganssle.com. 


Thought for the Week
--------------------
Write in C (Sing to the Beatle's tune "Let it Be")

When I find my code in tons of trouble,
Friends and colleagues come to me,
Speaking words of wisdom:
"Write in C."

As the deadline fast approaches,
And bugs are all that I can see,
Somewhere, someone whispers:
"Write in C."

Write in C, Write in C,
Write in C, oh, Write in C.
LOGO's dead and buried,
Write in C.

I used to write a lot of FORTRAN,
For science it worked flawlessly.
Try using it for graphics!
Write in C.

If you've just spent nearly 30 hours,
Debugging some assembly,
Soon you will be glad to
Write in C.

Write in C, Write in C,
Write in C, yeah, Write in C.
BASIC's not the answer.
Write in C.

Write in C, Write in C
Write in C, oh, Write in C.
Pascal won't quite cut it.
Write in C.



About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.




The Embedded Muse

-----------------------------------------------------------
Volume 3, Number 2   Copyright 1998 TGG    January 11, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Editor's Notes
- Mars Pathfinder
- Embedded Seminar in DC and San Jose
- Thought for the Week
- About The Embedded Muse


Editor's Notes
--------------
I'm doing my "The Best Ideas for Developing Better Firmware Faster" seminar
in DC on January 29, and in San Jose on February 26. More info follows in
this newsletter.

While the debate about Windows CE continues to rage in technical circles, I
was intrigued to see an article in that most un-technical of publications,
The Washington Post, about CE. It seems Microsoft signed a deal with TCI
(the largest cable TV company in the USA) to provide CE for TCI's upcoming
set top boxes. Microsoft will license more than 5 million copies of CE to
TCI. This is an interesting application, as it's very high volume with a
relatively low sell-price (about $300 per box), yet it's an embedded system
based on a 32 bit CPU with (now) a rather large and complex OS.

And, how often do you see OS decisions trumpeted in the Post?


Mars Pathfinder
---------------
Many of you may have seen Mike Jone's recent posting to the RISKS mailing
list about the software crashes experienced by the Mars Pathfinder. You may
not have seen the response by Glenn Reeves of JPL. These dialogs give a
fascinating view of the perils of priority inversion on real time systems.
Mike kindly gave me permission to reprint his letter and Glenn's response.

This is a fascinating story of how a bug makes it to Mars, and how clever
developers created code that anticipated bugs (i.e., they left debug
facilities enabled), and then fixed the bug, uploading code to a product
located on another planet. 


From Mike Jones:
The Mars Pathfinder mission was widely proclaimed as "flawless" in the
early days after its July 4th, 1997 landing on the Martian surface.
Successes included its unconventional "landing" -- bouncing onto the
Martian surface surrounded by airbags, deploying the Sojourner rover, and
gathering and transmitting voluminous data back to Earth, including the
panoramic pictures that were such a hit on the Web.  But a few days into
the mission, not long after Pathfinder started gathering meteorological
data, the spacecraft began experiencing total system resets, each resulting
in losses of data.  The press reported these failures in terms such as
"software glitches" and "the computer was trying to do too many things at
once".

This week at the IEEE Real-Time Systems Symposium I heard a fascinating
keynote address by David Wilner, Chief Technical Officer of Wind River
Systems.  Wind River makes VxWorks, the real-time embedded systems kernel
that was used in the Mars Pathfinder mission.  In his talk, he explained in
detail the actual software problems that caused the total system resets of
the Pathfinder spacecraft, how they were diagnosed, and how they were
solved.  I wanted to share his story with each of you.

VxWorks provides preemptive priority scheduling of threads.  Tasks on the
Pathfinder spacecraft were executed as threads with priorities that were
assigned in the usual manner reflecting the relative urgency of these tasks.

Pathfinder contained an "information bus", which you can think of as a
shared memory area used for passing information between different
components of the spacecraft.  A bus management task ran frequently with
high priority to move certain kinds of data in and out of the information
bus.  Access to the bus was synchronized with mutual exclusion locks
(mutexes).

The meteorological data gathering task ran as an infrequent, low priority
thread, and used the information bus to publish its data.  When publishing
its data, it would acquire a mutex, do writes to the bus, and release the
mutex.  If an interrupt caused the information bus thread to be scheduled
while this mutex was held, and if the information bus thread then attempted
to acquire this same mutex in order to retrieve published data, this would
cause it to block on the mutex, waiting until the meteorological thread
released the mutex before it could continue.  The spacecraft also contained
a communications task that ran with medium priority.

Most of the time this combination worked fine.  However, very infrequently
it was possible for an interrupt to occur that caused the (medium priority)
communications task to be scheduled during the short interval while the
(high priority) information bus thread was blocked waiting for the (low
priority) meteorological data thread.  In this case, the long-running
communications task, having higher priority than the meteorological task,
would prevent it from running, consequently preventing the blocked
information bus task from running.  After some time had passed, a watchdog
timer would go off, notice that the data bus task had not been executed for
some time, conclude that something had gone drastically wrong, and initiate
a total system reset.

This scenario is a classic case of priority inversion.

HOW WAS THIS DEBUGGED?
VxWorks can be run in a mode where it records a total trace of all
interesting system events, including context switches, uses of
synchronization objects, and interrupts.  After the failure, JPL engineers
spent hours and hours running the system on the exact spacecraft replica in
their lab with tracing turned on, attempting to replicate the precise
conditions under which they believed that the reset occurred.  Early in the
morning, after all but one engineer had gone home, the engineer finally
reproduced a system reset on the replica.  Analysis of the trace revealed
the priority inversion.

HOW WAS THE PROBLEM CORRECTED?
When created, a VxWorks mutex object accepts a boolean parameter that
indicates whether priority inheritance should be performed by the mutex.
The mutex in question had been initialized with the parameter off; had it
been on, the low-priority meteorological thread would have inherited the
priority of the high-priority data bus thread blocked on it while it held
the mutex, causing it be scheduled with higher priority than the
medium-priority communications task, thus preventing the priority
inversion. Once diagnosed, it was clear to the JPL engineers that using
priority inheritance would prevent the resets they were seeing.

VxWorks contains a C language interpreter intended to allow developers to
type in C expressions and functions to be executed on the fly during system
debugging.  The JPL engineers fortuitously decided to launch the spacecraft
with this feature still enabled.  By coding convention, the initialization
parameter for the mutex in question (and those for two others which could
have caused the same problem) were stored in global variables, whose
addresses were in symbol tables also included in the launch software, and
available to the C interpreter.  A short C program was uploaded to the
spacecraft, which when interpreted, changed the values of these variables
from FALSE to TRUE.  No more system resets occurred.

ANALYSIS AND LESSONS
First and foremost, diagnosing this problem as a black box would have been
impossible.  Only detailed traces of actual system behavior enabled the
faulty execution sequence to be captured and identified.

Secondly, leaving the "debugging" facilities in the system saved the day.
Without the ability to modify the system in the field, the problem could
not have been corrected.

Finally, the engineer's initial analysis that "the data bus task executes
very frequently and is time-critical -- we shouldn't spend the extra time
in it to perform priority inheritance" was exactly wrong.  It is precisely
in such time critical and important situations where correctness is
essential, even at some additional performance cost.

HUMAN NATURE, DEADLINE PRESSURES
David told us that the JPL engineers later confessed that one or two system
resets had occurred in their months of pre-flight testing.  They had never
been reproducible or explainable, and so the engineers, in a very
human-nature response of denial, decided that they probably weren't
important, using the rationale "it was probably caused by a hardware glitch".

Part of it too was the engineers' focus.  They were extremely focused on
ensuring the quality and flawless operation of the landing software.
Should it have failed, the mission would have been lost.  It is entirely
understandable for the engineers to discount occasional glitches in the
less-critical land-mission software, particularly given that a spacecraft
reset was a viable recovery strategy at that phase of the mission.

THE IMPORTANCE OF GOOD THEORY/ALGORITHMS
David also said that some of the real heroes of the situation were some
people from CMU who had published a paper he'd heard presented many years
ago who first identified the priority inversion problem and proposed the
solution.  He apologized for not remembering the precise details of the
paper or who wrote it.  Bringing things full circle, it turns out that the
three authors of this result were all in the room, and at the end of the
talk were encouraged by the program chair to stand and be acknowledged.
They were Lui Sha, John Lehoczky, and Raj Rajkumar.  When was the last time
you saw a room of people cheer a group of computer science theorists for
their significant practical contribution to advancing human knowledge? :-)
It was quite a moment.

POSTLUDE
For the record, the paper was:
L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols: An
Approach to Real-Time Synchronization. In IEEE Transactions on Computers,
vol. 39, pp. 1175-1185, Sep. 1990. What really happened on Mars ?


Here's a follow-up from Glenn Reeves, Mars Pathfinder Flight Software
Cognizant Engineer:

By now most of you have read Mike's summary of Dave Wilner's comments given
at the IEEE Real-Time Systems Symposium.  I don't know Mike and I didn't
attend the symposium (though I really wish I had now) and I have not talked
to Dave Wilner since before the talk.  However, I did lead the software
team for the Mars Pathfinder spacecraft.  So, instead of trying to find out
what was said I will just tell you what happened.  You can make your own
judgments.

Since I want to make sure the problem is clearly understood I need to step
through each of the areas which contributed to the problem.

THE HARDWARE
The simplified view of the Mars Pathfinder hardware architecture looks like
this.  A single CPU controls the spacecraft.  It resides on a VME bus which
also contains interface cards for the radio, the camera, and an interface
to a 1553 bus.  The 1553 bus connects to two places: The "cruise stage"
part of the spacecraft and the "lander" part of the spacecraft.  The
hardware on the cruise part of the spacecraft controls thrusters, valves, a
sun sensor, and a star scanner.  The hardware on the lander part provides
an interface to accelerometers, a radar altimeter, and an instrument for
meteorological science known as the ASI/MET.  The hardware which we used to
interface to the 1553 bus (at both ends) was inherited from the Cassini
spacecraft.  This hardware came with a specific paradigm for its usage:
the software will schedule activity at an 8 Hz rate.  This **feature**
dictated the architecture of the software which controls both the 1553 bus
and the devices attached to it. 

THE SOFTWARE ARCHITECTURE
The software to control the 1553 bus and the attached instruments was
implemented as two tasks.  The first task controlled the setup of
transactions on the 1553 bus (called the bus scheduler or bc_sched task)
and the second task handled the collection of the transaction results i.e.
the data.  The second task is referred to as the bc_dist (for distribution)
task.  A typical timeline for the bus activity  for a single cycle is shown
below.  It is not to scale.  This cycle was constantly repeated.

|< --------- .125 seconds ------------------------->|
|<***********|               |********|         |**>|
         |<-bc_dist active ->|   bc_sched active    |
|< -bus active ->|                              |<->|
|--------|-------------|----|------|------|----------
    t1         t2        t3    t4     t5       t1

The *** are periods when tasks other than the ones listed are executing.
Yes, there is some idle time.

t1 - bus hardware starts via hardware control on the 8 Hz boundary. The
transactions for the this cycle had been set up by the previous execution
of the bc_sched task. 
t2 - 1553 traffic is complete and the bc_dist task is awakened. 
t3 - bc_dist task has completed all of the data distribution 
t4 - bc_sched task is awakened to setup transactions for the next cycle 
t5 - bc_sched activity is complete

The bc_sched and bc_dist tasks check each cycle to be sure that the other
had completed its execution.  The bc_sched task is the highest priority
task in the system (except for the vxWorks "tExec" task).  The bc_dist is
third highest (a task controlling the entry and landing is second).  All of
the tasks which perform other spacecraft functions are lower.  Science
functions, such as imaging, image compression, and the ASI/MET task are
still lower.

Data is collected from devices connected to the 1553 bus only when they are
powered.  Most of the tasks in the system that access the information
collected over the 1553 do so via a double buffered shared memory mechanism
into which the bc_dist task places the latest data.  The exception to this
is the ASI/MET task which is delivered its information via an interprocess
communication mechanism (IPC).  The IPC mechanism uses the vxWorks pipe()
facility.  Tasks wait on one or more IPC "queues" for messages to arrive.
Tasks use the select() mechanism to wait for message arrival.  Multiple
queues are used when both high and lower priority messages are required.
Most of the IPC traffic in the system is not for the delivery of real-time
data.  However, again, the exception to this is the use of the IPC
mechanism with the ASI/MET task.  The cause of the reset on Mars was in the
use and configuration of the IPC mechanism.

THE FAILURE
The failure was identified by the spacecraft as a failure of the bc_dist
task to complete its execution before the bc_sched task started.  The
reaction to this by the spacecraft was to reset the computer.  This reset
reinitializes all of the hardware and software. It also terminates the
execution of the current ground commanded activities.  No science or
engineering data is lost that has already been collected (the data in RAM
is recovered so long as power is not lost).  However, the remainder of the
activities for that day were not accomplished until the next day.

The failure turned out to be a case of priority inversion (how we
discovered this and how we fixed it are covered later).  The higher
priority bc_dist task was blocked by the much lower priority ASI/MET task
that was holding a shared resource.   The ASI/MET task had acquired this
resource and then been preempted by several of the medium priority tasks.
When the bc_sched task was activated, to setup the transactions for the
next 1553 bus cycle, it detected that the bc_dist task had not completed
its execution.  The resource that caused this problem was a mutual
exclusion semaphore used within the select() mechanism to control access to
the list of file descriptors that the select() mechanism was to wait on.

The select mechanism creates a mutual exclusion semaphore to protect the
"wait list" of file descriptors for those devices which support select.
The vxWorks pipe() mechanism is such a device and the IPC mechanism we used
is based on using pipes. The ASI/MET task had called select, which had
called pipeIoctl(), which had called selNodeAdd(), which was in the process
of giving the mutex semaphore.  The ASI/ MET task was preempted and
semGive() was not completed.   Several medium priority tasks ran until the
bc_dist task was activated.  The bc_dist task attempted to send the newest
ASI/MET data via the IPC mechanism which called pipeWrite().  pipeWrite()
blocked,  taking the mutex semaphore.  More of the medium priority tasks
ran, still not allowing the ASI/MET task to run, until the bc_sched task
was awakened.  At that point, the bc_sched task determined that the bc_dist
task had not completed its cycle (a hard deadline in the system) and
declared the error that initiated the reset.

HOW WE FOUND IT
The software that flies on Mars Pathfinder has several debug features
within it that are used in the lab but are not used on the flight
spacecraft (not used because some of them produce more information than we
can send back to Earth).  These features were not "fortuitously" left
enabled but remain in the software by design.  We strongly believe in the
"test what you fly and fly what you test" philosophy.

One of these tools is a trace/log facility which was originally developed
to find a bug in an early version of the vxWorks port (Wind River ported
vxWorks to the RS6000 processor for us for this mission).  This trace/log
facility was built by David Cummings who was one of the software engineers
on the task. Lisa Stanley, of Wind River, took this facility and
instrumented the pipe services, msgQ services, interrupt handling, select
services, and the tExec task.  The facility initializes at startup and
continues to collect data (in ring buffers) until told to stop.  The
facility produces a voluminous dump of information when asked.  

After the problem occurred on Mars we did run the same set of activities
over and over again in the lab.  The bc_sched was already coded so as to
stop the trace/log collection and dump the data (even though we knew we
could not get the dump in flight) for this error.  So, when we went into
the lab to test it we did not have to change the software.

In less that 18 hours we were able to cause the problem to occur. Once we
were able to reproduce the failure the priority inversion problem was obvious.

HOW WAS THE PROBLEM CORRECTED
Once we understood the problem the fix appeared obvious : change the
creation flags for the semaphore so as to enable the priority inheritance.
The Wind River folks, for many of their services, supply global
configuration variables for parameters such as the "options" parameter for
the semMCreate used by the select service (although this is not documented
and those who do not have vxWorks source code or have not studied the
source code might be unaware of this feature).  However, the fix is not so
obvious for several reasons :

1) The code for this is in the selectLib() and is common for all device
creations.  When you change this global variable all of the select
semaphores created after that point will be created with the new options.
There was no easy way in our initialization logic to only modify the
semaphore associated with the pipe used for bc_dist task to ASI/MET task
communications.

2) If we make this change, and it is applied on a global basis, how will
this change the behavior of the rest of the system ?

3) The priority inversion option was deliberately left out by Wind River in
the default selectLib() service for optimum performance.  How will
performance degrade if we turn the priority inversion on ?

4) Was there some intrinsic behavior of the select mechanism itself that
would change if the priority inversion was enabled ?

We did end up modifying the global variable to include the priority
inversion.  This corrected the problem.  We asked Wind River to analyze the
potential impacts for (3) and (4). They concluded that the performance
impact would be minimal and that the behavior of select() would not change
so long as there was always only one task waiting for any particular file
descriptor.  This is true in our system.  I believe that the debate at Wind
River still continues on whether the priority inversion option should be on
as the default.  For (1) and (2) the change did alter the characteristics
of all of the select semaphores.  We concluded, both by analysis and test,
that there was no adverse behavior. We tested the system extensively before
we changed the software on the spacecraft.

HOW WE CHANGED THE SOFTWARE ON THE SPACECRAFT
No, we did not use the vxWorks shell to change the software (although the
shell is usable on the spacecraft).  The process of "patching" the software
on the spacecraft is a specialized process.  It involves sending the
differences between what you have onboard and what you want (and have on
Earth) to the spacecraft.  Custom software on the spacecraft (with a whole
bunch of validation) modifies the onboard copy. 

WHY DIDN'T WE CATCH IT BEFORE LAUNCH ?
The problem would only manifest itself when ASI/MET data was being
collected and intermediate tasks were heavily loaded.  Our before launch
testing was limited to the "best case" high data rates and science
activities.  The fact that data rates from the surface were higher than
anticipated and the amount of science activities proportionally greater
served to aggravate the problem.  We did not expect nor test the "better
than we could have ever imagined" case.

HUMAN NATURE, DEADLINE PRESSURES
We did see the problem before landing but could not get it to repeat when
we tried to track it down.  It was not forgotten nor was it deemed
unimportant.

Yes, we were concentrating heavily on the entry and landing software.  Yes,
we considered this problem lower priority.  Yes, we would have liked to
have everything perfect before landing.  However,  I don't see any problem
here other than we ran out of time to get the lower priority issues completed.

We did have one other thing on our side; we knew how robust our system was
because that is the way we designed it.

We knew that if this problem occurred we would reset.  We built in
mechanisms to recover the current activity so that there would be no
interruptions in the science data (although this wasn't used until later in
the landed mission). We built in the ability (and tested it) to go through
multiple resets while we were going through the Martian atmosphere.  We
designed the software to recover from radiation induced errors in the
memory or the processor.  The spacecraft would have even done a 60 day
mission on its own, including deploying the rover, if the radio receiver
had broken when we landed.  There are a large number of safeguards in the
system to ensure robust, continued operation in the event of a failure of
this type.  These safeguards allowed us to designate problems of this
nature as lower priority.

We had our priorities right.

ANALYSIS AND LESSONS
Did we (the JPL team) make an error in assuming how the select/pipe
mechanism would work ?  Yes, probably.  But there was no conscious decision
to not have the priority inversion enabled.  We just missed it.  There are
several other places in the flight software where similar protection is
required for critical data structures and the semaphores do have priority
inversion protection.  A good lesson when you fly COTS stuff - make sure
you know how it works.

Mike is quite correct in saying that we could not have figured this out
**ever** if we did not have the tools to give us the insight.  We built
many of the tools into the software for exactly this type of problem.  We
always planned to leave them in.  In fact, the shell (and the stdout
stream) were very useful the entire mission. 

SETTING THE RECORD STRAIGHT
I want to make sure that everyone understands how I feel in regard to Wind
River.  These folks did a fantastic job for us.  They were enthusiastic and
supported us when we came to them and asked them to do an affordable port
of vxWorks.  They delivered the alpha version in 3 months.  When we had a
problem they put some of the brightest engineers I have ever worked with on
the problem.  Our communication with them was fantastic.  If they had not
done such a professional job the Mars Pathfinder mission would not have
been the success that it is.



Embedded Seminar! Washington and San Jose
------------------------------------------------------
I'm conducting a full-day embedded seminar in the DC area on January 29 and
in San Jose on February 26. It's called "The Best Ideas for Developing
Better Firmware Faster", and is for 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(aatt_sign)ganssle.com. 


Thought for the Week
--------------------
The Six Phases of Every Project:

1. Enthusiasm
2. Disillusionment
3. Panic
4. Search for the Guilty
5. Punishment of the Innocent
6. Praise and Honors for the Non-Participants


About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.





-----------------------------------------------------------
Volume 3, Number 1   Copyright 1998 TGG     January 6, 1998
-----------------------------------------------------------
You may redistribute this newsletter for noncommercial purposes. For
commercial use contact info(aatt_sign)ganssle.com. 

EDITOR: Jack Ganssle, jack(aatt_sign)ganssle.com

CONTENTS:
- Editor's Notes
- EC++
- Embedded Seminar in DC and San Jose
- Thought for the Week
- About The Embedded Muse


Editor's Notes
--------------
Happy New Year to all readers of The Embedded Muse! Let's hope this is the
year we get our projects out on-time and with the minimal number of bugs.
Let's also hope that as we head towards the millennium we start to learn
more peaceful ways of dealing with conflict, both global and personal.

I'm doing my "The Best Ideas for Developing Better Firmware Faster" seminar
in DC on January 29, and in San Jose on February 26. More info follows in
this newsletter.


EC++
----
Long time readers of The Muse know that I'm a great fan of small systems -
those 8 and 16 bit embedded systems that surround us in life.

Yet if you regularly read the trade press you'll be hard pressed to find
much written about these small systems. Believe what you read and you'll
soon come to the conclusion that even the smallest application requires a
32 bit CPU with 2 Mb of ROM and RAM.

One theme we've been inundated with is C++. You can hardly open a magazine
without getting the feeling that C++ is the most common language around.
Few articles indicate, though, that C++ is best used only on the largest
systems. Forget about it for 8 bits; be very wary of using it on 16 bitters.

Though C++ does indeed bring great benefits to the art of programming, its
huge footprint and performance problems limit its usefulness in a lot of
embedded systems. Happily, some of the original C++ proponents are working
on a subset targeted specifically at the embedded market. EC++ is a reduced
version of C++ that brings many of the OOP benefits while eliminating those
features that create excessive burdens for real time, embedded work.

If you're contemplating the use of C++ for your next system, check out
http://www.caravan.net/ec2plus/, which is the home page of the group
developing the new standard. 

The goal of developing EC++ is to create a subset of C++ that is easy to
use, and that is targeted to the unique needs of embedded systems. The
group feels EC++ will avoid excessive memory consumption, support the
creation of ROMable code, and be entirely predictable in its response.

Noble ideals indeed. 

Several vendors either support the draft EC++ spec already, or plan to
soon. These include Greenhills, Metrowerks, and Hiware.

Before redesigning your system for EC++, though, be aware that the
committee designing the EC++ spec has little to no interest in 8/16 bit
support. EC++, like it's bigger brother, will be targeted primarily at 32
bit applications.

For more information on this new language, check out P. J. Plauger's
article on the subject in the December issue of Embedded Systems
Programming. He gives a great overview of the differences between EC++ and
C++, as well as a history and rationale behind its development.



Embedded Seminar! Washington and San Jose
------------------------------------------------------
I'm conducting a full-day embedded seminar in the DC area on January 29 and
in San Jose on February 26. It's called "The Best Ideas for Developing
Better Firmware Faster", and is for 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(aatt_sign)ganssle.com. 


Thought for the Week
--------------------
Steve Litt, Webmaster of Troubleshooters.Com
(http://www.troubleshooters.com), sent along this gem in response to the
Valgol language description in the last issue of The Embedded Muse:

It was gratifying to see your thorough and accurate coverage of the VALGOL
language in the Embedded Muse 12. Did you know that there's now an OOP
version? In much the same way that C evolved into C++, VALGOL has evolved
into VALGOL TO THE MAX. It's been endorsed by the Association of Ventura
Blvd Clothing Merchants, so I must use it on a daily basis (I live in
Reseda). I'll show you a snippet from one of my VALGOL TO THE MAX programs
(a POS system). Although this language is readable to the point of
self-documentation, I'm including comments for those not familiar with VALGOL.

VALGOL TO THE MAX'S power comes from its terse readability, its powerful
collection of error handling, and its self referential application pointer,
called deeeude (similar to "this" in C++, but for the application only).

//*****************************************************
//This partial file copy program copies certain records 
//between files
//*****************************************************

like y*know (i mean) start.
FILE Tiffany = make a file.
If Tiffany isn't totally stoked 
    bag your face, deeeude.         //abend
FILE Sean = make a file.
If Sean isn't totally stoked
    bag your face, deeeude.         
Sean sells at the mall              //open file Sean for input
If Sean isn't just totally awesome, 
    later days deeeude.             
Tiffany shops at the mall.          //open file Tiffany for output
If Tiffany can't hang, 
   like, barf me out, deeeude.      

//Transfer only records whose key field equals "Nirvana".
Tiffany buys all Sean's Nirvana records - oops, sorry deeeude, I mean CD's.
If any CD is bogus, 
   deeeude -- gag me with a spoon.  //extra-fatal abend   
Sean and Tiffany go home.           //close the files
Reseda rules, deeeude.              //exit the subroutine



About The Embedded Muse
-----------------------
The Embedded Muse is an occasional newsletter sent via email by Jack
Ganssle. Send complaints, comments, and contributions to him at
jack(aatt_sign)ganssle.com. 

To subscribe, send a message to majordomo(aatt_sign)ganssle.com, with the words
"subscribe embedded email-address" in the body. To unsubscribe, change the
message to "unsubscribe embedded email-address".

The Embedded Muse is supported by The Ganssle Group, whose mission is to
help embedded folks get better products to market faster.





Back to the top.