You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• What I'm Reading
• More on the Teletype
• More on Datasheets
• Buggy Airplanes
• Using Bugs to Get Fit
• Joke for the Week
• About The Embedded Muse

How do you get projects done faster? Improve quality! Reduce bugs. This is the central observation of the quality movement that totally revolutionized manufacturing. The result is a win-win-win: faster schedules, lower costs and higher quality. Yet the firmware industry has largely missed this notion. Deming et al showed that you simply can’t bolt quality onto an extant system. But in firmware there’s too much focus on fixing bugs rather than getting it right from the outset.

In fact it is possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Learn how at my one-day, fast-paced Better Firmware Faster class, presented at your facility. There's more info here.

Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter. - Eric S. Raymond

Please submit neat ideas or thoughts about tools, techniques and resources you love or hate.

Bill Long had a couple of ideas: [I have] two ideas for your 'Tools & Tips' section I thought I'd submit in hopes someday they're incorporated into a product.  I firmly believe that anything hardware can do to improve software helps all, both ideas are related to this concept.
 
The first idea involves detecting NULL pointers, a continual bane to test organizations everywhere.  I would like to see a processor issue an ABORT if a read/write ever occurs when a base register is zero.
 
The second idea involves detecting stack overflow.  A processor could be designed using a stack limit register to detect if a stack read/write operation ever exceeded its storage limit.
 
We all work in an industry with ever-increasing complexities, I would love to see hardware that promotes better software.
 
Some CPUs do include a memory management unit. Some of those - like on Intel's desktop chips from the 386 on - have enough capability one could program them to detect these conditions.

Chuck Petras sent some sites that are pretty interesting for those wanting to know more about electronics: Here's a site on basic car audio electronics which is very engaging.  Another is geared towards the car audio enthusiast who wants to learn about and repair his equipment.

What Good Are Strong Specifications?

Nick England sent this link to a Teletype FIFO - it uses a bin of tape for memory and a mechanical marvel to read the last character written.

John Nagle sent his history of the Teletype:

It took a long time to get printing telegraph machines right. The first one was built in 1852, but the Teletype Model 14, the first really good one, didn't come out until 1926. The 19th century designs worked by getting a rotating typewheel at both ends in sync, then sending a pulse when it was time to print something. Synchronization was a tough problem. Flyball governors were used to get both ends running at the same speed. To pull things into sync, when a pulse came in, a pawl was briefly dropped into a gear to correct sync errors smaller than half a character time. Startup required operator coordination at both ends, sending AAAAA and adjusting the receiver until it printed AAAAA. Huge headache, but once everything was synched up, text could be sent continuously. If the receive end got out of sync, the operator would open the circuit, which caused the sending end's printer to stop. Both operators then had to do the resynch drill. Unattended operation was not possible.

There was a whole patent category of "unison devices" for achieving sync. Edison's first big success was a means for getting stock tickers in sync. Stock tickers were steppers, rather than continuous spinning typewheel machines. Edison added a mechanical timeout; after enough pulses in a idle state, the machine was forced to a ground state, from which both ends could then be stepped synchronously. This, if it it got out of sync, would get back in sync. Now unattended reception was possible.

Interestingly, nobody thought to invent a mechanical phased locked loop. It was technically possible, but the math of phased locked loops didn't exist yet.

Then came Baudot and Krum and "start-stop" async. The concept appeared around 1900, and it looked like today's async transmission. Sending was straightforward, but the receive end was tough. Early machines worked just the way you'd expect - a clutch started a distributor, the bits were fanned out to a 5-bit register (made of relays), then parallel-transferred to a second 5-bit register (also made of relays), then send to 5 solenoids which drove a mechanical 1 out of 32 decoder. The early Morkrum machines and the Teletype Model 12 worked that way.

The problem was that all those relays had time constants, and they all needed adjustment. Remember, there were no scopes yet. The tools to look at things in the time domain barely existed. So those machines needed too much adjustment, and were not widely deployed. But they worked.

Now, with working machinery deployed and typing constantly, the second level of problems appeared. Teletype machines were deployed in a world that had few complex devices, and they had to operate far from people able to maintain them. The early machines were built on Remington typewriter frames. The Remington machines weren't designed for continuous motor- powered typing for years at a time, and the linkages wore out. The relay adjustment problem was a headache. They had to make the machine work reliably in the field.

First, everything had to be beefed up. Morkrum-Kleinschmidt (later Teletype Corp.) started doing their own designs and making their own parts. Heavy cast-steel frames. Precision stamped parts. Locknuts on every screw. Design features to prevent the machine from being damaged - turning the motor backwards will not hurt the mechanism, and typebars are only powered for the first half of their travel, so if a typebar sticks, the typebar pileup will not damage the machine. A keyboard mechanism where the mechanical binary encoder doubles as an interlock preventing pressing two keys at once, or pressing a key before the previous character has been encoded. They built the typing unit as a removable module; remove some thumbscrews and it lifts out, disconnecting all the electrical connections. Field swaps were easy.

And, interestingly, an end to all the relays. The selection mechanism became entirely mechanical, driven from a camshaft. As long as the motor was within about 5% of the nominal speed, the device would work.

Incidentally, the 1.5 stop bit thing is there for a reason. If the stop time is an odd length, if the receiver gets out of sync, it will drift back into sync in a few character times, even when characters are being sent at full speed. With a stop bit that's a multiple of the bit time, and an appropriate bit pattern, you can stay out of sync.

