Volume 3, Number 8 Copyright 1998 TGG April 9, 1998
You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org.
EDITOR: Jack Ganssle, email@example.com
- 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” 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 firstname.lastname@example.org.
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