Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
logo The Embedded Muse
Issue Number 234, January 21, 2013
Copyright 2013 The Ganssle Group

Editor: Jack Ganssle,
Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for noncommercial purposes. For commercial use contact To subscribe or unsubscribe go to or drop Jack an email.

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

If you're a fan of the history of this field, here's a nice site with a collection of info about old microprocessors.

Quotes and Thoughts

A programming language is low level when its programs require attention to the irrelevant. - Alan J. Perlis

Tools and Tips

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

There's been a ton of feedback about ways to preserve random bits of information. Carl Peterson wrote:


In regard to Dave Kellogg's comment of using a MS Word document to keep track of interesting factoids, since he uses the Windows environment (I use both Windows & OSX at home), Windows 2007 and 2010 seem to have OneNote provided. You can highlight anything on a website (IE of course) or any Microsoft product tool, right click and "Send it to OneNote". A pop-up will appear and ask what section you want to place it in. As you can see below it will take pictures, links, text etc.

Another tool I use is Snagit (company provided - not sure what it costs) to cut/paste anything on my screen into Microsoft products (Word. PowerPoint are my main targets - it might do more). It's what I used to capture the "picture" below. It's also available for OSX as I see from their website.

One Note

Olav Haugan sent this:


Regarding tool for easily searchable personal knowledge-base I think that TiddlyWiki [ ,] is a very useful tool in this regard. It is a single self-contained HTML file that acts as your own personal wiki. It is portable since it's a single file and can easily be stored in the "cloud" to synchronize access between computers. It is highly customizable with plugin support and customizable style sheets.

And Jeff Barth submitted:


