Low-Power Design

Low-Power Design: Understanding Your Current Budget

Battery-life estimates often look great on paper and then disappoint in the field. The gap usually comes from real operating conditions: duty cycle, radio behavior, regulator modes, temperature, leakage paths, and I/O states that differ from the datasheet test setup.

Low-power design requires accounting for where every microamp goes, including currents that only appear in certain modes or board-level conditions. Picking low-power parts is a starting point, not the whole story. Sleep-mode numbers are typically measured under specific configurations, and small details like pull-ups, floating pins, and peripheral clocks can dominate average current.

This guide focuses on a practical workflow: build a current budget, validate it with measurements, and iterate on the biggest contributors until you hit the lifetime you need.

The Two Power Equations You Need to Know

Dynamic power: $P_{dynamic} = C \cdot V^2 \cdot f \cdot \alpha$. Notice voltage is squared. Dropping from 3.3V to 1.8V cuts dynamic power by 70%. This is why voltage scaling is so effective.

Static power: $P_{static} = I_{leak} \cdot V_{dd}$. As a rough rule, leakage current roughly doubles every 10°C, though the exact factor depends on the dominant leakage mechanism (subthreshold versus gate) and the process node, and at deep submicron the slope can be flatter. That device that sleeps fine at room temperature? Put it in a hot enclosure and watch the battery drain.

Start With The Battery Math

A CR2032 coin cell has about 225mAh. At 10µA average, that's roughly 2.5 years. At 100µA, it's about 3 months. This basic calculation should happen on day one of your project, not when prototypes are failing.

Don't forget regulator efficiency. Your switching converter might be 85% efficient at full load but 50% efficient at light loads, where you'll actually operate. Those losses come straight out of your battery budget.

Power Domains: Shut Off What You Don't Need

Modern MCUs let you power down sections independently. That USB peripheral you're not using? It's still drawing current unless you explicitly disable its power domain. Same for analog comparators, DACs, and communication interfaces.

Clock gating stops switching power; power gating eliminates leakage too. Know which peripherals support which, and use them aggressively.

Voltage Scaling: The Quadratic Win

Remember that V² in the power equation? Drop your voltage by half and you cut dynamic power by 75%. Many MCUs let you run at reduced voltage when you don't need full speed. Use it.

The catch: on any given part, lower voltage means slower switching, and the datasheet caps the maximum clock at each supply level. For most embedded tasks that ceiling doesn't matter. A slower clock at lower voltage often beats running fast and sleeping longer.

Sleep Modes: Pick The Right One

Your MCU probably has 4-8 different sleep modes. The deepest one (500nA!) takes 5ms to wake and loses RAM. The lightest one (50µA) wakes instantly but barely saves power. Wrong choice kills your battery either way.

Calculate the break-even point. If your sleep period is shorter than the energy cost of entering/exiting deep sleep, you're better off in a lighter mode. For a device sampling at 100Hz, deep sleep might actually waste power.

Peripherals: The Hidden Power Hogs

That ADC you left enabled "just in case"? It's burning milliamps. The comparator monitoring a signal that changes once per hour? Still drawing 50µA continuously. Audit every peripheral.

Analog peripherals are particularly tricky. A precision voltage reference needs 500µs to settle after power-on. If you're sampling every 100ms, keep it running. If you're sampling hourly, power it down. Know the settling times and do the math.

Clocking: Faster Isn't Always Better

Running faster so you can sleep longer sounds smart, but it's not always optimal. Higher frequencies burn more dynamic power, and the wake/sleep transitions have overhead.

Most MCUs have multiple clock sources: a 32.768 kHz crystal for ultra-low-power timekeeping, internal RC oscillators for quick wake-up, and PLLs for when you need speed. The energy cost of switching sources and waiting for PLL lock matters: sometimes it's cheaper to run slow continuously than to wake fast and sleep.

Memory: Where Leakage Hides

SRAM leaks current even when you're not accessing it because every cell holds always-powered transistors that contribute subthreshold and gate leakage at all times. The dominant component in modern processes is subthreshold current through the off-state transistors of each cell, with gate leakage adding its share through all six transistors of the standard 6T topology (and a much bigger share on older nodes without high-k gate dielectrics). More RAM means more leakage. Some MCUs let you power down RAM banks you're not using during sleep, and ULP-targeted memory cells (8T or 10T topologies) can end up leaking less than 6T despite the extra transistors, because the decoupled read port lets designers use weaker, higher-threshold storage transistors and lower retention voltages.

Data organization matters too. Cache-friendly access patterns (sequential, localized) use less energy than random access, and the savings show up in average current as well as throughput.

Your Regulator's Quiescent Current

Linear regulators waste power as heat: (Vin - Vout) × Iload goes straight to ground. Switching regulators are more efficient but draw quiescent current even at zero load. For a system sleeping at 1µA, a regulator with 10µA quiescent current dominates your power budget.

Modern PMICs handle this with automatic mode switching: efficient switching at high loads, ultra-low-quiescent linear mode when sleeping. Check the datasheet curves at your actual load current, not just peak efficiency.

Energy Harvesting: Intermittent By Nature

Solar cells, piezoelectrics, and thermoelectrics provide power that varies wildly, and sometimes drops to zero. Your system needs to handle this gracefully: store energy during good times, throttle during bad times, and cold-start from completely dead.

MPPT (maximum power point tracking) extracts the most energy from your source. Supercapacitors or small batteries buffer the variability. The key is matching your average power consumption to your average harvested power, with margin for bad weather or dark periods.

Software Affects Power

Efficient code means less time in active modes. But the trade-offs aren't obvious. A more complex algorithm that compresses data before radio transmission might save more energy than the extra CPU cycles cost, because radio dominates power budgets.

Interrupt-driven designs let the CPU sleep between events. But if interrupts fire too frequently, you never reach deep sleep. Sometimes polling is actually more efficient for high-frequency events. Do the math for your specific case.

Radio: The Biggest Power Hog

In a wireless device, the radio typically dominates power consumption. A BLE radio might draw 10mA for a few milliseconds to send a packet. That's more energy than your MCU uses in seconds of sleep.

Minimize radio time. Send less data, send it less often, and shut down the radio completely between transmissions. Protocols like LoRaWAN and Zigbee are designed for this. If you need always-on connectivity, expect to sacrifice battery life.

Measuring Real Power

Simulation rarely gets power consumption right. You need to measure actual silicon. But measuring microamps with high dynamic range is tricky. You need specialized equipment that can track both 10mA active peaks and 500nA sleep current.

Test all states and transitions. The current during mode switching often surprises people. And test multiple units: process variation can cause 2-3x spread in leakage current between devices.

If you are developing a battery-powered product, I can design the hardware and firmware together to hit your power budget. I have designed ultra-low-power systems that reach multi-year battery life.

Sometimes the biggest wins come from unexpected places: a GPIO configuration, a regulator in the wrong mode, or a peripheral that's not fully disabled. Get in touch if you would like your product designed to its power budget from the start.

Low-power optimization spans hardware and firmware. These techniques are applied throughout my embedded firmware development services, helping battery-powered products achieve their target runtime.