Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
Logo The Embedded Muse
Issue Number 237, March 4, 2013
Copyright 2013 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com
Jack Ganssle, Editor of The Embedded Muse

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

Contents
Editor's Notes

The average embedded software project devotes 50% of the schedule to debugging the code. It's stunning to realize that half of the project's time is wasted fixing mistakes.

Perhaps the other half should be called "bugging."

Unfortunately that debugging just doesn't work. Most organizations ship with about ten bugs per KLOC, two orders of magnitude worse than best-in-class outfits. A focus on fixing bugs will not lead to a quality product.

How do you get projects done faster? Improve quality! Reduce bugs. This is the central observation of the quality movement. The result is a win-win-win: faster schedules, lower costs and higher quality. Firmware engineering, too, can - and must - profit from the same win-win-win.

Learn how (and far more) at my Better Firmware Faster class, presented at your facility. See http://www.ganssle.com/onsite.htm.

Quotes and Thoughts

Perl -- the only language that looks the same before and after RSA encryption. - Keith Bostic

Tools and Tips

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

Tim McDonough sent this tip:

A nice free service to send reminders, etc. is NudgeMail.

Notepad++ sure is popular. Vishwanatha M S added this:

More about Notepad++: there is a plug-in "SourceCookifier". You can get the outline view of a C/C++ file with this (similar to what we see in an IDE).

There are also a whole lot of other plug-ins that really increase the productivity and make Notepad++ usage a lot of fun.

He also likes GIT:


I was going through the Tools' list and found that there is no mention of GIT version control system. I have used ClearCase over the last 9+ years and switched to SVN about 2 years ago. One thing that I found missing in these two systems is local version management (ClearCase offers this to certain extent). After I started using GIT, this missing part was filled up. Apart from this, GIT offers incredibly fast system (because it is managed locally), a nice UI and complete freedom to do your own changes without affecting others. Another major advantage if GIT is its network independence. You can keep continuing with your work even when you are offline (while in SVN, it is not possible to commit when I am offline). Setting up a repository is pretty easy. There are lots of resources out in the web about GIT and the difference between GIT and other systems. I found this http://ftp.newartisans.com/pub/git.from.bottom.up.pdf a good way to understand GIT. GitExtensions is a UI tool similar to TortoiseSVN (there is also TortoiseGit, but I found it not user friendly).

Colin Walls wrote to correct a misconception about Evernote:

I was a little concerned about an inaccuracy in one of your readers contributions [which suggested Evernote needs an Internet connection].

This is incorrect. Evernote synchronizes between the local device and the cloud. Only on mobile devices, the synchronization can be set to be "on demand" to reduce storage use.

Evernote is actually an amazing tool/service for managing random data, particularly if you are very mobile. If you'd like me to write a short piece introducing the tool, I would be more than happy to oblige.

I have no business interest in or connection to Evernote Corporation. I am just an enthusiastic user of their products.


Quantum Leaps

What I'm Reading

Software on Mars - the story of the code that drives the rovers.

Power Challenges May End the Multicore Era - A scary analysis of a possible near-term future. Communications of the ACM, February 2013 pg 93-102.

The Multicore Programming Practices Guide - you have to register, but it's free.

More on Specialization

In Muse 236 I wrote about the tradeoffs between being a generalist and a specialist. Readers had a lot to say!

Rob Fries wrote:

Most embedded engineers work for a place that's small (read as, has only 1-3 engineers). No one to split up the work with.

On some occasions I've had folks working for me that wanted to specialize, because they only wanted to do the `fun' work, whatever that was for them personally. The problem is, if they didn't do the other tasks, they didn't learn from the mistakes they made while only doing the "fun" work. Feedback provided was forgotten quickly because they didn't experience the pain of the mistake. The best engineers *can* do it all, and usually still *have* to do it all even after many years, but their key skill becomes a recognized asset for the group, and others with a different key skill can help them in turn.

David Wyland contributed this:

