Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
logo The Embedded Muse
Issue Number 250, December 2, 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

Quotes and Thoughts

Robert Matthews sent this week's quote:

"...well over half of the time you spend working on a project (on the order of 70 percent) is spent thinking, and no tool, no matter how advanced, can think for you. Consequently, even if a tool did everything except the thinking for you -- if it wrote 100 percent of the code, wrote 100 percent of the documentation, did 100 percent of the testing, burned the CD-ROMs, put them in boxes, and mailed them to your customers -- the best you could hope for would be a 30 percent improvement in productivity. In order to do better than that, you have to change the way you think."
-- Fred Brooks

Tools and Tips

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

Tom Walter sent two suggestions for mobile device apps:

RPN – Droid48  is free. 

Electodroid is a cool free app, btw.  Just handy quick reference stuff


Contest Results

In the last issue I asked "What is the strangest or funniest embedded product you know of?" Quite a few folks responded, and our judges had a hard time selecting the top three winners. They are listed below, and each will receive their own FRDM-KL25Z development board, courtesy of Freescale Semiconductor.

Jon Koenig submitted:

The "annoy-a-tron" from  I left one as a retirement present in the basement of a good friend, near his electronics workbench.  It entertained him for two weeks, before he found it attached to my note of good wishes.  A great design for a frivolous purpose.  An interesting implementation of little events at long random intervals, without the disastrous consequences that happen to our normal devices.

(That sounds like so much fun I've ordered one for family fun during Christmas).

From Howard Speegle:

The best one I ever ran across was back in the 70s, when microprocessors were just hitting the market.  While shopping for blenders at the local discount store, I noticed one of the models had a sign that promised "contains microprocessor".  As a person with a pretty good idea of the odds of a $25 microprocessor being embedded in a $12 blender, I had to find out, so my trusty pocket protector provided the needed calibration screwdriver and I set to work to remove the base plate.

When the base was off, there it sat, proudly bearing the Intel logo. Glued to the sidewall was an undoubtedly non-functional microprocessor, having no electrical connections of any sort, but certainly fulfilling the promise of containing a microprocessor.

David Kramer likes one of his designs:

Funniest embedded application ever…  I designed the "Mount Count" about 5 years ago.  It's an estrus detection system to tell when cows go into heat.  For all of modern technology, the best indicator is when the cow is mounted by the bull. I'm not sure if the bulls are sterilized or not but apparently the ranchers want to know the optimum time to artificially inseminate their cows.
The device consisted of a small low-power microcontroller running off a Li battery.  The board was mounted inside a clear plastic case and the assembly gets glued onto the back of the cow just above her tail.  When an 1,800 lb bull mounts her the housing compresses and closes a small micro-switch.  The processor counts the number of mounts over a certain period of time with a surprisingly complex and proprietary algorithm. When the magic happens an LED blinks to tell the rancher the time is right.

Newer systems nowadays use wireless transmitters.

Thanks to everyone who participated!

More on Certifications

Not surprisingly, the article about certifying software engineers elicited an avalanche of response. Michael Linden sent a link to the ACM Task Force On Licensing Of Software Engineers Working On Safety Critical Software (draft report, July, 2000). The conclusion was that the ACM should not support such licensing.

An interesting quote: "It has been found that it is very difficult to pass the FE examination unless it is taken right before or after graduation from an engineering school." FE is Fundamentals of Engineering, a wide range of subjects which include chemistry, materials science, statics and much more. One wonders about the applicability of these subjects to a professional engineer if the typical PE candidate will forget much of the material in the months after leaving school!

A number of you complained that most (there are exceptions) universities teach CS people programming, but not software engineering. Programming is just one of the many activities we do. I've often thought that coding should wait till junior year. Prior to that students should learn about engineering in general, and software engineering more specifically.

Jon Koenig wrote:

I pursued an EIT and PE right after college, and have maintained it with fees and continuing education. Is it worth it? I think so, for me. My school prepared me well, and the tests were lengthy, but not difficult. Peer review and recommendation also plays a part in the process. I expect many other PE's feel the same way. Most PE's that I have met have been very competent engineers. I have also worked with many very competent engineers without certification. The difference seems to lie with the poor chumps who were promised an engineering education and got a degree, but really did not get their money's worth. They are convinced (by their diploma mill) that they are engineers, but have difficulty with stuff that I learned in freshman year. Unfortunately, I have worked with far too many of them, and they can be dangerous. These folks would not have a chance with the tests, and likely would not get peer recommendations.

So my initial expectations of a PE are higher than the average "engineer", but either has opportunity to earn or lose my respect. Most PEs live up to my expectations.

"Engineer" means different things in different places. In England, it's the guy who wires your house. In the US, it may refer to the guy who drives the train or the bulldozer. In Germany, it is quite limited to someone who is certified and has an advanced college degree. A lot of folks like to argue this point, I really don't care that much.

The proceedings of my state agency included land surveyors, engineers, morticians, barbers, beauticians, and bingo parlors. That is pretty much the inverse order of disciplinary actions. It was interesting to learn about all the screw-ups that happen in the various professions. I learned to cut my own hair.

Charley Moore submitted this:

With all the development now being done in India and China, it would probably just lead to more US engineering unemployment and even more development overseas. And does anyone think that THAT would be safer?

Sergio Caprile had some thoughts from South America:

You know, Argentina may be big in terms of square meters, but is a small country. I'm in charge of R&D at this company (I'm the one and only) and have also been in charge of tech support some years ago, stuff that was handled by a technician. Through the years I've had the honor of getting in touch with excellent professionals, and the sadness of meeting people with absolutely no knowledge of electronics, that questioned the quality of the components this company sales.

