Embedded Muse 125 Copyright 2006 TGG February 22, 2006

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- Book Review – How Computers Do Math
- Pre-CAD
- Yet More on Tools
- Jobs!
- Joke for the Week
- About The Embedded Muse

Editor’s Notes

Then I ran across this super-cool computer built using 415 relays as the active elements: http://www.cs.pdx.edu/~harry/Relay/index.html . There’s a short video of the thing operating linked from the site; unfortunately it’s silent. I bet the clacking noise is impressive.

Denver and Dallas – Learn to develop better firmware faster in my one-day seminar in Denver on April 26 and Dallas April 28. Details at: https://www.ganssle.com/classes.htm. With luck there might be some decent skiing in the Rockies that week!

TV chef Emeril is always “kicking things up a notch” by adding garlic and other zestiness to his recipes. How are your firm’s engineering recipes? Want to kick up your development processes by more than a notch? I can present my Better Firmware Faster class at your facility. See https://www.ganssle.com/classes.htm .

Book Review – How Computers Do Math

The book is aimed at people starting out in computers; we embedded experts know this stuff cold. But an interested 15 year old could get truly in-depth insight into the mysteries of computing from this volume.

It’s a very readable book laid out with easy-on-the-eyes formatting and a plethora of clear illustrations. The illustration of a LIFO stack just booms clarity. Chapters start with relevant and often amusing quotes; one of my favorites is Lewis Carroll’s “The four branches of arithmetic: ambition, distraction, uglification, and derision.”

Quickly page through the book and you’ll be puzzled by its organization. The first 55 pages (out of 450) comprise its ostensible meat. The rest are labs for each chapter, a series of problems the authors pose to illustrate important concepts. They nudge you through the solutions – there are no proofs left to the confused student.

The labs are very well-written accessible activities in which the authors take the reader along hand-in-hand. They’re a bit insidious: work through them and the reader will become a reasonably competent assembly-language programmer, without realizing he’s learning one of the more difficult aspects of programming. There’s a perverse genius in covertly slipping assembly language into one’s head without pain.

The authors’ sure hands guide one along each lab, with descriptions and demonstrations till the code that’s required is almost anticlimactic: “of *course* it must be like this!”