Specialization is good for the silicon economy, if you consider specialists as elements that can be assembled into teams to make new products and processes. A wider selection of more powerful elements means more options for assembling a multi-element design. But there is an assumed requirement: a lead designer that creates and coordinates the overall design of the product and how the various specialists fit into the picture. Using the Principle of Leaky Abstractions, the lead designer has to understand at least one or more levels of abstraction down from the top level design in order to debug the problems between the design and its assumed requirements, let alone just debugging the design to make it work. Without this knowledgeable leadership, mediocre design results in the best case, and disaster in the worst. Somebody has to lead. The old chestnut of a camel being a horse designed by a committee applies.

Frequent correspondent Luca Matteini added this:

I really share your feeling on having a whole project in my hands, from the analysis through development, production support, and tech support. I really love to see things from their conception to practical use, feels
like my work is really "complete", in some sense. Maybe is a Da Vinci syndrome, feeling to master every art and science -- and Da Vinci birthplace is even a few tens of miles from here! But the world has changed from the Renaissance, the notions in a physics textbook can prove it, even though Da Vinci was anyway a genial engineer
(an 'engenial'?).

At the same time, with the new pace of technology, things have become so much more complex from 1980, when I read my first electronics magazine. I think that anyone that can follow a project from the first ideas, to final realization (with success!) is really a lucky person: as I am when I can do the same. You just have to put some limits to your work, because it needs a tradeoff on total complexity. You have to be conscious that it can't go beyond your limited skills (no matter how you grow).

Many years ago I worked with a guy on some heavy mechanics systems, and he was used to say "it's not that we're unable to do it: just isn't in our convenience". This way he was hiding a practical limit, favoring his
enormous self-esteem. We should always keep well grounded (not just electrically), and from there reach for the best we can.

What I fear more, about specialization, is what I read in your words about the lack of reality, that risks to infect even who works in engineering. So, can be fine being specialized in something, but not loosing the bases. Maybe among the bases I should list even the hunger for knowledge, that should pervade anyone who works on applied science. Otherwise, pasting blocks of precooked code, or blindly connecting to a black box, won't be that different from moving boxes of storage.

Tom Mazowiesky was one of many to quote Robert Heinlein:

"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."

A quote from Lazarus Long, one of Robert Heinlein's in Time Enough For Love.

Fabian Picca wrote:

Regarding your comment on specialization, and while it is true that the industry demands increasingly specialized people, being a generalist is what have kept me on the embedded business for more than 20 years (and counting).

However, I couldn't agree more with your viewpoint and I also think that because of this focus on "saving the company money", it is becoming more difficult for newcomers to get a job unless they are highly specialized.

Anyway, even when extremes are bad, I still think that I prefer to stay at the generalist end of the spectrum.

 

Dealing With Common Code Bases

Bob Lee asked about references for dealing with common code bases. I couldn't think of any; does anyone have some suggestions? He wrote:

I'm trying to find an article(s) or book(s) that explains different ways to structure the source code/projects for a common code base used in multiple products across multiple platforms, etc. but haven't found any. I'd like to see more than one approach and the pros and cons of the different approaches. It needs to address things like:

- Differences in target processors

- Differences in features (e.g. feature specific header/API but different implementation for each product)

- Differences in peripherals (e.g. EEPROM API with specific implementations for different chips supported)

- Differences in tool chains (e.g. IAR for target, VC for PC)

- Others?

Can you recommend any good reading in this area?

Reading Lots of Switches

I always enjoy EDN's Design Ideas column. The latest includes a simple circuit with a ring counter that lets you read ten or more switches using just two I/O pins on a microcontroller (plus an interrupt input). I'd be wary of the circuit in figure 2; it could be glitchy depending on the type of logic used. Lots of other circuits suggest themselves - for instance, using four outputs from an MCU fed into a 74LS154-type demultiplexer to read 16 switches. One might be able to eliminate the diodes since the 74LS154 has negative logic outputs.

Jobs!

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 www.ganssle.com/jokes.htm.

'Tis the dream of each programmer,
Before his life is done,
To write three lines of APL,
And make the damn thing run.

Advertise With Us

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

About The Embedded Muse

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. 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 info@ganssle.com for more information.