It sounds like Evernote ( would do what Dave wants to do with much less overhead. It's easy to store web links, or entire web pages, or selections. Plus make text notes, audio notes, drag pictures into notes, add tables, etc. And it syncs across all major OS's and smart phones.

David Fernandez Pinas's approach is:


Since 2001, I have been using a plain text file formatted in simple HTML to keep my bookmarks organized. HTML allows you to insert graphics, tables, text, links as needed and quickly from any simple text editor.

The links are grouped by sections. I keep an index list of topics in the webpage. Moreover, I put some keywords and descriptions next to the links, so it is easy to make a simple text search and find the links again by keyword or subject.

I used to have this webpage online, but now I just keep it in a pendrive I always carry with me, for multiple purposes, that I regularly backup.

Jeanne Petrangelo wrote:


In issue 233, Dave Kellog explained how he uses Word documents to keep various bits of information and that he's unhappy with that approach. What he's looking for is called a Personal Information Manager or PIM. I use a paid-for PIM called RightNote. It's normally at but the website is under maintenance as I type this. In 2010 I paid $35.40. RightNote stores the information on my PC. It has all the features Dave mentioned (tabs, tree hierarchy, spreadsheets, rich formatting, links, images etc). I keep links, meeting notes, to-do lists, "maybe someday" ideas, and more in RightNote. I even have a password protected tab where I keep access details for the various password protected things at work, so I only have to remember one password. Content can be exported to various formats. It has built-in search capability.

Another popular PIM is Evernote (, which also has apps for mobile devices; data is stored in the cloud so you can access the same data from different platforms. Evernote has a free version and a subscription version with more features. I'm unable to access Evernote from work due to company network security restrictions, but I use it on my smart phone for non-work information. I assume the PC version of Evernote can do what RightNote can do, with some differences. For example, while RightNote has its own spreadsheet functionality, I've read that Evernote lets you attach an Excel spreadsheet so it's stored in the cloud but it uses your locally installed Excel to open it.

Mike Skrtic channels Windows 3.11:


Dave Kellogg's thoughts of regarding the cloud of Word documents reminded me of my solution. I use a little program called axxCardfile which I have found extremely useful. It is a reinterpretation of the Win 3.11 program - on steroids!

Basically I have a deck for each general topic , and then I can paste virtually any sort if info in almost any format into a card.

Since every "card" is blank, and there are no pre-defined fields, virtually anyone can use azzCardfile as a sort of database. With azzCardfile, everything is wide open. Sure, it's not a database in the true sense of the word, but it's close enough.

As far as features go, I really can't go into every one of them. There are a ton of features that I've never used. Features that I have used include:

  • Format text as you would in any normal word processor, including bold, italics, changing text and background color, text size, etc.

  • Create hyperlinks pointing to web pages. Ctrl+click on hyperlinks to open that page in your preferred web browser.

  • All pages are searchable. Search within a card, or search all cards for a specific word or phrase.

  • All cards are printable. You can even Ctrl+click multiple cards to print them out into a single document (this is how I create my road trip lists).

  • Export cards (or multiple cards) to RTF, HTML, or a few other formats.

Here are the screen shots: I was going to send one of my decks, but I couldn't find screenshot that didn't contain confidential info of some sort.

Tony Garland likes Trunknotes and Vimwiki:


Dave Kellogg had some thoughts about Royce Muchmore's point about keeping Internet Links (favorites) somewhere "in the cloud": Generalizing Royce's problem statement somewhat, I've tried various mechanisms to store various tidbits and points of information. "

Thought it might be worth mentioning another set of tools that I use to keep track of various tidbits of information: trunknotes for iPad/iPod/iPhone ( together with vimwiki ( Trunknotes is a wiki-like note taking and organizing application which brings the power of wiki to the iPad/iPod/iPhone in a stand alone way. This means that you can easily refer to, enter and edit your notes in an easy-to-use reliable wiki running on the device you almost always have with you. What's especially great about trunknotes in the day-to-day engineering battle is it has a "Wi-Fi Sharing" feature which, when enabled, allows you to access trunknotes from within any browser on another machine on the local wireless network. What this means is that you can keep a browser window open on your main development machine (using a URL which trunknotes provides) which gives you full access to trunknotes as if it were running on your local machine-although it is still on your portable device. The web interface is fully capable of creating, deleting, editing, and searching-just like on the actual device. Except you have the efficiency of your large PC display and full keyboard. Then, whenever you run off somewhere, you grab your portable device and it has everything on it. Another nice feature is Dropbox synchronization. I use this to make sure my notes are backed up on the PC (locally) and as an interface with the other half of my equation: vimwiki. Vimwiki can be configured to work pretty well with trunknotes files (including the file extension and most of the wiki markup syntax). This gives me the best of both worlds: I can use trunknotes stand-alone (even from my PC) or I can use vim (or gvim) with vimwiki. This means I can do all my trunknotes editing using powerful vim features and vimwiki allows global wiki page renames and other great features including super flexible and powerful search (although trunknotes does well in that department).


After my review of the Analog Discovery USB scope, Brent Knecht sent in this warning:


It seems there has been an explosion of USB based test equipment, but there is one big pitfall. A colleague of mine turned his workstation into a doorstop when he accidentally touched the common probe of his USB `scope to a hefty +24VDC supply. The supply's negative output was connected to the AC safety ground, which referenced it back to the computer. Now we only use such devices with a USB isolator to prevent this kind of carnage.

I recently purchased an automotive OBDII-USB interface for working on my vehicles. The manufacturer's website warns against powering the laptop from a non-isolated 12V-120V inverter connected to the vehicle for the same reasons. Their website has photos of melted USB connectors on customers' laptops.


Quantum Leaps

What I'm Reading

An astonishing number of SCADA systems are vulnerable.

Are there only four companies capable of making the most advanced chips?

Free book on analog design.


Best C Book?

Greg Feneis wrote wondering what is the best C reference? He likes Teach Yourself C, Second Edition by Herbert Schildt (1994) and wonders about C11 books.

My go-to references are the C99 standard itself, and K&R's The C Programming Language, Second Edition. What are your favorites?

The embedded compiler vendors I've spoken to say that they don't plan to support the new C standard for at least a couple of years.

The Seven Habits of Highly Dysfunctional Developers

Here are a few ways of maximizing your job security through proper dysfunctional design and management of your next embedded project.


Make promises you know you can't keep. This cardinal rule is most effective when applied to scheduling. It's notoriously difficult to create a schedule that is accurate, so don't worry, be happy, wing it.

One perfect indicator of an impossible schedule is that sick feeling one gets in the gut when moving Pert chart triangles around in an effort to meet marketing's arbitrary deadline.

When you find yourself fudging data to meet expectations you know you're on track to mastering the art of overpromising. When you whisper lots of "maybes", "I hopes", and "ohmygods"; when miracles are expected and required, then your overpromising skills are truly in the upper percentiles of the dysfunctional.

The most dysfunctional development groups have perfected this to a fine art, at times even bursting into loud guffaws when management requests a schedule or a progress update.

Never limit your overpromising practice to schedules! Embedded systems are singularly subject to the merits of overpromising on system performance. Always promise that a 1 MHz 8051 will suffice. Always promise data transfer rates that press the state of the art.

Defer Hardware Issues

Sometimes the most frustrating part of getting your code to work is making it interface to the system's hardware. There's no sense in getting upset at the beginning of a project when you know that the end will be a disaster anyway, so always defer dealing with hardware requirements until you've written many thousands of lines of hardware-dependent code.

Though modern C compilers are quite efficient even at handling low level tasks like talking to the hardware, proper convoluted design requires writing all drivers in assembly language. Minimize documentation and maximize obfuscation to enhance your job security.

The hardware engineers will surely be happy to respin the board design as often as required, especially if the changes are requested within a week of final delivery.

When it's time to assign blame, remember that modern FPGA design means the hardware is now just like the software - it's never done.

Ignore Real Time

Never address real time issues until the night before delivery. Deferring performance problems, in particular, will assist in following the previous rule (Defer Hardware Issues), particularly if your code is so slow you'll have to replace the 8051 main CPU with a quad core Pentium-class machine.

Some of the most successful dysfunctional developers have managed to create systems without an RTOS, and then convince their bosses to shoehorn the RTOS in only at the last minute.

Be sure to convince your boss that no commercial RTOS is quite right for your application. Writing your own will fill many a lonely evening. Customers will delight in finding the subtle bugs sure to be left behind in the final executable.

Since an application that is properly segmented into multiple tasks differs so much from the standard stream of consciousness approach, shoehorning an RTOS into your system late in the game will potentially add years to the project and to your job security.

Glorify Globals

Use lots of global variables. Every module should be dependent on variables from every other module.

Make use of today's powerful tools which impose no penalty for the use of huge include files. Define every variable within the include file, so you won't have to worry about remembering which one is used where.

It doesn't hurt to use cryptic naming conventions as well, to obfuscate the origin and influence of each global. Since the monster include will define variables with the most limited scope, yea even unto loop counters, remember that standard practice calls for expanding the old FORTRAN practice of naming temps. Use the names "i", "ii", and (my personal favorite) "iii", just appending "i"s as needed to create unique labels.

Ignore the precepts of modern object oriented software design, which requires that variables be encapsulated within the functions that use them. Anyone who has done a complete OOP embedded project realizes just how much thought and planning is required to do so correctly.

Take the easy approach now, since you know you'll be debugging forever anyway. Remember that "maintenance" is nothing more than an abstract concept touted by overpaid programming gurus, since most software never makes it to the field anyway.

A frequently overlooked benefit of globals is their profound influence on your personal job security. Creating alarming numbers of dependencies in your code surely leads to the company being forever dependent on your skills.

Discourage Understanding

Software is complex. Few of us will ever understand a chunk of code over 50k lines. Bear in mind that software consultants tell us we should keep functions under a page as that's all the average programmer can comprehend.

Since the history of the industry shows us that most software folks just start writing the code before bothering with a detailed design, it's clear that functions will always exceed a page. Sometimes the length of a single function may rival War and Peace. Given this fact, it seems unlikely that we'll ever understand the code anyway, so just go ahead and crank out C. As fast as possible.

Besides, since the firmware will surely take longer than expected to complete, it's best to get started immediately.

Most embedded systems run into trouble during debugging. One common problem includes synchronizing with external hardware. The wise practitioner will include a delay routine, whose input parameter is a delay time in arbitrary units. Sprinkle calls to the delay liberally into all hardware-centric activities. Tune the delay parameter until the unit works (working is the only measure of success).

UNIX programmers are intimately familiar with the concept of a "magic number". We should extend it to all aspects of embedded code. A particularly appropriate place for magic numbers is in the programming of complex peripheral chips. Be sure, though, to add comments as required. For example:

outp(0x3ab2, 0x33); /* program port */
outp(0x44ff, 0x87); /* set other port */
outp(0x9fde, 0x01); /* this seems to make it work??!! */

Modern debugging tools promote our lack of understanding of deep problems. Once, when an edit-compile-debug cycle took hours, programmers were careful to be sure they had considered all possibilities before fixing a bug. This is no longer required. As soon as a problem surfaces, change something - anything - and recompile. It'll take but a few seconds, and with luck the change just might have the desired effect.

Tuning the code with magic numbers and poorly thought out bug fixes enhances your career prospects. Quit and become a consultant to your old company, and enjoy many years of bountiful income from additional tuning and hacking.

Neglect Standards

A quick glance through the literature shows hundreds of ideas for improving software productivity. Code inspections, methodologies, design reviews, and the like are the darlings of the gurus.

But all are boring. All take time away from the thrill of coding, the excitement of debugging, and the roller-coaster-like terror of watching deadlines flash by.

The Software Engineering Institute defines the Capability Maturity Model (CMM), which gives five levels of software maturity, as follows:

5. Optimizing - Characterized by Continuous Improvement. The organization has quantitative feedback systems in place to identify process weaknesses and strengthen them pro-actively. Project teams analyze defects to determine their causes; software processes are evaluated and updated to prevent known types of defects from recurring.

4. Managed - Predictable. Detailed software process and product quality metrics establish the quantitative evaluation foundation. Meaningful variations in process performance can be distinguished from random noise, and trends in process and product qualities can be predicted.

3. Defined - Standard and Consistent. Processes for management and engineering are documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing software.

2. Repeatable- Intuitive. Basic project management processes are established to track cost, schedule, and functionality. Planning and managing new products is based on experience with similar projects.

1. Initial - Ad hoc and Chaotic. Few processes are defined, and success depends more on individual heroic efforts than on following a process and using a synergistic team effort.

Clearly, though, level 1 is far too high of a standard for the most defective development projects. Fortunately Captain Tom Schorsch of the U.S. Air Force realized that the CMM is just a subset of the true universe of development models. He discovered the CIMM - Capability Immaturity Model - which adds four levels from 0 to -3:

0. Negligent - Indifference. Failure to allow successful development process to succeed. All problems are perceived to be technical problems. Managerial and quality assurance activities are deemed to be overhead and superfluous to the task of software development process.

-1. Obstructive - Counter Productive. Counterproductive processes are imposed. Processes are rigidly defined and adherence to the form is stressed. Ritualistic ceremonies abound. Collective management precludes assigning responsibility.

-2. Contemptuous - Arrogance. Disregard for good software engineering institutionalized. Complete schism between software development activities and software process improvement activities. Complete lack of a training program.

-3. Undermining - Sabotage. Total neglect of own charter, conscious discrediting of peer organizations software process improvement efforts. Rewarding failure and poor performance.

Strive for level -3 compliance to maximize project duration and thus your own job security.

Abandon Discipline

Abandon all discipline when the end of the project draws near.

If, perhaps though mistaken non-observance of the preceding rules, you happen to have employed software standards, or code reviews, or a scientific design methodology, be sure that as soon as the boss cranks up the pressure you drop all pretense of careful engineering. Just crank that code!

After all, we know that pilots, when late in pushing back from the gate, always decide to skip the take-off check list.


Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intents of this newsletter. Please keep it to 100 words.

Joke For The Week

Note: These jokes are archived at

Jon Titus sent the following:

A wife asks her engineer husband, "Could you please go shopping for me and buy one carton of milk? And if they have eggs, get six."

A short time later the husband comes back with 6 cartons of milk and no eggs.  The wife asks him, "Why did you buy six cartons of milk?!"

He replied, "They had eggs."

Advertise With Us

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at

About The Embedded Muse

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

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at for more information.