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

Ad

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 http://www.ganssle.com/onsite.htm.

Quotes and Thoughts

"If McDonald's were run like a software company, one out of every hundred Big Macs would give you food poisoning, and the response would be, 'We're sorry; here's a coupon for two more." - Mark Minasi

Tools and Tips

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

Scott Whitney wrote:

For an Android emulation of the HP16c, 12c, 15c, and 11c, there's a really good suite called "ClassicRPN" from AmeloConsulting.  I absolutely loved the whole "Voyager" series of calculators from HP, and this is a pretty faithful implementation of them.  Runs great on my Samsung Galaxy Nexus, especially if I hold the phone sideways - looks almost exactly like the real thing!  It's available through the google play store:  https://play.google.com/store/apps/details?id=com.ameloconsulting.classicrpn&hl=en .  I think you can also buy individual calculators if you don't want them all.

What I'm Reading

Quantum Leaps is advertising in the Muse this issue. Their book, Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems by Miro Samek is one of the most thought-provoking works about embedded systems. I did not find it an easy read, but it was well worth the time.

How to Program Unreliable Chips - It's ironic that advancing technology is giving us lower reliability. This article is about an effort to embrace the lower reliability in some applications. A corruption of the program counter is a disaster, but an incorrect pixel on a screen is probably not a real problem.

Yet another USB scope. Yawn. But wait: this is a Kickstarter project to put a scope in a wristwatch! The ultimate in geek wear, and I can't wait to get one.

Frequent correspondent Charles Manning sent a link to an effort to add formal structure to C programs. The idea is to annotate the code in the comments with constructs that help external tools check the code's correctness. There's more here. This is somewhat akin to the SPARK language, though SPARK is designed from the outset to lead to better outcomes. It's a fascinating notion, but will probably struggle to gain traction.

Freebies!

Well, not a freebie, but Ada Germany is willing to sell a copy of the Ada Language Reference Manual for half price. Contact Huber Keller.

Freescale graciously donated some of their way-cool FRDM-KL25Z Cortex M0+ board (which I reviewed here). So it's giveaway time. Answer this puzzler for a chance to win a free FRDM-KL25Z board: What is the strangest or funniest embedded product you know of? Please include a link or other substantiation if you can.

The FRDM-KL25Z board

The FRDM-KL25Z

Contest rules: three winners only, and all will be selected at random by our biased and highly-partial panel of curmudgeon judges on or about November 29. Fun is more important than ultimate truth. Send your entry to marybeth@ganssle.com. Sorry, we can’t acknowledge entries. I'll post the winner’s name (but no other contact info) in the next Muse and any funny or interesting commentary.

Reply to When Faster is Slower

Bob Fowler had some comments about "When Faster is Slower," from the last Muse:

I have made the claim to younger developers that it still takes 6 months to develop any application that took 6 months in 1968 when I started developing programs.  They usually look at me as if I were lost in the woods with no compass.  Some have commented that if that were true, the developer produces applications that do so much more today than they used to.  That is true, but I look beyond the ribbons and bows and still cannot justify the idea that an accounts payable application that processed vendor checks accurately in 1970 is less than the same application that today processes with the same accuracy but with a mouse, lovely graphics and a workstation that cannot run fast because of the virus checkers and spybot detectors running in the background.  Each project took 6 months and each resulted in the same product benefits regardless of how ugly or pretty the environment.

What is the difference?  The enhanced "user experience" so popular today must be burdened with many extra features that are presumed to improve the practice that they support, be it accounting, process control or firmware development.  Moore's Law has spoiled us.  We now have so much more computing power available to the developers and buyers of software products that we have become seduced by the extravagance that has arrived so cheaply.  The developers of tools are in the same trap.  Rather than enforce a consistent practice of designing and coding assembler, C or C++, we are faced with a blizzard of techniques and products that put off the responsibility for accuracy and promptness to tools that we just learn before having to upgrade to the next level of enlightenment.

In the midst of the storm, the target of our effort is sometimes forgotten.  It still takes 6 months.  We haven't learned to shorten the schedule by focusing on the destination instead of the chariot.

That's my opinion, and I'm stikkin' with it.

Certification

A typical techie, totally lacking in vanity, not even sure what mirrors are for, my only requirements for a haircut are cheap and fast. And so I found myself at the local barbershop, chatting with the stylist as she did her $15 magic.

I'm fascinated with people, so asked about her life and her job. A single mom, she was more or less abandoned by hubbie. The court-awarded child support arrived for a while, but petered out. Sometimes a check comes, more often not. She's had to raise two kids entirely on her own. Little education limited her prospects, but through heroics I can barely imagine she managed a short stint at the local Vo-tech and obtained her cosmetology license.

License? Turns out that in Maryland all hair stylists must pass a test and be certified. Now, the peril we're talking about is legions of Marylanders walking around with bad haircuts. No one will die or be injured, though perhaps teenaged girls will court suicide.

I thought about our profession. We're the people who built nuclear power plant controllers, avionics, life-critical medical instrumentation, and systems that control every aspect of huge industrial facilities.

License? Certification? Nah. If you can spell "C", you've got a job. There's no need to understand failure mode analysis, DOD-178C certification, or FDA software requirements.

Do you need to understand software methodologies, process engineering, CMM, PSP, agile development, or complexity metrics? Nope. Just have the ability to crank some code, fast.

Millions of people depend on firmware-intensive pacemakers and other medical implants for each heartbeat. Supersonic planes cannot be controlled by mere humans; without the computer they'd break up in the blink of an eye. It won't be long before steering wheels just control an encoder.

Our systems are getting more complex and ever-more-ubiquitous. Malfunctions are on the upswing. We do know that as firmware complexity increases, errors will too. The curse of frenetic competition and our obsession with quarterly profits drives companies to focus more on shipping fast than on getting it right.

This is the only industry left where we can ship products with known defects and not get sued. That will certainly change. And when it does, I suspect insurance companies who pick up the tab for the huge jury awards will demand that developers have some sort of professional certification. Perhaps the certification will be meaningless, but it will help provide for a better defense in court. If I, with no medical credentials, operate on a patient and make a mortal mistake I'll go to jail. A doctor will probably just see a rise in the cost of his malpractice insurance.

Bob Paddock has been tracking the increasing number of US States that are requiring one has a PE license to call oneself an "engineer."

Though I abhor the thought of certifying developers, and would probably leave the industry if this happened, is it inevitable? What do you think?

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.

The sooner you fall behind, the more time you'll have to catch up. - Steven Wright

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.