Embedded Muse 140 Copyright 2007 TGG February 5, 2007

You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

- Editor’s Notes
- Free Books
- Tools & 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 all this and much more at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/brochure-onsite.pdf .

Robin Robins has a short must-read piece called “The five dumbest things computer consultants consistently do to sabotage their success.” If you’re in the consulting business, check it out at http://www.connectitnews.com/usa/story.cfm?item=387 .

TI announced that they won’t develop process technology past the 45 nm node, instead planning to rely on outside fabs for smaller geometries in the future. According to the December 4, 2006 EE Times “Under the Hood” issue, at 65 nm the gate oxide is an astonishing 6 or 7 atoms thick! http://www.geek.com/news/geeknews/2006Jan/bch20060202034541.htm claims a 45 nm fab costs some $3.5 billion. Do go to that site and click on the picture of the 4004, Intel’s very first processor, which shows its relative size at 10,000 nm (1971 technology) all the way down to 45 nm.

Ben Sweet pointed out that Freescale has a nice learning kit available: 16-bit HCS12 DG128 Stand Alone Student Learning Kit (http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=LFEBS12UB&fsrch=1 ). He writes: “It includes a microcontroller board with TWO MC9S12DG128 microcontrollers (one for the target and one for the host interface to the PC), various pre-wired I/O circuits (LEDs, switches, CAN and LIN interface, AND MORE!), circuit prototyping area, CodeWarrior IDE, AND a Lab Manual that walks users from elementary assembly programming and interface through Embedded C-programming using the IDE. All for about $100! (Less than the price-tag on many college text books!)”

Free Books

My parents came of age during the Great Depression. Consequently my siblings and I were raised in a strict, never-waste-anything environment that I’ve tried to inflict on my own kids.

But despite trying to be minimally consumptive, we sure do acquire a lot of stuff. Books are my bane; Amazon’s One-Click ordering makes it oh-so-easy to get the latest intriguing tome. Compounding that, a lot of publishers send me free computer books hoping to get a review. Some I save; some get passed along to friends, and too often I seem to acquire multiple copies.

There’s a stack of technical books here that I no longer need. It seems sort of unethical to eBay those that were sent as freebies, and I can’t remember which were free and which weren’t. So, you can have ‘em. They’re all free and I’ll pay for shipping. If you want one, please send marybeth@ganssle.com an email. She’ll probably get inundated, so here are a few rules to throttle the packets:
- First come, first serve
- Please include a shipping address (no PO Boxes)
- One book per person – let Marybeth know which one you’d like.
- I ask you to write a review of the book after you read it, so others can benefit. It’ll run in the Muse, and with the other book reviews on ganssle.com, with appropriate credit to the reviewer.
- Please don’t feel offended if we’ve run out!

Though the books are in good condition, some have annotations I made while reading them. Here’s the list:

Analog Interfacing to Embedded Microprocessors, Stuart R. Ball, Newnes, 2001

The Definitive Guide to How Computers Do Math, Clive Max Maxfield, Alvin Brown, Wiley, 2005 (A really good intro)

CMMI Survival Guide, Suzanne Garcia, Richard Turner, Addison Wesley, 2007

The Art and Science of Analog Circuit Design, Jim Williams, Butterworth-Heinemann, 1995 (Excellent and fun)

Practical Development Environments, Matthew B. Doar, O'Reilly, 2005

Foundations of Analog and Digital Electronic Circuits, Anant Agarwal, Jeffrey H. Lang, Morgan Kaufman, 2005

Programming Embedded Systems in C and C++, Michael Barr, O'Reilly, 1999 (This is the original work; there’s a new edition that recently became available that I’m keeping).

Embedded Systems Firmware Demystified, Ed Sutter, CMP Books, 2002

My Job Went to India (And All I Got Was This Book), Chad Fowler, Pragmatic Bookshelf, 2005

The Microprocessor - A Biography, Michael S. Malone,Springer-Verlag,1995 (A nice history)

The Blue Book of Grammar and Punctuation, Jane Straus, 2004 (Not computers, but useful for perfecting one’s English for commenting and writing)

The DSP Handbook - Algorithms, Applications and Design Techniques, Andrew Bateman, Iain Patterson-Stephens, Prentice Hall, 2002

The Human Factor, Kim Vicente, Routledge, 2004 (A good book on human engineering of all sorts of systems)

Debugging the Development Process, Steve Maguire, Microsoft Press, 1994

Design for the Real World, Victor Papanek, Academy Chicago Publishers, 1984

Tools & Tips:

Jonathan Harston wrote: “Talking about development tools, and PCB layout in particular, I use Paint Shop Pro. No, really!

