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
• Model-Based Design
• Maybe Rust is Not the Future
• A Cap to Give a Short Boost?
• 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" in the subject line your email will wend its weighty way to me.

"Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday's code." - Christopher Thompson

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

EDN has a clever 16-bit DAC made from a DPOT and PWM here.

Sergio Caprile wrote about model-based design:

Chaitanya Patel had some interesting comments:

And Jackson Burnett contributed this:

Googleplex, CA. In a cavernous hanger at Moffett Field, Larry Page today addressed a screaming coven of developers at Google's World-Wide Developers' Conference. "We have many new products I want to announce today," he started off, "but first I want to talk about those idiots in Cupertino. It's Ipod this, Iphone that. What, didn't them geeks learn any English? So today we're introducing the MyPod and MyPhone. That Gulfstream 5 over there in the corner is MyPlane, and don't you forget it."

Developers swooned while texting each other and updating their MyGoogle+ pages, their MyGlasses forming a markedly-effective remedy to procreation.

"As you know, our motto is Do No Evil, which we've demonstrated by pursuing world domination, passing the details of your really weird and disgusting search queries to any cop with a flash drive, and relocating our headquarters to the tiny island of Aunu'u to evade taxes while lobbying for millions of H1-B visas to protect our bloated bottom line.

"Today..." A pause. The crowd, faces anticipating a world-changing announcement, stopped breathing. "Today, I'm introducing SLOTH, the world's slowest computer language."

Puzzled murmurs echoed in the hanger from developers who had just learned that Rust was the New Way Forward.

"We've discovered that our minions, uh, users, aren't really doing much. MyChrome spends 99.999999% of the time executing a little event handler in cache just waiting for our vassals to hit a button on the keyboard. It's the same if they're using MyDocs, MyMail or pretty much any other MyApplication. The CPU is just tapping its toes, executing three or four billion instructions per second to deal with some barely sentient serf hunting and pecking like he had never seen a keyboard before. Besides, pretty much all of our subjects are mostly updating their FaceBook pages while pretending to work. How much computer power is needed for that?

"SLOTH, which stands for Seriously Low Optimization ThresHolds, has been under development for a really, really long time. I mean, like, forever, man. But now we can proudly announce a CoreMark of under 0.000001/MHz on an Intel i9."

This reporter later learned that SLOTH programs sequence through every processor instruction, and checksum all of memory between each statement to insure even heating of the ICs. Compilation units are individual statements – one statement per file. By default the compiler #includes the entire source of MyAndroid with each compilation unit, though random jumps are inserted between lines to confound the processor's branch prediction. All integer calculations are promoted to quadruple-precision floating point which is interpreted rather than translated to machine code. Complete copies of Moby Dick in UTF-128 are inserted between statements to eliminate short branches and thrash the cache.

Mr. Page went on: "But now there is a very great Evil, yea a veritable Mordor that will unleash trials and tribulations unto the seventh generation, that is, assuming you ever manage to find girlfriends. For Sauron, in his current Tim Cook incarnation, has cursed the world with a new language that is so easy to use, that is so completely and sinfully graphical, that anyone will be able to write a killer app. Next thing you know those lousy theater majors will be able to find work in our formerly exclusive software world. We techies, who elevated ourselves to the high priests of the modern era, will have to learn the social graces to find work. I was just informed that we'll be expected to chew with our mouths closed!"

Pandemonium. One attendee shouted "No, no!" Others started sobbing. "My mother warned me I'd have to take showers someday," one sniffed.

A handler leaped to the stage: "Our Sacred Leader feels your pain. Let him continue!"

Mr. Page said: "SLOTH is specifically designed to be unintelligible to pretty much everyone. Not only is it slow, the syntax is more cryptic than APL's, uses more parenthesis than LISP, and completely avoids all symbols between ‘A' and ‘Z', except for ‘I'. All variable names are combinations of ‘I's."

The handler looked shocked and whispered in Mr. Page's ear. Mortified-looking, he added "Of course, by that I also mean no characters between 0x61 and 0x7a with the exception of 0x69."

"The curse wrought by Java has been eliminated in SLOTH. All operations are pointers, and there are a minimum of three levels of indirection required for any statement to compile."

Snickers. "That'll show them poly-sci majors!" one attendee yelled.

"Another upside is that so much computer power will be needed to run a SLOTH program than our chattels, who have been completely taken in by the IoT marketing claptrap, will be unable to move from in front of the MyGoogle screen due to the weight of their wearables."

Delirious now, the crowd wept with joy as Mr. Page was hustled to his G-5, which taxied onto the 101 for takeoff. The police, clutching their flash drives, directed traffic onto La Avenida St., conveniently shutting down Microsoft's Mountain View campus.

In other news, rumors persist that Microsoft will introduce an even slower language called "C-flat-minor" next week.

I've been getting email about two subjects relating to ultra-low-power systems. Let's consider a system that must run from a coin cell - say a CR2032 - for ten years. That works out to an average current draw of 2.5 microamps before the battery is discharged.

