You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email.
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 https://www.ganssle.com/onsite.htm.
|Better Firmware Faster Seminar
No ESC East? No Problem!
What? No Embedded Systems Conference in Boston?
We'll sure miss the cancelled ESC, but you can still come to my one-day Better Firmware Faster class near Boston November 1. It will be held at a hotel near Routes 90 and 495, about 38 miles from Boston's Logan airport and 39 from Providence's TF Green. This is the first public version of the class in two years.
This is a very fast-paced (and fun!) full-day course that teaches better ways to produce firmware. I'll show how to drastically cut bug rates and shorten schedules. Plus, I cover technical issues that are unique to embedded systems, like dealing with real-time issues.
Seating is very limited so sign up today.
|Quotes and Thoughts
The best programmers are not marginally better than
merely good ones. They are an order-of-magnitude better,
measured by whatever standard: conceptual creativity, speed,
ingenuity of design, or problem-solving ability. - Randall
|Tools and Tips
Please submit neat ideas or thoughts about tools, techniques and resources you love or hate.
An article on EDN has a nice list of tools.
|What I'm Reading
The Balancing Act of Choosing Nonblocking Features, September 2013 Communications of the ACM. An interesting look at nonblocking code.
Could the tunneling FET lead us past 6 nm?
|Overpaid? Compared to What?
Mike Perkins had an interesting take on two things in the last Muse:
Jan Woellhaf had a very original and thought-provoking idea about overtime work:
Reinhard Kopka reports from Austria:
Nancy Blair wrote:
An anonymous reader had some information about working overtime in Germany:
Intel's FinFETs are helping push Moore's Law to sub-20 nm geometries, and recently TSMC showed their roadmap to 10 nm. FinFETs have a number of useful attributes, not the least offering a reduction in transistor power consumption. Intel's Atom processors can run on just a few watts of power.
A "few watts" is an enormous power budget compared to a lot of embedded MCUs that run on just 150-200 microamps/MHz. Even more astonishing are the sleep modes which can keep an MCU dormant but alive on tens of nanoamps. The goal is to run small systems for years (some foolishly claim decades) on just a small battery, like a CR2032 coin cell. These systems sleep nearly all of the time, waking once in a while to perform some action. Think smoke alarms, remote controls, and the like.
A CR2032 has about 220 mAh of capacity (quoted capacities vary a little depending on the vendor), which means it can source one mA for 220 hours. (There is some dependency on capacity vs. how fast one discharges the battery). Its nominal voltage is 3.0, perfect for these 1.8 to 2V min MCUs, and the discharge curve has a sharp knee. For some reason the vendors claim they run at 3.0 to 3.3 volts; my experiments show otherwise. The following curve is for 9 Energizers discharged at a 0.5 mAh rate. The load is then removed and various loads depicted by the curves momentarily applied. Batteries from Duracell, Maxell and Panasonic behave similarly.
Batteries discharging at a 0.5 mA rate.
Some of the vendors claim their MCUs can run for 20-30 years from a single CR2032. That's may be true in theory, but not in practice. The vendor debate centers around how long a system can sleep on a coin cell, but that's simply irrelevant. The right question is: how much useful work can the system do while awake?
"Useful work" translates into a lot of things (clock rate, instruction set efficiency, etc), but is ultimately bounded by how much current the system (MCU and other components) can consume while awake. It's is the budget we have to work with, and cannot be exceeded (on average).
I came up with the following curve, which assumes a ten year battery life. It shows the number of mA available while awake as a function of time spent sleeping and amount of current consumed while sleeping.
Here's a blowup for systems that sleep practically all of the time:
mA available for deeply-sleeping systems
Here's the key takeaway: Sleep currents are essentially irrelevant. And another important point: there's very little energy available for work when the processor is awake. Internet of Things? No chance, due to the power needed by communication, unless the system sleeps at least 99.99% of the time. In other words, it's awake 9 seconds per day or less.
The two sleeping graphs are theoretical. In practice the situation is much worse due to the batteries' discharge characteristics. More on that to come.
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.
Patrick Wong writes: I found my Yahoo menu upside down (when I hover on my user ID). It was consistently upside down. I was joking myself Marissa Mayer/Yahoo must be pushing the boundaries (and teasing our brain or marketing ploy??).
|Advertise With Us
Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. .
|About The Embedded Muse
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at firstname.lastname@example.org.
The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.