My usual response to the internals carrying those people's comments was "tell him to go to one of those houses that have a sign showing "University" in the front, there he'll find what he is looking for". You know, to work as a physician, you need to have credentials from a university certifying you are a doctor. Otherwise, you'll meet a demand for illegal exercising medicine (or something similar, I'm translating legal terms in spanish...). To work as an attorney, same stuff. To work in electronics... well, anyone will do. I'd like to have the legal equivalent of "illegal exercise of engineering" !

There is a certification, it is called university degree. We could start by requiring developers to at least be engineers. As for firmware... well, I don't have credentials to support that, I'm self taught in C, my university program taught me BASIC, Pascal, and I've learned 6800 assembly in high school. Beyond that, my teachers were good enough to provide me with the right tools so I can learn new programming languages and firmware techniques, but that's what we engineers know how to do, that's why we are engineers, isn't it ? Anyway, it is a tough question and our countries and educational systems are quite different, but I'm sure there are lots of stuff that can be done so the engineering degree is enough for a certification as a developer.

Rob Milne had this to say regarding his unconventional entry into this field:

"...and would probably leave the industry if this happened, is it inevitable?"

I too would leave engineering if it came to pass.  In fact I'd have no choice but leave because I'm a member of the set of people that lack an engineering degree.

That said I agree that standards should exist for the development of complex embedded systems.  Accreditation seems to be a logical way to address the situation but unfortunately the legal requirement for a PE is going to eliminate a lot of highly qualified people like myself.
We'll be  relegated to non-critical systems or forced to work in jurisdictions without this stricture or forced out of the field completely.  A debate needs to happen about how high code quality can be achieved without alienating qualified outliers.

One of the responsibilities in my position as a 'Firmware Design Supervisor' is to select whom to hire when presented with a pile of resumes.  I try very hard to review them with unprejudiced eyes.  A PE qualification means almost nothing to me.  I always wonder if the HR filter that proceeds me has eliminated someone unconventional like myself.  I'm still thankful for the foot in the door I received 13 years ago when I transitioned from mechanical to software eng (My convoluted path = University Physics degree dropout -> Art School -> Fine Art Lithographer -> Tool and Die Maker -> Mold Maker -> CAD/CAM programmer (auto and aerospace) -> Firmware Designer -> Contract Software Developer (various from open source to legacy systems reverse engineering) -> Widget Inventor -> Present (I am a poorly tuned servo wrt vocation)).  I cannot in good conscience be a gatekeeper for a guild that would refuse to have me as a member.

Vlad Zeylikman's take was interesting:

Isn't that what engineering diploma is?  Licensing doctors and lawyers has more to do with the guild style limit on the number of practitioners than anything else.  The problem is that 'engineering' is not taught in college; only engineering disciplines are.

I would also like to mention that software engineering has its specifics but you really need to start with engineering fundamentals, i.e., problem definition, problem analysis, problem space analysis (not only possible solutions but also what adjacent areas will be affected).  These subjects are taught but they are not practiced as 'hacking' is cool and can produce results quickly but engineering is boring because it involves a lot of non-coding things...  mechanical engineers have been taught (in the past) to calculate strength and then triple the values for safety.  in software, this is equivalent to tripling the test cycle with random inputs.  instead, we ship software that barely passed a smoke test... 

I also have a pet peeve: engineers should be taught history of engineering, from Chaldeans to Romans, to industrial revolution.  But that is not going to happen....

Dave Telling sent this:

My understanding of the cosmetology license is that it more than anything else a money-maker for the certifying board, and most likely was put into place to minimize competition. My wife does just as good a job at cutting my hair as the "professionals" (albeit taking a bit longer) but could not legally charge people for this without a license. In a similar vein, the cab companies are up in arms because people are using an app that lets them gives rides to others who are going to the same place/same direction -- basically they (the cab companies) are accusing them of offering an "unlicensed" taxi service. Taxi licenses in NYC are very expensive, so I can see how someone might object to me giving a ride to someone else for a much lower cost, but in the end, what is the problem? I don't know what requirements one must meet to drive a cab in NYC, but my last taxi experience (in Chicago) was with a guy who could not speak English, did not know how to get to my desired destination, and even after finally programming his GPS, I had to tell him when to exit the freeway and where to turn! What was THAT certification/license worth? Then the taxi company has the nerve to charge me "meter and a half" because the hotel was in "the suburbs" instead of downtown. Licensing, outside of a very few professions (medical) has never been much more than a way of making money for someone. Engineering is particularly difficult, because there are so many categories and sub-categories. In addition, as we who work in the industry know, certification does not guarantee competence. In the end, in my opinion, certification is way for established organizations to maintain their lock on particular field.

