|Jack Ganssle's Blog
This is Jack's outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at firstname.lastname@example.org. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).
|For novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.|
September 17, 2018
The latest issue of IEEE Embedded Systems Letters (full disclosure: I'm on the advisory board) has an article titled The IoT Energy Challenge: A Software Perspective. It's not particularly useful for practicing engineers, but does raise some worthwhile points.
The authors correctly state that the structure of the software inside a low-power IoT device is hugely important in influencing the energy needs of such a product. They cite a study that claims the way the code is implemented can account for 80% of the power used. I have no idea how true that claim is, but that strikes me as being high. Maybe the biggest factor is how much time the device spends sleeping, which is probably mostly application dependent. That is, a system that only needs to wake up and take data once an hour is inherently more frugal than one that needs to be less somnambulant.
The article surveys the state of the art in measuring energy needs of IoT systems and notes that today it's basically impossible to understand how much energy is needed.
And yet… the market has addressed this, albeit in imperfect ways. I have reviewed a number of them here. No doubt, more are available. Segger's and IAR's JTAG probes do a great job of measuring current consumed, and can correlate that to the executing code. There are a lot of other tools, mostly pretty inexpensive, that will measure current, but don't sync it to the executing code, but these are useful as well. Note well that in selecting these instruments it's critical to consider their bandwidth, as typical IoT systems have quickly-changing energy needs.
The article does mention using an oscilloscope, but in my opinion that is about the worst possible way to monitor current in a low-power IoT device. While sleeping the system might consume microamps or less; when doing wireless comm perhaps a hundred mA. Scopes just don't have the dynamic range to provide any sort of accuracy in the uA to many mA range. There is an exception to this: ee-quipment's Real-Time Current Monitor converts the voltage drop across a resistor from linear to log, overcoming the dynamic range problem. I tried to explain this in the article at that link, but it seems didn't do a good job as I get a lot of email from people who don't "get" the value of measuring the log(current).
So we do have options, and I highly recommend that anyone building something that has to run for a long time from a battery investigate these products.
But there is another issue which the Embedded Systems Letters article vaguely refers to: Predicting a system's energy needs. This is akin to figuring worst-case execution time. That's easy enough to measure - and it is important to measure it! But that's reactive. The code has been written, more or less works, and only then do you discover that the system is too slow or needs too much power. The boss is yelling about shipping and you just found the promised two-year battery life will be three months.
I've chastised compiler vendors for years that they don't give us a clue how fast the code runs. Not even vague guidelines. In the assembly-language days the assembler would print the number of T-states each instruction took. One could, admittedly tediously, get a pretty good idea how long things would take. The vendors tell me they can't do the same for C because of a lot of reasons that just seem to skirt the issue. Even just a sense of WCET would be better than the current situation, where we're coding into a black hole, hoping for divine intervention that things won't be too slow, and when they are, making sometimes random changes to hopefully save a few microseconds.
I have no idea how tools could predict power needs as this is such a complex issue. But until a solution comes along all we can do is hope for the best, take some measurements, and curse our foul luck when the coulomb count is too high.
(For more on ultra-low power design see this.)
Feel free to email me with comments.
Back to Jack's blog index page.
If you'd like to post a comment without logging in, click in the "Name" box under "Or sign up with Disqus" and click on "I'd rather post as a guest."
Recent blog postings:
- Marvelous Magnetic Machines - A cool book about making motors
- Over-Reliance on GPS - It's a great system but is a single point of failure
- Spies in Our Email - Email abuse from our trusted friends
- A Canticle for Leibowitz - One of my favorite books.
- A 72123 beats per minute heart rate - Is it possible?
- Networking Did Not Start With The IoT! - Despite what the marketing folks claim
- In-Circuit Emulators - Does anyone remember ICEs?
- My GP-8E Computer - About my first (working!) computer
- Humility - On The Death of Expertise and what this means for engineering
- On Checklists - Relying on memory is a fool's errand. Effective people use checklists.
- Why Does Software Cost So Much? - An exploration of this nagging question.
- Is the Future All Linux and Raspberry Pi? - Will we stop slinging bits and diddling registers?
- Will Coronavirus Spell the End of Open Offices - How can we continue to work in these sorts of conditions?
- Problems in Ramping Up Ventilator Production - It's not as easy as some think.
- Lessons from a Failure - what we can learn when a car wash goes wrong.
- Life in the Time of Coronavirus - how are you faring?
- Superintelligence - A review of Nick Bostrom's book on AI.
- A Lack of Forethought - Y2K redux
- How Projects Get Out of Control - Think requirements churn is only for software?
- 2019's Most Important Lesson. The 737 Max disasters should teach us one lesson.
- On Retiring - It's not quite that time, but slowing down makes sense. For me.
- On Discipline - The one thing I think many teams need...
- Data Seems to Have No Value - At least, that's the way people treat it.
- Apollo 11 and Navigation - In 1969 the astronauts used a sextant. Some of us still do.
- Definitions Part 2 - More fun definitions of embedded systems terms.
- Definitions - A list of (funny) definitions of embedded systems terms.
- On Meta-Politics - Where has thoughtful discourse gone?
- Millennials and Tools - It seems that many millennials are unable to fix anything.
- Crappy Tech Journalism - The trade press is suffering from so much cost-cutting that it does a poor job of educating engineers.
- Tech and Us - I worry that our technology is more than our human nature can manage.
- On Cataracts - Cataract surgery isn't as awful as it sounds.
- Can AI Replace Firmware - A thought: instead of writing code, is the future training AIs?
- Customer non-Support - How to tick off your customers in one easy lesson.
- Learn to Code in 3 Weeks! - Firmware is not simply about coding.
- We Shoot For The Moon - a new and interesting book about the Apollo moon program.
- On Expert Witness Work - Expert work is fascinating but can be quite the hassle.
- Married To The Team - Working in a team is a lot like marriage.
- Will We Ever Get Quantum Computers - Despite the hype, some feel quantum computing may never be practical.
- Apollo 11, The Movie - A review of a great new movie.
- Goto Considered Necessary - Edsger Dijkstra recants on his seminal paper
- GPS Will Fail - In April GPS will have its own Y2K problem. Unbelievable.
- LIDAR in Cars - Really? - Maybe there are better ideas.
- Why Did You Become an Engineer? - This is the best career ever.
- Software Process Improvement for Firmware - What goes on in an SPI audit?
- 50 Years of Ham Radio - 2019 marks 50 years of ham radio for me.
- Medical Device Lawsuits - They're on the rise, and firmware is part of the problem.
- A retrospective on 2018 - My marketing data for 2018, including web traffic and TEM information.
- Remembering Circuit Theory - Electronics is fun, and reviewing a textbook is pretty interesting.
- R vs D - Too many of us conflate research and development
- Engineer or Scientist? - Which are you? John Q. Public has a hard time telling the difference.
- A New, Low-Tech, Use for Computers - I never would have imagined this use for computers.
- NASA's Lost Software Engineering Lessons - Lessons learned, lessons lost.
- The Cost of Firmware - A Scary Story! - A hallowean story to terrify.
- A Review of First Man, the Movie - The book was great. The movie? Nope.
- A Review of The Overstory - One of the most remarkable novels I've read in a long time.
- What I Learned About Successful Consulting - Lessons learned about successful consulting.
- Low Power Mischief - Ultra-low power systems are trickier to design than most realize.
- Thoughts on Firmware Seminars - Better Firmware Faster resonates with a lot of people.
- On Evil - The Internet has brought the worst out in many.
- My Toothbrush has Modes - What! A lousy toothbrush has a UI?
- Review of SUNBURST and LUMINARY: An Apollo Memoir - A good book about the LM's code.
- Fun With Transmission Lines - Generating a step with no electronics.
- On N-Version Programming - Can we improve reliability through redundancy? Maybe not.
- On USB v. Bench Scopes - USB scopes are nice, but I'll stick with bench models.