But how is one to do a lab? You need a computer, right? Well, sure, but the authors provide a DIY Calculator on CD, an interactive and sophisticated bit of code that runs on a PC. It sports the usual display and math functions, plus its own low-level programming language. And, it’s extensible. The companion website (http://www.diycalculator.com/aboutdiy.shtml ) contains plenty of downloadable extension code, plus the calculator itself. Like open source advocates they hope the community will contribute to the set of routines.

The web site also has a fabulous background to the field of computing (http://www.diycalculator.com/cool.shtml#PhyVer ) that, if you’re a history buff like me, will suck you in and surely doom the schedule of whatever product you’re working on now.

Where too many computer books have a dreary chapter about number systems, “How Computers Do Math” cover the subject in an entertaining and very complete fashion. From basic binary math they go on to show how one constructs an adder out of gates. Signed, unsigned, multiplication, rounding (9 different approaches!), BCD – it’s all there, and it’s all extremely comprehensible.

The book is published by John Wiley & Sons, Hoboken, NJ, copyright 2005, and sells for $26 on Amazon.

Pre-CAD

Long ago, back in the 70s, there were no personal computers or similar tools we take for granted. The life of a digital designer was very different indeed.

Drafting was a skill all mechanical engineers mastered in college, but for some reason, at the University of Maryland, it was not considered important for electronics guys (guys - all guys. There were virtually no women in the field then). Some engineers were nothing short of gifted artists, creating schematics that filled the paper in a visually pleasing way. Others, myself included, could hardly draw a straight line even with the aid of a drafting machine.

Lettering was a fine art. It’s hard to imagine this now, when we select from a thousand fonts with a few mouse clicks, but neat signal names were essential. Some designers used lettering templates. I always found these too cumbersome, and so subjected all readers of my drawings to the same illegible scrawl that the nuns weekly punished me for in grade school.

Every branch of engineering had its unique set of templates. Digital designers used a handful of plastic stencils that contained the entire stock of resources we worked with: AND and OR gates, inverters and “not” circles, and, of course, various sized squares and rectangles for microprocessors, memories, and everything else. Large chips were rare then; the largest might have a whopping 64 pins, which wasn’t too hard to draw.

We drew resistors, capacitors, and other components using similar stencils. With a little practice you could whip the pencil through the zigzag of a resistor template in no time, though a not-perfectly-sharp pencil always resulted in only a hazy image of the part.

Though Luddites scoff that computers let us make mistakes at new, unprecedented rates, in fact even with these crude tools we were quite competently creating errors faster than decent designs. In lieu of a “delete” key we used erasers. Erasers in every form imaginable. In fact, most of us made so many mistakes we used electric erasers, a motorized drill-like device that spun a cylinder of gum-like material. Though these quite effectively removed vast areas of pencil lead, careless use always produced a hole in the vellum. Then what? I suppose mil spec folks started over, recopying the entire drawing onto a fresh sheet of paper. Where I worked we glanced furtively over the shoulder, and rerouted signals around the hole.

Drawings produced by hand - by sloppy electronic folks - had much wider line widths and larger lettering than that we make on computer screens today. As a result the drawings were big. Though some folks used “C” size paper (17 by 22 inches) generally “D” (22 by 34) was the norm. Engineers, production people, and technicians all looked like quintessential architects, with stacks of these monsters on every flat surface. When troubleshooting a new design the first step was to position a big table next to the lab bench - just to hold the drawings.

We drew on vellum, a gauzy semi-transparent material that was pretty tough. It took repeated erasures well, though somehow I always managed to drill a couple of erasing holes through each drawing.

Today we use mostly “A” and “B” sized paper, as that’s all laserprinters handle. You can fax or Xerox these drawings without trouble. An ordinary filing cabinet is the perfect storage place. Back then, every business had a “drawing room”, dedicated to nothing more than storing (in cabinets called “flat files”) and reproducing these huge representations of our tiny circuits. Most companies had people whose entire role was to file and copy these.

No copier then or now could handle a sheet of D sized paper. One reason we used vellum was its transparency. An engineer duplicating a drawing first put it on top of an equal-size piece of paper coated with a light-sensitive chemical, and ran it through the Ozalid machine. This beast beamed a very intense light through the vellum, exposing areas with no pencil marks. It then treated the paper with ammonia, which turned the unexposed areas blue. The ever-present smell of ammonia (and second hand cigarette smoke!) was simply a part of the engineering environment.

Once the ammonia line broke in the middle of the night. In the morning the entire building was uninhabitable. Fire department fans eventually sucked the fumes out, but we found strange chemical changes in our environment. One secretary’s fake flowers changed to a wonderful purple shade. Many pictures hanging on walls now looked like 19th century daguerreotypes. And, of course, several thousand dollars of unused Ozalid paper were completely developed, bright blue reminders of the incident.

Now drawings have no value. Did you spill coffee on a schematic? Just print out a new copy. The information itself if immensely valuable, but its paper incarnation is sacrificial.

Before CAD systems the paper was the only representation of a drawing. The labor required to recreate one was so immense that it was simply inconceivable to lose or mar a schematic. It’s funny to realize that one promise of computerization was the paperless office, yet what has happened is paper is now so prevalent that it’s worthless. By contrast, in the olden days an original drawing was a holy relic. Copies were scarce because of the cost of duplication and the nuisance of storing the bulky papers.

The regulations said no drawing left the files unless it was being duplicated or was on an engineer’s drafting board. Most of us flaunted these rules when the Ozalid machine (which required an hour to warm up) was off at night and we were engaged in a furious troubleshooting war. Living dangerously, with the original by the bench, we’d hope to be done by morning when the drawing police came in. More than one drawing went back in the files with food stains in the corners.

I suppose it goes without saying that there were no PCB software packages. Either our engineers or outside contractors, leaning over a light table for weeks on end, routed tracks by placing black tape on sheets of mylar. It was a game of chess: the best board designers developed a mental plan of attack which (they hoped) would let them get all of the tracks down without running into dead ends. How things have changed! Now it’s great fun to watch the routing program automatically plopping traces down onto the virtual board, at a speed that takes my breath away. In the 70s a big board took weeks, even months, to design.

They routed on mylar, as paper isn’t dimensionally stable when subjected to humidity variations, and the PCB was made via a photographic reduction of the drawing. My dad, a mechanical engineer from way back, tells me that in the 50s they had the same problem with paper when designing airplanes. Since this predated even mylar, they drew on starched linen in ink. Apparently the linen was stable, but it couldn’t tolerate water. One drop of sweat dissolved the starch, ruining the drawing. And this was before Grumman, his employer, had air conditioning.

Me, I’m thankful for modern CAD. I’d never go back to those tedious days of yore.

Yet More on Tools

Several people suggested Ethereal. David Hinerman wrote: “On the topic of tools: I highly recommend Ethereal (http://www.ethereal.com) for Ethernet packet sniffing. We just got done adding an Ethernet interface to several of our products and this was indispensable. It's also free. It's available for Windows, Linux, and Unix.”

Henk Dijkstra contributed: “My tip would be srecord http://srecord.sourceforge.net by Peter Miller, to manipulate target files for embedded systems.

“It has default support for numerous fileformats, and you can easily add new formats to it. By applying filters to the input files, you can also manipulate it if needed (like adding CRC/Checksum or crop/fill/exclude parts and much more).

“Another useful item for adding lightweight threads to an (existing) application is: Protothreads by Adam Dunkels: http://www.sics.se/~adam/pt/ . It consists of a few include files defining MACRO's that are used to implement threads as switch/case constructs. I have used it to easily add functionality in existing complex systems with high timing constraints.”

Shaun Kaplan wrote: “In the last issue, under the tools discussion, Gennady Palitsky wrote in about ContentSaver. I too was looking for a similar tool and last week went flipping through the Firefox extensions and found one called Scrapbook (http://amb.vis.ne.jp/mozilla/scrapbook/). I've only had it a few days and I've never tried ContentSaver so I can't give a comparison but so far I'm very happy with it.”

Jobs!

Joke for the Week

Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that goes to 48,000+ engineers. Click here to sign up or enter your email here: