Embedded systems
Low-power design starts with hardware and firmware together
Creayzo Embedded Labs 4 min read
A low sleep-current specification is useful, but it is only one part of a battery-powered product. Sensors, regulators, wireless activity, and firmware timing all contribute to the energy used in normal operation. A useful power budget begins with the complete system and its expected duty cycle.
Describe the operating cycle
List what the product does during a representative cycle: wake up, read sensors, process data, communicate, and return to a lower-power state. Estimate how long each activity lasts and identify events that can change the cycle.
An average-current estimate can be built by multiplying each state’s current by its fraction of the total cycle and summing the results. Use consistent units and treat the result as an estimate to validate on hardware, rather than a guaranteed battery-life figure.
Measure the whole board
Measure current at the product power input, not just at the microcontroller supply. Account for regulators, indicator LEDs, pull-ups, sensors, and communication modules. Development-board measurements can include circuitry that will not be present in the final product.
Capture both quiet periods and brief bursts. A measurement setup that only reports a slow average may hide the timing and magnitude of individual events.
- Measure active, idle, communication, and sleep states.
- Separate intended loads from debug and development circuitry.
- Repeat measurements with representative peripherals connected.
Choose sleep modes around the application
Lower-power modes involve tradeoffs in wake-up time, retained state, and available peripherals. The supported modes and wake sources differ between MCU families; consult the documentation for the exact device rather than assuming that a setting transfers unchanged between products.
On STM32 devices, the power-management documentation is a starting point for comparing these tradeoffs. Validate the chosen wake source, clock recovery, and peripheral initialization as part of normal firmware testing.
Make the power budget part of design reviews
Hardware and firmware decisions should be reviewed together. Consider whether a peripheral needs power continuously, how often wireless data must be transmitted, and whether the application can combine work into fewer wake periods.
Re-measure after design or firmware changes and record the test conditions. Battery chemistry, temperature, conversion losses, and the product workload affect real operating life. A documented measurement is a stronger basis for product planning than a single best-case number.