Same chip, one week or one year

A product that runs a week on a battery and a product that runs a year can be built on exactly the same microcontroller. The difference is almost never the silicon - it is the firmware, and specifically how well it uses the part's sleep modes. Modern microcontrollers draw a few milliamps while running and drop to tens of microamps, or even a single-digit microamp, in their deepest low-power states. When a device is genuinely active only a fraction of a percent of the time, battery life is decided entirely by how low you managed to get during the other ninety-nine-plus percent.

Which is why an energy budget should exist before the first line of firmware is written.

What each sleep mode actually turns off

Vendor names differ, but the hierarchy is nearly always the same:

  • Sleep (or idle). The core halts; peripherals and clocks keep running. Modest saving, essentially instant wake-up.
  • Stop. Most clocks are gated, RAM contents are retained, and wake-up takes tens of microseconds. This is the workhorse mode for most battery products.
  • Standby / shutdown. Almost everything is off and consumption falls to a few microamps, but the device wakes as if from reset and loses RAM state unless it was saved to a retained region.

Choosing among them is always a three-way tradeoff, and these are the numbers to pull from the datasheet before you commit:

  • Deep-mode current - the parameter that sets battery life for a mostly-waiting device.
  • Wake-up latency - critical when the product must respond to an external event within milliseconds.
  • State retention - whether run-time variables and the real-time clock survive.
  • Wake sources - which pins, timers, or peripherals can actually bring the part back. This constraint often decides the mode for you.

Architect around events, not around a loop

The most common low-power mistake is firmware that spins in an endless loop polling sensors. An efficient architecture works the opposite way: the controller sleeps, and something external wakes it - a pin interrupt, a real-time clock alarm, or a sensor that detects its own threshold crossing and asserts a line. Active time collapses to the minimum that physics requires.

Two details matter more than they look:

  • One stray periodic task can erase the whole saving. A background job that wakes every ten milliseconds to check a flag will dominate average current no matter how deep your sleep mode is. Audit every timer.
  • The architecture choice constrains the technique. A scheduler with a periodic tick has to be configured for tickless operation, or it will never let the part sleep deeply. Decide this alongside the question in RTOS vs bare metal, not afterwards.

In our experience across connected-product projects, moving from polled to fully event-driven firmware moves average current by an order of magnitude - far more than any code-level micro-optimization.

What is really draining the battery is usually not the MCU

With the controller asleep at a few microamps, the rest of the board becomes the story. Frequent culprits:

  • A linear regulator with high quiescent current - it can easily consume more than the sleeping processor. Regulator selection is a low-power decision.
  • An indicator LED left on, or a pull-up resistor tied to a pin that is being driven low.
  • Sensors never commanded into their own standby state, or held awake by an I2C bus that never releases.
  • Leakage through unconfigured GPIO, floating inputs, and external circuitry that back-feeds the rail.
  • The radio. Every transmission costs energy, so reporting frequency is an engineering decision, not a marketing one.

That last point deserves emphasis. Radio choice and reporting cadence typically dominate the energy budget of a connected sensor, so pick the protocol for the duty cycle you actually need - LoRa and LoRaWAN in a product covers one end of that spectrum. If your device does local inference to avoid transmitting raw data, the energy tradeoff of computing versus sending is discussed in TinyML on microcontrollers.

Do the duty-cycle math early

Estimating life is simple weighted averaging. Take a sensor that wakes once a minute, runs twenty milliseconds at eight milliamps, and sleeps the rest of the time at five microamps. The active portion contributes roughly three microamps averaged over the minute, so total average draw is around eight microamps. A lithium primary cell with a capacity of a bit over a thousand milliamp-hours would, in theory, last well beyond a year - before you subtract self-discharge, conversion losses, and temperature derating.

That calculation takes minutes and immediately tells you whether the marketing target is realistic. It also shows where the leverage is: in most designs, halving the reporting interval changes the answer more than any firmware optimization. Once the numbers are roughly right, the results feed straight into battery pack design and into microcontroller selection - which is why all three should be done together, not in sequence.

Measure, do not guess

You cannot optimize consumption you have not measured. A current meter with wide dynamic range shows the full profile over time and reveals spikes nobody knew about - a radio retry storm, a sensor that takes far longer to settle than the datasheet suggests, a bootloader that spends a hundred milliseconds at full current on every wake. From the measured profile you compute average draw, divide capacity by it, and get an estimated life. If the number misses the target, change the sample rate or the sleep mode and measure again.

Do this on real hardware, at the temperature extremes the product will see, and with the radio actually connected to a network. Bench numbers taken with the radio disabled are the most common source of battery-life claims that collapse in the field. The cost implications of this work are outlined in firmware development cost, and the wider discipline is mapped on our embedded software hub.

Find out if your battery-life target is achievable

Projects House builds an energy budget at the start of every battery-powered product, then verifies it with measurement on real hardware rather than spreadsheets alone. If you want to know whether your battery-life target is realistic before you commit to a cell size and an enclosure, tell us about the product through our contact form and we will work through the numbers with you.