Alan Ott had a book recommendation:

Are you familiar with the economist Milton Friedman? He wrote a book called "Free to Choose: A Personal Statement," in which he enumerates the virtues of free markets one by one. The book has a series of chapters called, "who will protect us from the $some_bad_people," where he one by one discredits arguments for government limiting access to professions with things like certifications. Cosmetology is one of them.

Scott Nowell wrote:

Without answering your question on licensing being inevitable, let me first ask, have you ever seen it make a difference?  I have not.  I have known a number of licensed PE’s and I can’t name one that I thought was as good as some non-degreed software engineers I know.  Then again, PE licensing involves such a broad range of requirements it seems to be more a jack-of-all-trades, master-of-none situation.

This is along the same line as our not requiring a specific degree for our engineers.  I would rather hire someone with the passion for the work and the demonstrated ability than someone who managed to pass the required classes.  I have worked with far too many MS and PhD degreed engineers that were nearly incompetent where it counts.

Larry Eaton contributed:

I've come to see professional licensing as a way for unions to gain a legal method to limit competition. In most cases it seems to me that the profession are the ones being protected, not the public, as the licensing authorities would want us to believe, as justification for the rules.

Many years ago, the IEEE had a leaning toward licensing. I believe their prime motivation was to protect US workers from foreign workers. Another protection they seemed to promote was the limitation on work visas and such.

This is why I dropped my IEEE membership. I feel that I would be a hypocrite to support this and yet support free trade, oppose unions, etc. It would be against my political and ethical beliefs. On a side note, I believe that, for instance, the AMA is significantly responsible for our health care mess. It seems obvious to me that allowing an interested party, (doctors), to control the number of new doctors on the market is a great way to drive up medical costs. Another great way to drive up medical costs is to let doctors decide that I must visit one and get permission, before I can purchase a needed drug, such as blood pressure medicine or athlete's foot cream, or birth control pills, etc.

Anyway, it would seem to me that requiring licensing of embedded developers would serve me from a selfish point of view, but would not serve the public, quite the opposite.

I suggest that we police ourselves possibly, by having a private certification authority. Advertise this authority and get the public to recognize it as an organization dedicated to quality. Then have it funded by engineers who agree to their standards and pass a test or something similar and pay for membership. Membership to the organization would be a great stamp for your resume.

I think real estate agents, real estate appraisers, boat appraisers, jewelry appraisers and many more use this business model.

Why couldn't we?

Finally - the license business is wrought with self interest as evidenced by the requirement of things like licensing to wholesale liquor, to sell caskets (both of which have lost court cases here in Ga), and such silly things as licensing of flower arrangers in La and as you mentioned, licensing of barbers, interior decorators, the list goes on...

John Carter had this thought:

There is a balance between certifying the developer, and certifying the company and certifying the product. I have no certifications beyond university degrees. But the company I work for has ISO (and other) certifications

The products I work on under go many very rigorous certification test regimes for vibration and waterproofness, security, interoperability, RF noise, RF band compliance, intrinsic safety in hazardous atmospheres, ..... the list is very long and very comprehensive. Some tests are external, some done by a large internal test team.

The people who perform certification tests have the appropriate certifications.

Doctors need to be certified since their effects are "In Real Time". I don't need to be certified since certifying my outputs is a more effective procedure for controlling risk.

The Hundred Years' War

The war grinds on. After a century the tally stands at 30 million dead worldwide, with no end in sight to the slaughter. Industry cranks out the machines of death, manned by citizen-soldiers on the field of battle.

No, I'm not reciting a history lesson about Europe in 1453. This is here and now, in the US and abroad. The battlefields are the highways; the instruments of war the automobiles manned by sometimes crazy, sometimes distracted, or sometimes just confused ordinary people. They range in age from 16 to far-too-old, their driving skills might be comparable to a NASCAR professional or perhaps are just being learned.

Every parent of teenaged drivers lives in fear of that late night call. I tried to give mine training, advice and wisdom, but told them the most important tool they have, should they chose to employ it, is reflection. Most drivers operate as an open-loop system, accumulating bad habits over years, rarely thinking about the implications of these habits.

Close the loop. Stop and think about your practices. Change something.

I give the same advice to engineering groups. Stop and think about your development efforts. What practices do you use to ship the system? Do you start in a spirit of professionalism and then descend into the 7th circle of hacking perdition as the deadline looms? Are comments accurate or, in change frenzy, do you "forget" to update them as the code changes?

The notion of continuous improvement has greatly changed the world of manufacturing. It's the deliberate and methodical analysis of processes to find ways to eliminate the unneeded and optimize that which is necessary. Soul searching is an ancient idea behind improving one's self. Feedback stabilizes systems, be they electronic systems or human. We all develop bad habits. Stop and reflect, from time to time, about your development (and driving!) practices. Bad habits are like entropy -- they accumulate constantly unless one works hard to keep things in order.

Every important endeavor, like engineering embedded systems, benefits from introspection.

What do you think? How do you avoid developing bad habits?


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

Steve Bresson sent these links to funny and relevant comics:

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.