You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• Designing Ultra-Low Power Systems
• Software Entropy
• More on Crappy Code
• Failure of the Week
• Jobs!
• Joke for the Week
• About The Embedded Muse

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me.

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded" in the subject line your email will wend its weighty way to me.

When Herbert Hoover told a lady he was an engineer, she replied, “Why, I thought you were a gentleman!”

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

Here's a good article about memory safety.

This month's Cool Product is the H32 development board. Christos Apostolidis has kindly made one available to Muse readers.

Enter via this link.

I'm getting a lot of email about designing systems that must run for years from a coin cell. If you see claims that a particular MCU can run for decades from a CR2032, well, apply some engineering sense.

This is a tough problem that spans both hardware and software issues. Neglect either one and the system's performance will be very disappointing. I've studied this at length, going so far as to discharge over 100 coin cells while monitoring their characteristics, and the results are surprising. A full (and long!) report is here, but here are the highlights:

Though MCU vendors make a big fuss about their incredibly-low sleep currents (often measured in nA), for all practical purposes those are irrelevant. If under a microamp or so, sleep currents matter little.

What does matter is how much time your system sleeps.

And even more important is how much work you can do when the system is awake.

The MCU is often the least important coulomb consumer. Other components leak, sometimes a lot. Even the lowly decoupling capacitor can be a significant resistive load.

As a coin cells discharges its internal resistance goes up - a lot. There could be a ton of capacity left, but a high resistance may mean it is unusable, depending on how much current your system needs when it is awake. Here are my experimental results, which shows how the battery's internal resistance means a large drop in voltage delivered to the circuitry:

(The horizontal axis is time, but is unlabeled as it could be in years, for a really low-power system, or hours if it is a current hog.)

Four loads are shown: 1 uA, 0.5 mA, 10 mA and 30 mA. These represent the current the system needs when awake. At 30 mA less than 2 volts is delivered while the battery is still far from discharged.

This implies it's a bad idea to wake up running at full speed. A fast clock pulls a lot of power, and if the battery's resistance is high that could result in a voltage drop large enough to crash the MCU. Better, wake up with a slow clock, and ramp up while monitoring the voltage.

On-board brown-out circuits are pretty much worthless. See the paper for details.

Some advocate using a capacitor to provide some boost to the power supply for a few milliseconds. Though the math works out, in the real world it won't work. An analysis is in the paper.

Though there's much said and advertised about running a system for a decade from a coin cell, that is so technically challenging few will achieve it. Perhaps one can take consolation in thinking one may be retired, or at another job, when the systems start failing, but that's poor engineering practice.

I needed a light bulb for my car, so went to Rock Auto, once a sponsor of my favorite radio show (Car Talk) and found the right part. The URL is 690 characters long! Comprised of numbers and upper and lower case letters, some experimenting found that it is indeed case sensitive. So that's a set of 62 distinct characters, representing 10¹²³⁷ distinct possible part numbers. Now, I'm sure Rock Auto does stock a lot of parts, but given that there are only about 10⁸⁰ protons in the universe, one wonders just what the developers were smoking.

Later in the week I surfed over to Bank of America and clicked on a 927 character link, which could select one of 10¹⁶⁶² web pages.

No doubt these links are conglomerations of selectors and such, probably derived from a lot of history. They remind me of old software that accumulates lots of cruft that nobody really understands anymore.

Software is like life: untended, it tends to rot. Little bits of nastiness fester and accumulate. A quick hack to get the thing out the door never gets cleaned up. The next release also gets some added nastiness. Perhaps one realizes that a method could really be improved... but isn't.

Luke Hohmann preaches "post-release entropy reduction", the idea that the cost of maintenance increases non-linearly with each release as these defects increase development costs as time goes on. "Entropy" is the disorder in the code stemming from the ugliness. He advocates that, at the beginning of each release cycle, we clean up the poor parts of the software.

Though I'm not sure I agree with the math, it is thought-provoking. If M is the mess in a release, and N is the number of releases, he thinks the cost of a release is something like:

(1+M)(1+M)+... (1+M) = (1+M)^N

He goes on to posit that if the cost of refactoring the mess out is R, then the cost goes to:

1+R+R+R... = 1+R*N

which is linear, rather than exponential.

However suspect the math might be, experience suggests that he is on to something. All to often a project will grow into an unmanageable mess until the team, inevitably, tells management that "this code has become too expensive to maintain." His prescription to clean it up before adding features seems good advice.

Tom von Dein took issue with my thoughts in Muse 477:

Shannon Spencer sent this:

And this is from Rob Wehrli:

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.

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 intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.

These jokes are archived here.

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.