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
• Beware the Brown-Out Reset Circuit!
• Working With Your Hands
• More on Testing RAM
• 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.

I'm off sailing this month so may be very slow in replying to email.

When it comes to software quality, you can pay me now or you can pay me a lot more later. Karl Wiegers

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

Chris Svec sent this:

Low-power MCUs usually have a built-in brown-out reset (BOR) circuit. Unfortunately, most are poorly designed and/or lightly documented and should not be used.

One popular ultra-low power MCU, from a vendor who noisily advertises two to three decades of coin cell operation, has a BOR which is off by default. On, it requires somewhere between 8 (typical) and 16 uA (worst case). If your system is running from a battery, for a decade of life from a CR2032 the system's average power draw cannot exceed 2.5 uA. Even if one were to foolishly use the typical number, the BOR by itself will deplete the battery in just a couple of years.

Another vendor, pushing extremely-low power ARM parts, rates the BOR at 0.49 to 1.26 uA -- typical. There's no max listed; there's not the slightest guidance of what statistical distribution one can expect when making thousands of systems. 1.26 uA eats half the 2.5 uA budget.

In another case the datasheet reads about the BOR: "In the deeper sleep modes, this will contribute significantly to the total current consumption."

As Deming said: "In God we trust, all others bring data." They didn't, and it strikes me as risky to rely on divine intervention instead of careful analysis. I'd be wary of using these uncharacterized parts in long-lived applications. As always, read the datasheets pessimistically and carefully.

When does the BOR interrupt occur? In some cases the voltage range is very wide; an example is an MCU where it is listed as 2.05 (min), 2.2 (typ), and 2.35 volts (max). Doing worst-case design you'd have to assume that the BOR may occur at 2.35 volts.

The following graph shows the voltage a CR2032 battery can deliver as it discharges as a function of load (note the 0.5, 10 and 30 mA lines):

The 10 mA load line is pretty common for an awake MCU with enabled peripherals; 30 mA is not unexpected if there's any sort of wireless comm going on. The heavy red line is at 2.35 volts, the max value where we may see a BOR interrupt. Note that in this case the BOR circuit will signal a dead battery, if there's a 30 mA load, shortly after you ship the product. With a 10 mA load the battery-dead indication happens when there's still 31% capacity left.

In other words, the BOR circuit is useless in this sort of battery-operated scenario.

A much better alternative is to leave the BOR off and use the ADC. Wake up from time to time, apply a load similar to what the system normally needs when awake, and read Vcc. If it's near 2.0, then signal a battery failure (or take whatever action your system needs in this situation).

If such a reading is taken once every ten hours (surely, more often than needed), and 10 mA were pulled for 1 ms during this reading, over a decade this eats only 0.03 mAh, or 0.01% of a CR2032's capacity. And, by manually reading the ADC a more nuanced approach to battery management is possible than by relying on a single, poorly-controlled, BOR voltage.

When I was about 8 or 9 my grandfather would bring loads of old lumber by the house for me. I built a succession of "forts" in the backyard, tearing each down as soon as it was completed in order to craft a more perfect version.

About the same time my very frugal dad bought a new Sears Craftsman drill. Old timers will remember these: aluminum cased, they ran forever. He gave me his old one, which I used for many years till it was lost in a shipwreck. That drill spawned many creations, in the early days most silly and non-functional.

Building stuff with scraps led to making radios, and then other bits of electronics, till in high school my dad and I companionably built a separate room in the basement for my electronics lab. In those days WWII surplus equipment was plentiful and cheap. Working with vacuum tubes eventually morphed into transistors and ICs.

I went to college to study EE thinking that it was electronics that was so fascinating, but over the years have realized that, while the subject is utterly compelling, what drove me into engineering was the love of making things. Wiring up a circuit. Designing that circuit. Creating software that does something. (And this is probably why I'm drawn to embedded: PC programmers write code that doesn't do anything fun; embedded people flash lights and drive motors.)

So today, 60 years after banging nails and wood into forts, I have a pretty complete woodworking shop. It's still fun and rewarding to take an idea and mold it into reality. With my own hands. Those forts morphed into building a barn (I'd long dreamed of building a real structure; turns out, never again!).

While many engineers never build things, what drove me into the field was the connection between the intellectual work of solving a problem on paper and then converting it into reality. In truth, most of the systems I designed were built by technicians, but making them work meant surrounding myself with test equipment and tools. Doing stuff. With my hands. C code typed with clean fingernails ultimately makes things happen!

My stepson got a degree in business management and worked for many years in an office, analyzing data and writing reports. Now he's working on boats. He has found that, for him, working with his hands is more satisfying than white collar work.

(For a different - and fun - take on programming as drudgery, listen to Stan Roger's White Collar Holler.)

I have known incredibly erudite engineers who have never touched a soldering iron yet are responsible for amazing creations. Others were the opposite. One RF engineer didn't do schematics till he had a working prototype; his soldering iron rendered a 3D circuit that, once working, was committed to paper. Steve Ciarcia of Byte and Circuit Cellar fame often said his favorite programming language was a soldering iron. We come at this field from many directions and we need both the lofty intellectual as well as the inveterate tinkerer.

As Charlton Heston said, "You can pry my oscilloscope from my cold, dead hands."

Why did you become an engineer? What is your story? Do you have any regrets?

Jonathan Morton had some comments about testing RAM on the fly from the last issue:

From Jim Allyn. He says "But it's a dry heat, and honestly, it didn't feel a degree over 1000".

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.

A programming language is low level when its programs require attention to the irrelevant.

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. can take now to improve firmware quality and decrease development time.