Low-power coding for embedded systems is about helping a device finish useful work while spending as much time as possible in an efficient idle or sleep state. This matters for sensors, wearables, remote monitors and other devices that may need to run for months or years on a battery.
The biggest gains rarely come from shortening a few lines of code. They come from reducing wake-ups, avoiding unnecessary polling, batching communication and switching off hardware that is not being used.
This guide focuses on firmware and embedded devices. For general application and web-development principles, start with energy-efficient code for beginners. To compare implementations yourself, use the green code experiments.
What Makes Embedded Software Use Power?
An embedded system may draw energy through its processor, memory, sensors, display, storage and communication radios. The exact balance depends on the hardware and workload. A wireless transmission may dominate one design, while a frequently refreshed display or continuously sampled sensor dominates another.
Power is the rate at which a device uses energy. Battery life depends on energy used over time. This is why a brief burst of work followed by a long sleep can be more efficient than keeping a slower processor awake continuously.
1. Replace Polling With Events
Polling repeatedly asks whether something has changed. A loop that checks a sensor or flag thousands of times can keep the processor active even when there is nothing to do.
Where the platform allows it, use interrupts, callbacks or event notifications. The processor can sleep until the event occurs. Keep interrupt handlers short, record what happened and let the main task perform longer work.
2. Make Sleep the Default State
Many microcontrollers provide several power states, from light idle modes to deep sleep. Deeper states generally save more energy but take longer to enter and leave, and they may not retain every peripheral or memory region.
Choose the deepest state that still meets the next deadline. The Zephyr power-management documentation shows how an operating system can select system and device power states. The principle applies beyond Zephyr: make active time intentional and return to sleep promptly.
3. Batch Sensor Readings and Network Traffic
Starting a radio, storage device or sensor may have a fixed energy cost. Ten tiny operations spread across ten wake-ups can therefore use more energy than one well-sized batch.
- Collect several readings before writing to flash.
- Send multiple records in one network session when latency allows.
- Combine timers that have similar deadlines.
- Avoid waking a display or radio for information the user will not see.
Batch size is a trade-off. Larger batches may increase memory use or delay urgent data. Test the smallest number of wake-ups that still satisfies reliability and response requirements.
4. Reduce Sampling Without Losing the Signal
Sampling faster than the application needs wastes processor time, memory and communication energy. Define the real resolution and response-time requirement before choosing a sensor rate.
Adaptive sampling can help. A monitor might sample slowly while readings are stable, then increase the rate when it detects a meaningful change. Add sensible upper and lower bounds so the system remains predictable.
5. Switch Peripherals Off Properly
A processor can enter sleep while a peripheral continues drawing power. Radios, analogue converters, displays and external sensors may each need an explicit low-power state.
Track ownership carefully. Before suspending a device, confirm that no task still needs it. On wake, restore only the state that is required. Zephyr separates system power management from device power management, which is a useful mental model even when you use another platform.
6. Choose Algorithms for the Real Workload
An inefficient algorithm keeps the processor awake for longer. First remove repeated calculations, unnecessary conversions and avoidable copying. Then consider whether a different data structure or algorithm reduces the total work.
Do not optimise blindly. A faster approach may use more memory, and extra memory may increase hardware requirements. Measure the whole device under a realistic workload rather than assuming that runtime alone tells the complete story.
7. Treat Memory and Storage as Energy Costs
Frequent flash writes consume energy and can shorten storage life. Buffering can reduce write operations, but important data may be lost if power fails before the buffer is committed.
Use compact data types when they genuinely fit the range, avoid retaining data that can be regenerated cheaply, and design a clear persistence policy. Reliability comes first for safety-critical or irreplaceable information.
8. Measure on the Target Device
Desktop benchmarks cannot reproduce every feature of a microcontroller, radio or battery. Test on the actual hardware with the real firmware configuration.
- Measure current in active, idle and sleep states.
- Record how often the device wakes and how long it stays awake.
- Test typical, busy and failure conditions.
- Include radio retries, weak signals and disconnected states.
- Repeat tests at relevant temperatures and battery levels.
A current probe or power analyser gives better evidence than a software estimate alone. If specialised equipment is unavailable, start with repeatable battery-run tests and platform telemetry, then document the limitations.
A Practical Low-Power Review
- What wakes the processor?
- Can polling become an event?
- Which peripherals remain powered while idle?
- Can network, sensor or storage operations be batched?
- Does the sampling rate match a real requirement?
- What happens during errors, retries and lost connections?
- Have changes been measured on the target hardware?
The Main Principle
Low-power firmware does useful work efficiently, keeps hardware active only when needed and returns the system to an appropriate sleep state. Start with wake-ups and peripherals because they often reveal larger savings than small code-level tweaks.
For the wider environmental context, read the guide to green software engineering.