One of the top complaints about electronic devices in our modern, mobile society is the battery life that falls short of expectations. Human beings have to some degree become addicted to our ability to be connected and streaming data at all times in one form or another.

The increased use of mobile devices has not only resulted in chip manufacturers being forced to rethink how they design microcontrollers, but 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 for the anticipated and required duration. There are seven tricks that—if followed—can help to help guarantee an accurate estimation of battery life.

Tip no. 1: Traditional battery budget analysis
The first—and usually the last—trick an engineer performs to estimate the required battery size and anticipated battery life is to create a traditional battery budget. This type of analysis typically involves creating a spreadsheet in which each component in the system is listed. The engineer then goes through each component, determining its minimum, typical, and maximum current consumption, and recording these values.

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 an ultra-low-power deep sleep mode. An example can be seen in figure 1.

Once each component has been analysed 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. This all sounds fairly straightforward, but the problem with this type of analysis is that many of the numbers used are more-or-less determined based on experience. (This is a kind way of saying that they are a complete guess.)

The engineers make guesses to the best of their ability, but usually there remains a level of uneasiness, since there may be unexpected leakage currents, a bad estimate on how much the microcontroller will truly consume, and any number of other factors. (I once sized a battery for an application, after which the mechanical team decided they couldn't get the "look and feel" they desired, so they instead designed in a different battery with half of the capacity.)

Tip no. 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, but it should also include a relative idea about how long each of those tasks will run and the different peripherals involved.

Figure 2: Example of a software task analysis. (Click on image to enlarge)

From this information, a simple listing of the different tasks and behaviour of the microcontroller can be documented in order to improve the traditional battery budget "guestimations." A simple example of this can be seen in figure 2. Note that an RMA will also give the developer a comfort level in that all tasks will complete in a deterministic manner, with no deadlines being missed.

Tip no. 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, birth sign of the developer, and so forth. 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 to developers that will greatly improve how battery budgets are estimated. One that immediately comes to mind is STMCubeMx from STMicroelectronics. This tool is primarily intended to be used to set up 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.

The STMCubeMx software allows a developer to enter in different software assumptions and peripheral configurations, after which it will generate a profile of energy consumption. For example, a developer can enter the run mode, clock speed, and duration, to name just 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 for consideration in this analysis.

Tip no. 4: Bench-top experiments
As much as any engineer loves modelling 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—as early as possible in the design cycle—development kits and prototype parts be tested for real-world behaviour! This doesn't need to be a clean and polished test, but—at a minimum—it should be able to verify basic assumptions about the software, microcontroller energy draw, and other elements of the system.

One of the nice things about bench testing is that it is a quick and inexpensive way to prove that the power portion of the design is on the right path. If there is an error in a datasheet, an oversight in assumptions, etc., then the data taken from the bench can be used to refine the model. The end result is to bring us one step closer to proving that the intended design is, in fact, valid.

Tip no. 5: Battery life-cycle analysis
Creating a model, bench testing, and simulating the energy consumption of the system go a long way with regard to nailing down how much battery life an embedded system can expect. There are a few additional potential pitfalls, however, 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 that has a battery life of nine hours when first manufactured may only last six hours a few months later. This is certainly 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 its brown out value. The result will be a dead embedded system long before the battery has truly discharged all of its energy.

Tip no. 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 200kHz! 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.

Using such a tool, a developer can then review the profile, determine which tasks or functions are drawing the largest amount of energy from the battery, and focus any low-power optimisations in these areas. There are even tool options that will record how much execution time is spent in which functions, so that the developer can determine which functions and/or tasks are CPU hogs!

Tip no. 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 in on the analysis. Whether the person is a coworker or a third party, having another engineer review the estimate and supporting data will result in information and ideas that may not have been considered by the original developer. This greatly helps to ensure that nothing "falls through the cracks" and that—when the product launch day draws near—the members of the design team are confident that the system will not run out of juice before its time. The result is not only a happy boss, but happy users who aren't frustrated by having to recharge their devices partway through the day.

About the author
Jacob Beningo is an embedded systems consultant and lecturer who specialises in the design of resource-constrained and low-energy devices. He works with companies to decrease costs and time to market while maintaining a quality and robust product. He is an avid tweeter, a tip-and-trick guru, a home brew connoisseur, and a fan of pineapple!