What type of decoupling capacitor should we use? A related question is: could adding a capacitor across a battery's terminals provide a short-term boost that could sustain a pulse load? It's not hard to show mathematically that the answer is "yes."

But the math is irrelevant. In engineering we're always faced by conflicting needs and what appears a simple solution sometimes isn't.

It's useful to think of a battery as a zero impedance source with an internal resistor between it and the terminal. That resistor's value increases as the battery capacity is drained. If it were 50 ohms and the system needed 10 mA the terminal voltage is down by half a volt, often enough to cause the MCU to crash. Add a big capacitor, as in the following diagram, and a short pulse load can draw on the charge stored in the cap.

In a TI white paper ("Coin Cells and Peak Current Draw") the authors conclude that this is a viable solution. They show a case where a capacitor must sustain a 30 mA load for 1 ms. An 87 uF capacitor will do the trick, though they recommend 100 uF since no one makes 87 uF devices.

There are a couple of problems with this conclusion.

First, the capacitor leaks. It's always across the battery terminals, so is sucking juice, depleting the battery, even during long sleep intervals. How much leakage? It depends on a number of factors, including dielectric material. Let's consider tantalums, which offer great capacitance versus cost figures. The following table shows the numbers for a 100 uF part. (For tantalums it's usual to rate leakage in CV, where V is the rated, not the applied, value.)

The last column is the most telling. Given that the average current draw over 10 years cannot exceed 2.5 uA, just the capacitor's leakage will suck the battery dry in a fraction of a decade.

Who would have thought that a cap could leak more than Edward Snowden?

How about a better part? The best low-leakage capacitors with the C values needed are MLCC. MLCC leaks are specified in ohm-farads:

It's clear Y5V dielectrics can't be used. Select a more expensive X7R device. And, one must be careful which X7R is selected as some leak as badly as Y5Vs.

Takeaway: be really careful which decoupling capacitors you choose!

The X7Rs exhibit better temperature stability, which has always been the primary reason to use them, but not as a function of leakage! Here's a typical graph of normalized leakage versus temperature:

A system that has to run over wide temperature extremes may leak two orders of magnitude more than shown in the previous table; that sweet AVX spec'd at 0.3 uA suddenly looks like a moderately low-value resistor. But even over room temperature, say 20 to 30 degrees, plan on twice the parasitic drain than specified. In the case of the AVX a quarter of the battery is lost to the capacitor.

It gets worse.

MLCC devices derate themselves. As the applied voltage increases, the effective capacitance decreases. Murata has a tool that helps model this, and here's the result for 22 uF parts:

If space is precious you have few options. Apply 3 volts to a nice small 6 V 3216 device and only half the capacitance is available. The TI paper specifies a 100 uF part, but in this package you'd have to use 200 uF. Alternatively, one could use a higher-voltage (bigger and more expensive) device, or use a larger package as shown in the graph.

Perusing various sites it's rather astonishing how few capacitor vendors specify leakage. A lot of them claim "low leakage" but don't give numbers. That's about as useless as a campaign pledge.

Kemet's excellent "Application Notes for Tantalum Capacitors" does show how derating the voltage can help. Operate at the cap at a third of the rated voltage and the leakage will typically decrease by an order of magnitude. Go to ten percent of the part's rated level and leakage dives by another factor of five. But in a three volt system that means a 30 volt capacitor -- bigger and pricier.

These deratings are "typical" numbers. Use with caution.

So, despite the problems with capacitor deratings and leakages, can use use one to temporarily sustain a Vdd high enough to keep an MCU from crashing during a brief waking period?

The following graph shows the required capacitor, at 20 degrees C, for 10, 20 and 30 ms pulses with various loads, ignoring all of the complicated effects noted above. You'll have to factor all of those parameters in as well, which, as we've seen, can more than double the required uF. The leakage numbers are based on that nice AVX component. Though the TI paper uses a capacitor to boost power for 1 ms, for Bluetooth and other protocols tens of ms are more likely.

So we've done the math, and have figured out what size capacitor to buy. Let's ignore all of the unpleasantness and assume that a 100 uF part fits the bill, and that we're using a low-leakage AVX part. They're $27 each!

Maybe this is a government project where costs don't matter. Using the graph above we pick off a 400 uF part for a 10 mA 20 ms load (remember, this is before all of the derating that must be done). The leakage will eat about half the battery capacity. And, the capacitor doesn't exist; the biggest such part on the market is 220 uF. You can't buy a bunch of smaller parts and parallel them, since the leakage will go up.

What about a supercapacitor? These are astonishing devices that offer farad-levels of capacity. Alas, the lowest-leakage supercap I can find is from Cap-xx, and they quote 2 uA at 23C, doubling at 70C. That's impractical since even at room temperature it'll eat just about the entire 2.5 uA current budget.

Summing up, in the use case I've described (ten years of system life from a coin cell) it's impractical to get a short Vdd boost from a capacitor across the battery.

Daniel sent this:

This is from Tony Williams:

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.

I showed my 12 year old son an old floppy disk. 

He said "Cool! You 3D printed the save icon!"

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.