One of the top complaints about electronic devices in our modern, mobile society is that their batteries don’t last as long as expected. Human beings have to some degree become addicted to our ability to always be connected and streaming data of one form or another. The increased use of mobile devices has resulted in not only chip manufacturers being forced to rethink how they design microcontrollers but even how embedded system designers build systems. Developers armed with even the latest techniques and technologies can struggle to ensure they have enough battery to operate their product at the expected interval. There are seven tricks that can be followed to help guarantee that an accurate battery life is estimated.
Trick 1 – Traditional battery budget analysis
The first and usually the last trick that an engineer performs to estimate the battery is to create the traditional battery budget. This type of analysis usually involves creating a spreadsheet in which each component in the system is listed. An engineer then goes down through each component, determines minimum, typical and maximum current consumption and records it. With this information in hand, the engineer can now start to estimate what percentage of time the system will be in each of these consumption bins. For example, the microcontroller may only spend 5% of the time in run mode, 25% in a low power stop mode and 70% in a deep sleep mode. An example can be seen in Figure 1 which can also be downloaded from https://beningo.com/138-battery-power-budget/ .
Figure 1 – Example Traditional Battery Budget
Once each component has been analyzed in this way, the results are summed and the system now has minimum, typical and maximum current consumption numbers that can be used to size a battery. Part of the problem with most of these types of analysis is that the numbers are more or less determined based on experience. In other words, they are a complete guess. The engineer guesses the best to their ability but usually there is a level of uneasiness as there may be unexpected leakage currents, a bad estimate on how much the microcontroller will truly consume in addition to any number of other factors. (I once sized a battery for an application and the mechanical team decided they couldn’t get the “look and feel” they desired and instead designed in a different battery with half of the capacity.)
Trick 2 – Software RMA
As part of the software architecture design and analysis a Rate Monotonic Analysis (RMA) should be performed on the software. This analysis will not only identify the different tasks that the software is going to be performing it should give a relative idea of how long each of those tasks will run and the different peripherals involved. From this information, a simple listing of the different tasks and behavior of the microcontroller can be documented in order to improve the traditional battery budgets guestamations (estimated guess). A simple example of this can be found in Figure 2. Note that an RMA will also give the developer a comfort level that all tasks will complete in a deterministic manner with no deadlines being missed.
Figure 2 – Software Task Analysis
Trick 3 – Chip Vendor Tools
One of the foggiest areas when it comes to energy consumption is the microcontroller. There are so many variables concerning how these little guys will consume energy. A review of most vendor datasheets will provide wide ranges of energy consumption based on temperature, voltage, peripheral set, altitude, wind speed, zodiac sign of the developer and so on. There is always the question as to where and how these numbers were obtained and if they are accurate or not.
Even with a little bit of hand waving though, there are some new tools that chip vendors are starting to supply developers that will greatly improve how battery budgets are estimated. One that immediately comes to mind is the ST Microelectronics STMCubeMx. The tool primarily can be used to setup and configure an STM32 microcontroller but the really cool part about it is that it has the ability to simulate current consumption. An example can be seen in Figure 3.
Figure 3 – ST Microelectronics STMCubeMx
The STMCubeMx software allows a developer to enter in different software assumptions and peripheral configurations and it will then generate a profile of energy consumption. For example, a developer can enter Run Mode, clock speed, and duration to name a few parameters. The software can be broken up into steps in the analysis to generate the profile and the average microcontroller energy consumption. There are even common battery types and capacities available.
Trick 4 – Bench top Experiments
As much as any engineer loves modeling and estimation tools, there is always a tension that exists until those assumptions are tested and proven on the bench. This is why it is imperative that early in the design cycle development kits and prototype parts be tested for real world behavior! It doesn’t need to be a clean and polished test but at a minimum it should be able to test basic assumptions about the software, microcontroller energy draw and other components on the system.
One of the nice things about bench testing is that it is a quick and inexpensive way to prove that the low power design is on the right path. If there is an error in a datasheet, an oversight in assumptions, etc, the data taken from the bench can then be used to refine the model. The end result is being one step closer to proving that the intended design is in fact valid.
Trick 5 – Battery life cycle analysis
Creating a model, bench testing and simulating the energy consumption of the system go a long way in nailing down how much battery life an embedded system will get. There are a few different pitfalls though when it comes to the battery itself. The first, which concerns rechargeable batteries, is that each charge/discharge cycle decreases the overall capacity of the battery. The result of this decrease in capacity is that a device when first manufactured may have a battery life of nine hours but six months later may only last six hours. This is a factor that needs to be taken into account when performing the battery capacity estimate.
The second factor that should be kept in mind is the peak current draw from the embedded system. Any battery is rated for a certain number of milliamp hours (mAh) of operation but when the battery is partially discharged, it is possible that peak current can cause the battery voltage to dip into or below brown out. The result is a dead embedded system long before the battery has truly discharged all of its energy.
Trick 6 – Compiler Vendor Tools
Once the battery life analysis has reached the bench testing phase there are some very exciting compiler related tools that can be used to verify system assumptions. These tools have the capability to monitor how much energy the system is using at frequencies of 200 kHz! What is even better is that they allow the current draw of the system and the code that is being executed to be correlated! An example can be seen in Figure 4.
Figure 4 – IAR Workbench and I-Scope System Profile
With such a tool a developer can then review the profile and determine which tasks or functions are drawing the largest amount of energy from the battery and focus low power optimizations in those areas! There are even tool options that will record how much execution time is spent in which functions so that the developer can determine what function or task is being a CPU hog!
Trick 7 – Get a second opinion
It never hurts, especially when a development cycle or product launch is in jeopardy or critical to the survival of a company to get a second set of eyes on the analysis. Whether it is a co-worker or a third party, having another engineer review the estimate and data will result in information, ideas and thoughts that may not have been thought about by the developer. It greatly helps ensure that nothing squeaks through and that when product launch day is near the engineers and team are confident that the system will not run out of juice long before its time. The result is not only a happy boss but happy users who aren’t frustrated with having to recharge their device partway through the day.
