'About The Embedded Muse'
|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 ganssle.com.info
EDITOR: Jack Ganssle, ganssle.comjack
- Editor's Notes
- An Embedded History - Part 2
- Thought for the Week
- About The Embedded Muse
I'm doing my "The Best Ideas for Developing Better Firmware Faster"
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
work. A recent call caught me short when a fellow wondered if The
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
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
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,
prompted a lot of response from readers. Almost concurrently a couple of
articles in Embedded Systems Programming magazine discussed why a
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
http://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
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
the 8008-based controller. The first computerized version had a 4k
- unbelievably tiny by today's standards, huge by those of the day. It
16 ROMs (1702s, the only game in town at the time, had a whopping 256
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
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
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
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
The monitor didn't have a mini-assembler, so we quickly learned all of
machine codes for the 8008's instruction set - not much of a feat when
consider how limited that set was.
Sometimes we could patch right on top of the code. When the change was
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
After a day of debugging, we'd have lots of changes (hey - we were kids
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
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.
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
Despite the troubles things worked, and we delivered hundreds of units
a couple of years. Time moved on and we later used better processors and
algorithms; people left the company, replaced with others not familiar
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
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
hardware and software, to identify and stamp out bugs, to manage risk,
to meet impossible deadlines.
For more information check out http://www.ganssle.com or email
Thought for the Week
SILICON VALLEY LINGO:
"percussive maintenance" - the fine art of whacking a device to get it
"prairie dogging" - in companies where everyone has a cubicle --
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
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.
"meatspace" - the physical world (as opposed to the virtual), also
"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
To subscribe, send a message to ganssle.com, with the words majordomo
"subscribe embedded email-address" in the body. To unsubscribe, change
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
Sombody shoot this man It is provoking serious ROTFL after several pints of
Sorry for wittetring my fingerst is havbbig troble locatyuing the
Cyheers steve r................
Wrtiong everu one is ronllling on the floore laffffineg at my
Byyei sorry fo r awastinfg bandwidth............ Steeeeeeveee.........
More... (looser matching)
- Last day of these posts
- In 1998
, 1999 only
- New search...