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

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• What I'm Reading
• Aging is Hard, for People and Software
• Book Review - The Hands-on XBee Lab Manual
• Embedded Security
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

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

"The World Wide Web was precisely what we were trying to PREVENT-- ever-breaking links, links going outward only, quotes you can't follow to their origins, no version management, no rights management." – Ted Nelson

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

Mentor Graphics recently announced an interesting approach to spur small outfits to use their Nucleus RTOS and Sourcery CodeBench C/C++ IDE. Any commercial company with sub-$1 million annual revenue can get complete access to these tools for free, for up to five developer seats. These are not the stripped down limited-time or limited-program-size versions that are so common, but include the complete tool suite (the license is for one year but is renewable). The qualification process appears to be very easy. A limited range of MCUs are supported via BSPs, but I'm told more are coming.

Obviously, this is a plan to plant Mentor's tentacles into startups that morph into larger organizations which will eventually buy licenses. That's hardly new; Apple did well pushing their stuff at discounted rates into the schools for the same reason. And it seems to make business sense; few small startups are going to fork over big licensing fees, so these are customers that Mentor would never have.

There's more info here.

The Right and Wrong Way to Implement Cryptographic Algorithms in Embedded Electronic Systems - including fascinating info on differential power analysis.

Software rots. Age is unkind to it. Just as people acquire aches and pains as the years progress, code tends to run down.

Young programs are slight, sprightly things that respond like gazelles and eat little disk space or flash memory. Bugs and misunderstood requirements frustrate users, but few expect much maturity from adolescence. With time and tuning the code seasons and becomes a fully productive part of a business process or product.

By middle-age patches, improvements and creeping featuritus bloat the girth and hobble performance. The graying code slows and swells, though still satisfies users.

Continuing bug fixes and ever more features drive the software into old age. Now annoying glitches and oddly interacting components deliver at best arthritic capabilities. Only heroic intervention at great expense staves off the inevitable. Cancerous growths -- forks controlled by hundreds of poorly understood #ifdefs - metastasize recklessly. Comment drift renders all documentation gangrenous. Deft surgeons remove chunks so infected they're useless and graft repairs onto essential organs.

The code acquires the moniker "legacy application," that label reserved for a program that's still needed but is so old and decrepit that maintenance costs soar. Some companies have a culture that respects legacy apps. In most they're considered a burden supported by the lowest paid developers, who resent the impact on their lives and careers.

When the cost to modify the code exceeds the value to the customer the program is either pensioned off to unsupported status or is euthanized. Sometimes it's replaced by a direct genetic descendant, a completely new, rewritten package whose design is drawn from the ancestor's structure but which exhibits all of the desirable attributes of youth.

And then the process repeats, with each generation evolving towards a higher level of complexity, better suited to fit the new, changed nature of the computing environment, then aging, eventually being buried 6 bits deep.

Death is an inevitable part of all life cycles. At some point a program simply meets no need. The world changes and requirements disappear. But all too often we kill off the software because of the creaky joints; it's simply too difficult to maintain.

Wise developers build the code from the ground up with robust DNA that's impervious to the damage caused by cosmic rays of real-world change. They create an immune system (documentation, structured code, extensible design) that bends to the inevitable assaults rather than brittlely collapsing.

But once launched the program is under the care of maintenance custodians, who might wreak havoc faster than the Ebola virus. Maintenance can be a careful process that applies wrinkle cream to defer the inevitable fate of the aged, or a process of rubbing soil into an already infected wound.

Legacy apps are often the core software that creates the bulk of the company's profits. Yet we dump support on the newbies who hack quick fixes, invariably breaking other features. They're untrained and inexperienced. Patches accumulate, each a little bit of ugliness layered on top of earlier mistakes.

Great maintenance people don't slap a poultice on the exposed wound. They grow a culture, determine the illness's root cause, and then inject exactly the right antibiotic. The patient recovers, healed, with neither scars nor lingering infections.

The cost of great maintenance is high; but that of poor support is ultimately even higher.