By 1930, with the Teletype Model 15, they finally had the reliability problem solved through design and manufacturing overkill. To prevent rust, they Parkerized the parts, a process usually used only on guns. To prevent wire insulation deterioration, a problem with the pre-1930 models, they used General Electric Deltabeston felted asbestos insulation ("will not age or crack", and in machines today, it remains in good condition, safe if you don't strip the wire.) They avoided using rubber; the platen rollers are hardwood in early models, and the carriage return stop, instead of being a bumper, is a bell-crank, piston, air dashpot, and spring-loaded pressure relief valve. Most Model 15 machines that exist today can still be made to work with a good cleaning and oiling. The same model was manufactured from 1930 to 1959, with few changes.

The machines were designed for maintainability. It is quite possible to completely disassemble a Teletype down to the individual parts, reassemble it, and get it to work. Any part can be replaced if necessary. Few parts require much disassembly to reach.

There's considerable elegance in the design. Working on one, you can sense that the problem you're dealing with was considered by the designers and a way to solve it exists. It's a worthwhile exercise for machine designers to understand an early mechanical Teletype. Good machine design is difficult, and these machines are one of the greatest examples of the art.

While reliability and ruggedness had been achieved, "quiet", "user-friendly", and "low-maintenance" were a long way off. The machines were still maintenance-intensive. A Model 15 has over 300 oiling points, and requires oil and two kinds of grease. Annual maintenance in heavy use involved removing the two electrical parts (the motor and the selector magnet) and soaking the entire printing unit in solvent, then re-doing the oiling drill. Few people would put up with that today. This is the price of maintainability.

Last issue I complained about datasheets today. It's not just the datasheets; even web sites that ostensibly serve engineers are filled with meaningless noise. Here's a snapshot of a tiny part of a web site that lists documents for one microcontroller:

It's a guessing game as to what those documents are.

One reader, who works for a major semiconductor vendor, responded with a challenge: What should a datahseet contain? With tongue in cheek I replied: "a complete transistor-level schematic of the part!" Actually, I appreciate how hard it is to really document these complex devices.

But it's frustrating when electrical parameters are not fully characterized. Often only typical values are given, not max and min. Some vendors treat these components as logic devices, when the truth is there are a lot of electronic issues involved (voltages, currents, etc).

Many devices today gloss over timing issues. ARM parts, for instance, very often have datasheets that skip basic issues like how many wait states are needed for internal flash, or how fast things really run. "89-zillion GHz" sounds great until one realizes that most of the time the thing needs to wait for memory.

What do you want in a datasheet?

Spotted in Norway:

The "BUG" label on the front landing gear door doesn't inspire confidence!

So you’re leaning back in that uber-recliner facing the 20" monitor, IR keyboard in your lap, editing, compiling, and debugging at warp speed. The nifty 3 Ghz Pentium stuffed with a bunch of gig of RAM and enough disk to hold every YouTube video screams through compilations and links. A quick alt-tab to the debugger window and a single button press starts the download.

But then you wait. And wait some more.

In the good old days when in-circuit emulators reigned supreme vendors competed on ultra-fast downloads. 64kbps went to 128 and then 1mbps and beyond. It wasn't long before we expected nearly instantaneous transfers. But today most developers use a JTAG or BDM debugger, a serial device with sometimes pathetically slow download speeds. Worse, even the zippiest protocols collapse to a glacial pace when writing to Flash memory.

So what do you do while waiting for the tool? Click over to Slashdot? Search for those Paris Hilton pictures? Send angry emails to your boss through an anonymizer?

One friend does jumping jacks.

I can tell when things are going badly for him. He buffs up. Large projects with lots of bugs and thus plenty of fixes and resultant downloads morphs his usual skinny frame into a figure more like an ex-governor of a large Western state with a recent new book than that of a typical nerd.

Buried in a hole of a lab with no windows – other than those supplied by Microsoft –a sickly fluorescent-light pallor, inch-thick glasses sliding down a narrow nose, at 56 years old "Bob" felt that first scary chest twinge. It wasn't a heart attack, but after presenting a clean cardiovascular bill of health the doctor admonished him to cut the cholesterol and above all to get some exercise. "Exercise?" he wondered, "is there a pill for that?"

Crazy schedules means Bob spends far too many hours hunched over the keyboard. A 90 minute commute followed by that desperately-needed cocktail leave neither time nor incentive for any sort of workout.

But he figures any problem has an engineering solution. Doing jumping jacks during those wasted downloading minutes reduces stress and keeps him healthy.

I was thinking about this (instead of doing jumping jacks) and realized:

Clearly this formula tells us that big buggy code == buffer. But "buffer" doesn't’t mean that thing malloc() allocates from the heap.

Suppose we wish to optimize variable exercise (we are engineers, after all, and wish to improve, well, everything). Various sources suggest 60 minutes a day. Transforming equation 1:

One tool I've used downloads at 150 μsec/byte. Using this number, the following chart shows how many downloads per day we need to achieve 60 minutes of exercise and those killer abs:

The data is stark. Early in the project before there's much code seed your programs with bugs. Lots of bugs. Taper off as the project grows. If you don't, if you maintain a fixed bug rate, not only with the project be hideously late, you'll get the grotesque shape of those monsters that adorn the covers of bodybuilding magazines.

I suppose there's a corollary to this: Managers beware. Hire only the weak and infirm. Ultrafit programmers write buggy code.

Note: These jokes are archived at www.ganssle.com/jokes.htm.

From Tom Walter:

Engineering Humor: My girlfriend left a note on the fridge, "It's not working. I can't take it anymore. I'm going to my Mom's place."

I opened the fridge.  The light came on. The beer was cold....  What the hell is she talking about?

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com.

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