“I put a grid lock on at 15 pixels, which becomes my 1/20" layout grid. Printing at 300dpi gives a tracking image. I email the layout as a JPEG to a PCB fabricator, they add on a tenner to convert it to their format and send me a little parcel of PCBs a few days later. I wouldn't recommend this method for anything big, but for small jobs it's a breeze.

“http://mdfs.net/Info/Comp/BBC/IDE/8bit took about five hours to design from paper to final artwork, with only one error which was fixed at the assembly stage by changing the assembly instructions.”

Marc Verwerft sent this link to ctrace: http://ctrace.sourceforge.net/
From their website: “CTrace is a fast, lightweight trace/debug C library. It was specifically written for use in a multi-threaded application, though it will work just fine in a single threaded C application. A trace/debug library has an interface of macros or functions which outputs the contents of program variables as the application is running. The trace calls may be made at user-defined levels. It may also be required to have trace functions only called on a particular thread or logical unit of the application.

“Isn't that what debuggers are for? Well, yes, though debuggers can be kind of tricky to use when an application is running across multiple threads. Also, once an application is deployed, for example on an embedded system, using debuggers becomes impractical. In this case, a remote protocol could turn tracing on for parts of the application, and the results may be returned either as a stream, or output to a file on the remote system, and collected via ftp.”

Dave Kellog sent in several tips: “For naming directories of tools, I have found a naming convention hierarchy of c:\Tools\Vendor\Product\Version works well. For instance:

“This groups all of my tools under a single top-level directory (for convenient single-point back-up). Under a given product, this allows for multiple versions of that product. The convention also allows for multiple products from the same vendor.

“For naming various working directories or versions of a file, I use the form of YYMMDD-HHMM, where the HHMM (hour and minute) part is in 24-hour time. For example, a file created at 3:20 pm on 15 January 2007 would be named as 070115-1520. The big advantage of this convention is that the natural sorting order of ASCII will order the directories into a correct chronological order. It also makes the time inseparable from the file, whereas a creation timestamp may be changed when a file is copied, etc.

“For dating chronological notes in various files, I simply use the same convention as the date. In this case, there is no particular advantage other then consistency with #2 above, and all dates are the same character length. Often Ill drop the -HHMM suffix, leaving me with a simple 6 character date. Eg, 070115.

“An idea for naming variables is largely based on Steve McConnells excellent book Code Complete. I call it Constricting Syllables. The idea is that each successive syllable in a name is a further refinement on the name up to that point. For example, in an autonomous vehicle I may have a variable named SteerVelocityMax. This is clearly a velocity in the steering system, and is a maximum velocity. One big advantage of this approach is that variable names sort into logically related groupings. This is a help in old fashioned map files, since related names will cluster together. It is also useful in modern IDEs that offer name completion.

“Perhaps other readers would have similar tips that would be useful to share with the community. I, for one, would like to learn from others experience.”

Note that Dave’s naming convention is one I learned in one of Jean Labrosse’s ESC classes: name from the big to the small, from the galaxy to the town, like: GalaxySolarsystemPlanetContinentCountryCity. So a name like Timer_0_read() is superior to Read_timer_0(). If one sorts the symbol map, the former groups all timer_0 related things together.

Also avoid acronyms and abbreviations in names. Does “disp” mean the verb “to display”, or is it the display hardware? Exceptions to the rule are industry-standard conventions, like LCD or LED, and any abbreviation or acronym that has been defined in a dictionary in a header file. Clarity uber alles.


Joke for the Week

From Catherine French:

Kauffman's Paradox of the Corporation –
The less important you are to the corporation, the more your tardiness or absence is noticed.

The Salary Axiom -
The pay raise is just large enough to increase your taxes and just small enough to have no effect on your take-home pay.

Weiner's Law of Libraries -
There are no answers, only cross-references.

Kenny's Law of Auto Repair -
The part requiring the most consistent repair or replacement will be housed in the most inaccessible location.

Second Law of Business Meetings -
If there are two possible ways to spell a person's name, you will pick the wrong one.
-Corollary - If there is only one way to spell a name, you will spell it wrong anyway.

Lampner's Law of Employment -
When leaving work late, you will go unnoticed. When you leave work early, you will meet the boss in the parking lot.

Quile's Consultation Law -
The job that pays the most will be offered when there is no time to deliver the services.

Van Gogh's Law -
Whatever plan one makes, there is a hidden difficulty somewhere.

Troutman's Fifth Programming Postulate -
If the input editor has been designed to reject all bad input, an ingenious idiot will discover a method to get bad data past it.

Lerman's Law of Technology -
Any technical problem can be overcome given enough time and money. - Corollary - You are never given enough time or money.

Lovka's Advice -
Never rely on a person who uses "party" as a verb.