Tweet Follow @jack_ganssle

Embedded Muse 153 Copyright 2008 TGG January 8, 2008

You may redistribute this newsletter for noncommercial purposes. For commercial use contact

EDITOR: Jack Ganssle,

- Editor’s Notes
- Book Review
- Open Spaces, Continued
- Tools and Tips
- Jobs!
- Joke for the Week
- About The Embedded Muse

Editor’s Notes

Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it’s not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See .

For the first time, I’ll be conducting a public version of this class in Denmark in April. For more information see .

Embedded Systems Design magazine (nee Embedded Systems Programming) is now 20 years old. Turns out there are some copies of issue number one, though they are jealously guarded. I ran into Rich Nass, the Editor-In-Chief, at a meeting in Santa Barbara last month. He was on his way north to return the magazine’s only copy of the issue, as it was too valuable to entrust to the postal service! Maybe there are more extant copies of the Magna Carta. The staff scanned the issue and allowed me to post it here: . Be warned: that’s a 50 MB file.

Talking about ancient history, the product that started the entire microprocessor revolution, the 4004, has its own site: . This has some amazing links, including the schematics of the device itself (to the transistor level), which takes only 3 pages! The reconstructed source code of the Busicom calculator is there as well, I’m sure much better documented than originally. The square root algorithm is fascinating.

John Johnson sent a link to this fun and very educational FPGA site: .

Finally, Happy New Year to all and best wishes for a prosperous, safe, and fun 2008.

Book Review

Jan Axelson has carved herself a niche providing complete information on a number of different communications schemes. Her Serial Port Complete is The Standard Reference on the subject, and is now available in a second edition.

Though PCs generally don’t come with an RS-232 port anymore, there are still a tremendous number of embedded apps that use these interfaces, so the subject remains important. But she has greatly enhanced the book with examples in C as well as the Basic used in the first edition. And there’s complete examples for the .Net environment as well, along with information about doing serial over wireless and using USB virtual COM ports.

If you’ve been in this industry for a good long while, perhaps earning some gray hair and an ulcer in the pursuit of embedded ones and zeroes… you probably still get mixed up about serial protocols. Is a “one” a negative or positive level in RS-232? In what order are the bits transmitted? What pin is what on a DCE versus DTE device?

The book starts off with a description of the asynchronous protocol used by RS-232, and then moves on to the PC’s serial port structure.

For the embedded person, though, the interesting stuff starts with a useful overview of PIC serial ports, again accompanied by code. Axelson goes on to give a complete look at the characteristics and use of RS-232 for connecting two devices - include the usually ignored problem of powering a device from the RS-232 port. She gives great advice about building isolated connections and on debugging problems

If you’ve ever built systems that communicate via RS-232 you know how difficult it can be to get things working properly. Axelson goes over both the problem of communications between an embedded system and the PC, and between networks of embedded systems.

RS-485 is still going strong in a lot of applications, and Jan covers that subject completely, both from the hardware and software perspective. If you’re using 485 this book is worthwhile just for those two chapters.

Jan’s book is about as complete a reference as you’ll find on serial communications using RS-232 and RS-485. The code could save you some time; the reference material surely will.

Open Spaces, Continued

Tom Mazowiesky had some comments on open spaces
“A comment on the 'Open Space' - A few years ago Ben Rich wrote of his experience as an engineer working for Kelly Johnson of the Lockheed 'Skunk Works', titled 'Skunk Works: a personal Memoir of My Years of Lockheed'. His story of development of the U2, the SR-71 and the F-117A Stealth fighter are great reading.

“He described his office working conditions basically as being crammed into the available space. While working on the SR-71, he removed a door separating his office and the adjacent office to allow another engineer and himself to update a drawing at the same time. These offices were located next to the shop floor, and engineers were expected to spend a portion of the day on the shop floor. They also left their doors open to anyone on the shop floor for questions and ideas. As we all move to the new global marketplace, I worry about our ability to engineer great products when the engineers are separated by thousands of miles from their creations. I've always gotten a kick out of seeing product literally go out the back door, and I wonder how we will keep that going in the new environment. Engineers are human, and while we all joke about how analytical and nerdy we are, we still put our emotions into the job and the products we design. Something is lost if we are removed from the factory floor.

“Personally I've always liked to have a quiet space when working on certain things, but I've also worked in open spaces, and they can be very productive as well. I think a lot has to do with the people who occupy the space, rather than the space itself. The managers who create good teams of dedicated people will always perform well, because those people understand the problem and have learned how to solve them in the past.”

Tools and Tips

In Muse 152 Paul Carpenter sent in a font to create timing diagrams ( ).

Dave Kellogg followed up with this: “This Timing font allows you to easily draw timing diagrams in Word, etc.

“To install the Timing font, I simply copied the "timing.ttf" file to my "C:\Windows\Fonts" directory. If you have problems, see "Install a new font on your computer" at "".

“Print out a copy of “Timing Font Crib Sheet.gif" to see the Timing font's keystrokes. The key mapping is well thought out.

“To use the Timing font in Word (on a PC with the font installed), simply change the font to "Timing", and use the keys (shown the crib sheet) to draw the waveform. Like any font, you can change its size, bold it, color it, high-light it, etc. The Timing font's characters are fixed width.

“To make sure that the Timing font is properly displayed on different computers without the Timing font installed (in Word or PowerPoint), embed the Timing font directly in the document. This will increase your document's file size by about 15K.
1. On the Tools menu, click Options, and then click the Save tab.
2. Under Save options, select the Embed TrueType fonts check box. Do >>NOT<< select the "Embed characters in use only" box.

“The timing font must be embedded for each document (i.e., it is not a permanent setting in Word). When the recipient opens the document, the Timing font is >>NOT<< installed on the recipient's computer.

“On PCs without the Timing font installed, a Word document containing the embedded Timing font will not show the "Timing" font as available in the Font drop-down box. However, it is possible to edit and create additional timing diagrams by using the Format Painter to clone the Timing font from some existing Timing font. So in effect the Timing font is available.”


Joke for the Week

Rick Miu sent in the following:

"To be or not to be... that is the question."

The answer is 0xff since:

0x2b | ~0x2b = 0xff