Confessions of a low power addict
I’ll admit it. I’m a low-power addict. I enjoy wringing every unnecessary milliamp out of my designs, or at least as many as budget and schedule permit. I’ve gotten pretty good at it.
It all started several years ago on a medical device project that started out just like any other. Requirements were dictated, electrical components were selected, battery budgets analyzed, and eventually schematics and a PCB were developed. The embedded software was architected and implemented. The PCBs arrived and the first tests of the product ensued.
That's when we discovered our power problem. The device needed to operate for 14 hours before being recharged. The best initial tests revealed that it only lasted about 4.5.
What went wrong? It turned out that the mechanical design team didn't like the battery's size. It was too big for their Star Trek-era design concept. Quietly, and against the few objections they received, they had changed it -- without consulting the electrical team.
The beauty of it all was that all aspects of this project were being done in parallel, which meant that everything, including production tools, all showed up at once. Once we got to the product testing stage, that was it; there was no going back and no budget to change the hardware. We were stuck with the mismatch. The 9.5 hour operational gap would have to be closed in software.
Was it even possible? What can possibly be done in software to squeeze enough battery life out of the device to last 3 times as long?
It turns out that a software developer has far more control over how energy is used in an embedded system than one might think. Energy savings start with the selection of proper software architecture. Round robin or polling methodologies are inefficient and waste energy. They need to be the first things that go. Interrupt driven techniques need to replace them.
Using an event-driven architecture, though, will only save energy if a low power mode is used during idle processor time. Modern day processors have a plethora of low power modes available, but they are not as simple or easy to use as one might think. They are a complex labyrinth of state transitions, wake events, and recovery times. Choose poorly and that could spell the end of any real-time behavior in your system.
Software architecture and low power modes are just the tip of the iceberg! Silicon vendors have been busy racing to see who can design in the lowest energy states. Implementing advanced techniques such as clock scaling, sleep-on-exit, and autonomous peripherals they can watch the energy usage drop. After a while, it starts to become addicting. How low-energy can a design go? What if DMA is used? Can compiler optimizations help?
Using these mentioned techniques as well as others, we were ultimately able to extend the product's 4.5 hour battery life to 14.5 hours! But this heady success was only the beginning of my fascination with low power. Rapidly advancing technologies and the demand for battery-operated sensor devices for the Internet of Things have since only added fuel to that fire. Low power design isn’t as simple as it once was, but understanding subtle details in the architecture and the implementation can be the difference between a successful or failed product.
So, I'm hooked. If low power design techniques are also of interest to you, whether it’s for your next project or simply something you find fascinating, consider attending my "Squeezing the Most out of Battery Life using the ARM Cortex-M Processor" presentation on Thursday May 6th at the Embedded Systems Conference in Boston. This 40-minute session will not only explore the questions I asked above, it will also review the fundamentals of low power design and measurement, energy profiles, and battery budgets along with providing real-world examples and sample code. Come and get your low-power "fix."
Jacob Beningo is a Certified Software Development Professional (CSDP) whose expertise is in embedded software. He works with companies to decrease costs and time to market while maintaining a quality and robust product. Feel free to contact him at firstname.lastname@example.org, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.
Join over 2,000 technical professionals and embedded systems hardware, software, and firmware developers at ESC Boston May 6-7, 2015 and learn about the latest techniques and tips for reducing time, cost, and complexity in the embedded development process.
Passes for the ESC Boston 2015 Technical Conference are available at the conference’s official site with discounted advance pricing until May 1, 2015. The Embedded Systems Conference and EDN are owned by UBM Canon.