Developing Firmware for Low Power Devices
In the ever expanding world of “Internet of Things” (IOT), battery powered gadgets and devices are becoming more prevalent in average daily life. The battery life on these devices directly impacts customers and can be a major factor for the success of a product. Here at Latch, many of our smart lock products fall into this category of battery powered IOT devices. These devices have their own embedded software on them, often referred to as firmware. Developing firmware to optimize battery life and power consumption is a big part of what we do here at Latch. We are always learning and finding new ways to improve battery life while still meeting the needs of our customers.
Power consumption starts with the hardware. The electronics design and component selection of a product is extremely important for power consumption. The hardware serves as the baseline of power consumption possibilities. However once the hardware design is complete, it’s up to the firmware to make sure these devices are running as efficiently as possible to maximize battery life while still meeting the product requirements. Battery life needs to be taken into consideration in the earliest stages of firmware development.
Understanding Power Consumption
When looking at power consumption, it’s important to understand the basics with regards to measuring power consumption on the device itself. At a basic level, batteries have a power capacity that is commonly measured in mAh. This stands for milliamp hours. If a battery is rated for 1000 mAh, it means roughly that the battery can supply 1000 mA for 1 hour before being drained. For comparing batteries of the same type, it’s generally safe to assume a higher mAh rating means it has a longer battery life capacity.
What does this mean for measuring power consumption on a device? Put simply, you can directly measure the relative power a device is consuming, by measuring the amount of current being drawn from the batteries. Power in an electronic device is measured in watts (or typically milliwatts in low power devices), with the equation: P = I*V. I is the current and V is the voltage, these multiplied together give the power P. Batteries supply a semi constant voltage to the device, while the current will fluctuate based on how the device is operating. Generally speaking, the more current being drawn, more power is being consumed.
There are many ways to measure current, from a standard digital multimeter for instantaneous measurement, to more complex power analyzers for recording extremely accurate data over time. You can work with hardware engineers to find what fits the needs of the specific project.
Create a Power Budget
When bringing up new electronics, it’s an extremely useful exercise to measure the current/power being consumed by each unique component. This can be done as part of the board bring-up process. This up front work can paint a clear picture as to where a device’s power budget is being spent. Ideally, the sum of power being consumed by each component should be equivalent to the total power being pulled out of the batteries. With these measurements, understanding the main power consumers on the device becomes obvious. It also has the added benefit of detecting any hardware issues causing unexpected power loss early on in a project.
It’s important to take into account how the device will operate in the field when calculating total budget. For example, is there an idle state the device will be operating most of the time? Are there high power actions that get triggered on certain events and how often can they reasonably be expected to occur? The expected use case of the product needs to be understood and taken into account when coming up with a breakdown of the power budget. Components that need to be on 100% of the time will obviously be much more impactful to the power budget than components that only need to be turned on when needed. By knowing the power budget breakdown, it’s easy to see where to focus firmware development in order to have the largest impact on improving battery life. See image below for a general example of what a power budget might look like.
Firmware Optimization
Firmware controls the hardware on electronic devices at a very low level. To optimize firmware for power consumption, it’s important to consider how the device will operate. These early design decisions can have large implications on how much power the device will consume. In a typical application, firmware exists on a Microcontroller (MCU), which is essentially a tiny computer chip with some extra peripherals. The MCU like every other electronic component is going to consume power. There are a number of different things to look at on the MCU itself to reduce power consumption.
One of the most important things you can do to reduce power consumption of an MCU is put it into a low power mode. MCUs that are specifically designed for low power applications will typically have one or more unique low power modes they can be put into. Once in a low power state, the MCU will be consuming less power and can be put back into its normal operating state in a number of different ways depending on the application. It could wake up from an external interrupt, or off a timer just to name a few examples. One of the goals from the very beginning of firmware development on a battery powered device, should be to put the MCU into a low power state for as long as possible. All information regarding the low power states will be available in the MCU datasheet or reference manual. Make sure to understand the different implications of the low power states and if it fits the application. For example, is RAM memory preserved, and can peripherals still operate? In order to maximize time an MCU is spent in a low-power state, it requires careful thought and planning on how the firmware is architected. This should be designed for early on in a project to make sure battery life goals are met.
Another consideration is make sure all peripherals and subsystems in the MCU are powered off when they are not in use. It’s a simple concept, but it’s worth verifying that everything is being shut down properly. The data sheet or user manual of a microcontroller will contain all the information on how to do this. It’s very important to have a good grasp on all details of how the MCU operates, so it’s good practice to read these documents in general. Some common peripherals include, Analog to Digital Converter (ADC), Pulse Width Modulation (PWM), Dynamic Memory Access (DMA), Timers, and serial protocols controllers such as UART, I2C, or SPI. Similar to switching off a light when you leave a room, any unused peripherals should be explicitly turned off when not in use. In addition, it’s important to put thought into the design of how these peripherals will operate. Upfront thought and design needs to go into the architecture of the firmware so peripherals can be powered down when not in use. One example would be to consider interrupt driven events over polling events whenever possible with regards to peripherals to avoid unnecessary usage.
It’s also important to look at how the GPIOs are configured on the MCU. GPIO stands for “General Purpose Input Output” and refers to the pins on a microcontroller that are used as digital inputs, outputs, or not used at all (floating). Modern MCUs contain a number of different options on how pins can be configured. Some common options are, choosing if a pin is an input or output, configuring the pin as open-drain configuration or push-pull configuration, or enabling internal pull-ups/pull-downs. I will not get into specifics of these settings, for a great overview check out this article by the folks over at Embedded Artistry. It is worth working with hardware engineers to verify all pins are being configured as they are meant to be. Configuring GPIOs incorrectly can cause significant power drain on a device.
It’s also necessary to consider external components connected to the MCU. These components could be sensors, external memory, radios, motors, or any other possible electronic component. Although you cannot write firmware on external components directly, the MCU will have firmware that controls how it will interact with these components and will impact overall power consumption.
The first thing to do when bringing up an external component, is read any relevant datasheet or documentation to fully understand how an external component is meant to be operated. This is an underrated task that can pay off dividends. The Firmware engineer should understand the component inside and out. It’s helpful to look for ways to put a component to sleep or low power mode when not in use. Similar to the MCU, external components should be put in a low power mode or turned off as much as possible.
It’s also important to understand all of a component’s configuration settings and their corresponding impacts on power consumption and user experience. Oftentimes, there are going to be tradeoffs that need to be considered. Adjusting a particular setting that improves battery life might also result in the product not performing as well from an end user’s perspective. All configuration options need to be understood to find the best balance. For example, an external Bluetooth radio might have an advertising frequency and transmit power settings that can be adjusted. These settings will directly impact power consumed by the radio, but they will also impact the radio’s range and connection latency for end users. It’s very common for the goals of user experience and power consumption to be conflicting. Part of the developer’s job is to find an optimal balance. Knowing the configuration settings that directly impact power consumption early on for a component is extremely helpful to optimize for overall battery life.
Summary
These topics are just a few things to keep in mind when developing firmware on battery powered devices. This is a vast topic with plenty of additional information out there outside of this post and it’s absolutely worth it to explore and learn more. Here at Latch we are always learning new ways to improve power consumption in our devices in order to give our customers the best possible experience. We will continue to get better and stay tuned for more great engineering content from Latch!