How do you prolong your product's life?

The 21st century has seen the dawn of the wireless era. Cell phones are no longer telecom devices; they're part of the vast Internet. Now we're all connected all of the time, in the office or at the beach. Some of us use a smart phone more for data communications that voice transmissions. Indeed, that mobile device may have four or more antennas: one with a link to satellites in space for navigation, another to the 3G network, a wi-fi connection and Bluetooth for near-field links to headsets and the like.

Radio data communications surrounds us, from messages sent to the smart sign hanging over the highway to science instruments transmitting their findings from the remote arctic to a lab in some pastoral setting via a satellite uplink.

Why have a Bluetooth link from the phone to a headset? A wired approach is a nuisance. It's bulky, in the way, and snags on things. Electronics is cheap; connectors are not, and the wireless version likely saves money and is more reliable. Messing with a tangle of cables in a lab or even with your PC is awkward. It won't be long before those all go away.

It's much more complicated to establish a link over an RF connection than with a wire, but smart hardware costs little today, and canned software is increasingly available. One popular option is Digi International's line of XBee prepackaged radio modules. You don't need to understand the nuances used, like direct-sequence spread spectrum coding or offset quadrature phase-shift keying, because those details are all taken care of by the modules.

You do need to understand how to use and interface to the modules, which is not made any easier by the terse and sometimes cryptic manuals. And XBee also uses the old AT command set, which is increasingly hard to find information about. For these reasons Jon Titus's Hands On Xbee Lab Manual is invaluable.

We learn in different ways. For many of us a hands-on approach is much more efficient than slogging through data books. Jon has taken that approach here, in a series of experiments designed teach by doing. From the very beginning you'll be putting together components that make something neat happen. Early experiments emulate a single-direction wire: a receiver module's output pin mirrors the input pin on the transmitter. Look Ma - no wires!

Each lesson is progressively more complicated and useful. Send analog data through the ether. Control multiple XBee modules. Connect other embedded components, like an Arduino Uno or ARM mbed board to the XBee modules. That, of course, is really the basis of embedded wireless networking.

Explore personal-area networks. These are self-assembling communications links where the network discovers at run time which XBee modules are operating. Jon shows how to do this, and how to piece the network together. Along the way you'll learn to handle interrupts, a crucial concept in the world of embedded systems.

Complex stuff. But fear not: Jon shows every step of each experiment. The lavish illustrations leave no chance for confusion. Whether it's a screen shot of a communications tool or a drawing of how to connect a LED, nothing is left out.

Welcome to the second decade of the 21st century, the age of wireless data communications. This book is your essential guide to using XBee modules to toss off the shackles of wires.

One prediction I'm constantly wrong about is that of security for embedded devices. It seems so obvious that so many of our connected systems could serve as attack vectors! And they are just as subject to intrusion. Compromised SCADA systems frequently make the news, and even medical electronics gets hacked. So for years I've been convinced that the Next Big Thing in the embedded world is security. So far, that prediction has been wide of the mark.

But VDC has a recent posting that may explain the lack of interest in the subject. It seems customers just don't care. They don't think most of the electronics that surrounds them is particularly vulnerable. So there's no demand for better security. Absent demand, security doesn't sneak into the requirements documents.

Consumer concerns about security. Image courtesy of VDC

It's hardly surprising that consumers worry about their money. But a connected car? The security implications can be huge.

There's another data point. A young insurance salesman stopped by recently, and he politely inquired about my work. He was very surprised to discover that so many products have computers in them. The notion of an embedded system was totally foreign. So perhaps many just don't have an inkling about the nature of the electronic world, and so therefore don't perceive a threat.

But one thing's for sure. Over the next 12 months embedded security is going to become a the most important issue developers face.

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.

Note: These jokes are archived at www.ganssle.com/jokes.htm.

Heard on a game show on NPR recently: "What product is Bill Gates contributing $100,000 to to create an improved version?"

One contestant answered: "Uh, Microsoft Word?"

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. .

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.