Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
Logo The Embedded Muse
Issue Number 241, May 6, 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

Analog Devices has a free analog university, which looks quite worthwhile. There's more info here.

Quotes and Thoughts

"Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday's code." - Christopher Thompson

Tools and Tips

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

None this week.

What I'm Reading

Is Programming Knowledge Related to Age? - A paper to be presented at the Working Conference on Mining Software Repositories later in May. I'll have a more detailed analysis of it on later this week. Turns out older engineers are better developers.

Inexact Design - Beyond Fault Tolerance. (Communications of the ACM, April 2013). Huge power savings can be had by tolerating some errors. Consider video - a single pixel error may not be a big deal. Or the statement "if (a>b)" - computers very precisely compare those two values, but in many cases the same result can be had by comparing just a few bits.

EDN, T&M World and Design East News

UBM, the publishing giant behind, EDN, EETimes and other sites and magazines, sent out a broadcast email recently announcing big changes. Actually, the email was mostly marketing doublespeak, but a friend in the company translated it for me. The bottom line: EDN as a print publication will be gone after the June issue. Like Embedded Systems Design magazine it will now exist only in an on-line version. Test & Measurement World online (T& will cease to exist; it will redirect to EDN's on-line site., and will migrate to a new format currently used by some of UBM's other properties; one that I find very visually busy and one that is far more into social interaction than providing good engineering information.

And Design East, the show formerly known as the Embedded Systems Conference Boston, will not be held this year.

The Internet has totally reshaped publishing, so it's no surprise more and more print magazines are disappearing. I'll sure miss EDN. It had slimmed down to a shadow of its former self, but continued to print great content.

Actually, I can't stand the word "content," which conflates information, knowledge, great articles, marketing BS, inane ads, and unmoderated, sometimes unintelligible, and at times angry rants into a ball of webized pages designed solely to attract Google clicks.

Back in the 1960s as a teenager I did some truth management on a form and managed to get a free subscription to EDN. A lot of the articles were over my head, but for most of five decades EDN has been my place to go to see what new cool stuff is going on in this amazing field. Old-timers fondly remember other publications of the day like Electronics and Computer Design. But they are all long gone.

Wikipedia claims EDN started in 1956; it sure would be interesting to see some of those early issues, which no doubt excitedly discussed the new technology of the transistor. Vacuum tubes were probably still featured in circuits.

I'm not privy to the reasons for canceling Design East, but am sure they are grounded in good business sense. It will surely be missed. The loss of all of those speaking slots means more competition for time at the West Coast show, which will presumably lead to even higher quality presentations there.

Engineering Curricula

Scott Whitney wrote a letter to a friend who was wondering about courses and training to provide more software focus to his experience as a hardware developer:

* A modern, block-structured programming language: I would pick C, since it's still the most common for embedded, but you could learn the principles using Pascal, Modula-2, or other languages. Most tool chains use some flavor of gcc, and if you want to start working with gcc on your PC, you could use mingw or cygwin to get started. My favorite C reference book is by Harbison and Steele. There are also some great little starter kits for embedded targets, including TI's LaunchPad for the MSP430 and several platforms for PIC and Atmel processors.

* A modern assembly language: Since ARM owns 60+ percent of the embedded world, I would learn a bit of embedded assembler using one of the ARM processors, e.g. something simple like an ARM Cortex-M0. Several companies have cheap exploration kits for these cores, and most manufacturers are making silicon with tons of peripherals around this 16/32-bit core. A good book and development module is here. In truth, you will seldom have to resort to assembler, but it's important to have an understanding of how the processor actually works in some cases.

* Data structures and algorithms: I have yet to take on a project where I have not needed some structures and algorithms like linked lists, queues, sorting, stacks, tree searches, etc. A basic understanding of how to implement these is a must-have, although in modern languages such as C++ you may get them for "free" through the STL or 3rd party libraries.

* Operating systems concepts: Everything from simple "supervisory loops" to timer-driven state machines, to real-time operating systems to full-blown operating systems like Linux, Windows, and the Cloud. Especially "real-time" or deadline-critical operating systems, which must execute threads or tasks within a certain time, or the system may fail. Common/free examples these days might include FreeRTOS, although I would also buy the book and get the academic source to Jean Labrosse's uC/OS-II and/or uC/OS-III and read them thoroughly. They are a great explanation of how an RTOS can be implemented, and he's an excellent author. The big difference between II and III is that III adds the use of a memory management unit, where you can protect tasks from stomping on each other. You can find the books here. For FreeRTOS, you could try this.

* No course on RTOS is going to be complete without a discussion of how you hook up devices to the RTOS, e.g. with device drivers. Unfortunately, most of the info on this will be inside one of the RTOS books, or else will be a book specific to Linux or Windows device drivers. If I come across some better examples, I will pass them along. The CMSIS library that is provided by ARM vendors often has good examples that can be the start of device drivers, but marrying them to an RTOS can be tricky. This is where a thorough understanding of the facilities that your RTOS provides, such as tasks, ISRs, semaphores, queues, etc. can be extremely helpful. The POSIX model uses some standard APIs for controlling device drivers: creat(), open(), close(), read(), write(), ioctl(), poll(), select()...

* Object Oriented Analysis/Design - How to break down and design a system using object-oriented and other methods. The standard notation for this is the Unified Modeling Language, but I confess that use about 1% of what it's capable of. I would like to learn how to use this better myself. Other requirements and design techniques can also be used for breaking down WHAT has to be done (requirements), and how you're going to do it (DESIGN).

* A modern object oriented language: For this, I would recommend C++, as it is the most common one you will find if you are able to use such language on an embedded processor. I'm using an NXP LPC1850 with the IAR Embedded Workbench tools, and we can actually support full C++ including templates, function overloading, multiple inheritance, exceptions, etc. It's rare to have such a luxury on embedded systems, which are often very constrained. For reference books, I really like the free ones from Bruce Eckel, called "Thinking in C++". They are available for download here.

* Dan Saks offers a killer course in Embedded C++ that I would love to attend.

* You have already been exposed to much of this, but a course dealing with Software Project Management would help, which will go over all of the life cycle models and typical steps that a software project goes through from napkin concept to retirement. A good standard for medical is IEC 62304. Basic models include things like project stages, development models (linear/waterfall, spiral, evolutionary, agile), implementation, testing, deployment. I think that incremental, evolutionary, and agile are the ones you will l most likely encounter today.

* For development environments, I would try to learn something based on Eclipse, which has become a free and de facto standard for IDEs. You can even get C/C++ GNU toolkits that plug into Eclipse so you have an editor, debugger, and compiler to learn the basic languages you'll need, and then many vendors have specialized plug-ins for their own debuggers, processor-specific register views, and compilers. Even some RTOS visibility tools are available.

* There are lots of "glue" tools that you will probably encounter, including "make", some type of version control (CVS, SVN, git, mercurial), scripting languages (perl, Python, others), but these will come with time and need.

* Something in embedded/real-time math (fast, usually limited precision, often with software floating point or scaled fixed point math may be helpful.) Jack Crenshaw has a great book on "Real-Time Math Toolkit", and if you need to do some serious math, "Numerical Recipes in C" is great.

What do you think?

Bob Scaccia has written about this subject here.

New Cortex M3 Book

Sergio Caprile was kind enough to review a new book about ARM Cortex M3 MCUs. The book is in Spanish, as is his review:

Desarrollo con microcontroladores ARM Cortex-M3 microcontroladores <<= 2

La documentación de ARM es extensa y completa, tan completa que para
entender las diferencias entre el Cortex-M0 y el Cortex-M0+ hay que leer
tres manuales de referencia y correr un diff mental.

Este libro está concebido como una guía para el desarrollador que desea
pasar de 8- a 32-bits. El primer capítulo introduce conceptos esenciales
para poder entender las arquitecturas de 32-bits y evaluar este tipo de
micros en general; mientras que el segundo capítulo abarca todo lo que
puede de todas las arquitecturas ARM de 32-bits al momento, con la
profundidad suficiente como para no ahogar, pero tampoco mojando sólo
los tobillos. La decisión de dónde poner el límite es mérito del foco
decidido para la obra, dado que cada arquitectura podría extenderse por
sí misma hasta ocupar el libro por completo.

Dicho foco está, como se desprende sutilmente del título, en Cortex-M3,
por lo que se lo describe primero. A continuación, todos los demás
procesadores del perfil M se describen en función de éste. El esquema de
descripción para los cuatro procesadores se mantiene uniforme y
minimalista, así como todo lo presentado en el resto del libro, por lo
que si comparamos la cantidad de información por unidad de volumen con
respecto a toda la bibliografía de ARM, el capítulo 2 sea tal vez
considerado un agujero negro.

Pero la información por sí sola es inerte, necesita de la práctica para
volverse conocimiento. Es así que los capítulos siguientes analizan las
herramientas de desarrollo en un ambiente independiente de cualquier
fabricante en particular, siguiendo luego con el análisis de las
prácticas más comunes en C y sus efectos en un procesador de 32-bits,
para finalizar con análisis de cuatro familias de microcontroladores de
distintos fabricantes, con ejemplos prácticos.

Sintetizando, este libro será una herramienta para ayudarnos en la
búsqueda del conocimiento, para a su vez dominar otra herramienta: los
microcontroladores ARM de 32-bits.

More on Aging Software

Don Herres responded to my comments on aging software:

In response to your question, the main problem with maintenance is that it usually is not "maintaining" but enhancing.  The application is being extended by adding features that were never planned and then trying to shoehorn them into the same code and micro that was originally used.  Most suppliers have an upgrade path for a micro that allows an almost "easy" transition when a micro becomes obsolete.

Of course, the problem with feature creep during the original product development is that at some point, you make the product work late in the schedule and nobody can remember all the little tricks done late at night to make the code work just right.  I try to comment extensively since I can not remember what I did two months later, let alone anyone else.  This makes maintenance something tossed over the partition to the new guy.

One reader who wishes to remain anonymous wrote:

A company hires a freelance engineer, and asks him to support a few software packages, making the host side of some embedded devices. The devices are sold, updated and supported for twenty years, so are the software packages. And that doesn't mean all that software is working flawlessly, neither that it's been debugged at it's best.

This engineer finds himself juggling with multiple modules, each nearly 30 kLOC large, where one quarter of the code is under #ifdef (to support multiple architectures, or even to be always excluded from compilation!), multiple global variables are nested in structures (often duplicated because too large to be remembered), and 4-5 developers over time have added different coding styles (but almost no comments).

Talking to the company's senior engineer, our intrepid hero proposes to start pruning and cleaning the code base, since maintenance is a big burden. The answer is always "no, we can't risk to change what's working now". So, the freelancer keeps being paid day by day, keeping together a software that risks to explode every time a new features is added (or any old bug is fixed).

Another funny part, is that the same freelancer contributed, more than 20 years before, to the growth of that same company. As he left to follow new projects, the heirs of software base kept intact most of the two decades old software (that again couldn't stay the same for so long), while some newcomers were coding ("bugging") without any clear guideline the new products.

Shouldn't be this the case for stop prolonging a product's agony and restart from a tabula rasa?


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

It's really not too difficult to fix your own hard drive if the problem is a head crash, or the infamous "stiction" problem. You will require #4/0 steel wool, Varsol, WD-40, a few hand tools, and about 45 minutes.

First, you need a clean room, so make sure the garage door is closed before you begin. Move those old lawnmower parts off the bench.

Disassemble the sealed unit and carefully wash all parts with Varsol. Bend the read/write heads out of the way and then disassemble the platter stack.

VERY CAREFULLY buff the platter surfaces with the #4/0 steel wool. This will remove any existing data, level out any surface defects, and help to redistribute the magnetic media and fill in those pesky "bad sectors" that most drives have.

Reassemble the platter stack, and using a .015" feeler gauge, bend the read/write head back to the platter surface, using the feeler gauge to set the gap. This is a slightly higher gap than the factory uses, but it reduces the chance of head collisions with any flotsam you neglected to remove.

Give the head and platters a good shot of WD-40 and reassemble the unit. If your drive has a filter, replace it with a clean section of gauze pad.

All that's left is to low level and DOS format the drive, and you're back in business.

I haven't tried this yet myself, but my friend's wife's sister-in-law's husband knows a technician who does it all the time.

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.