If your product runs on a battery, your firmware is either the reason it lasts 6 months — or the reason it dies in 6 hours.
Low-power design isn’t just about the hardware you pick.
It’s about how every part of your firmware is written — how often it wakes, what it does when it’s awake, how peripherals behave during sleep, and how tasks are prioritized across cycles.
At Veebar, we specialize in building embedded systems that actually last in the field, without cheating on performance. Here’s exactly how we approach it.
1. Understand Your Power Budget Before You Write a Line of Code
We start every project with a power model, not a feature list.
We calculate:
- Active mode draw (based on MCU clock, enabled peripherals, voltage rail)
- Sleep mode draw (MCU + PMIC + leakage from sensors/pull-ups)
- Wake event frequency (based on user interaction, sensor polling, radio activity)
- Battery capacity (typical vs actual under load and temp)
- Total cycle consumption over time
Example:
ESP32-C3, polling temperature every 10 minutes via I2C, BLE connection on-demand → < 25 µAh per cycle, avg current draw ~50 µA → 3–6 months on 500 mAh LiPo
No power model = no realistic runtime targets.
2. Wake-Up Architecture: Event-Driven, Not Loop-Driven
We engineer firmware around event interrupts and deferred task execution.
Instead of polling or tight loops, we structure:
- Wake on external interrupt (e.g. motion, GPIO, button press)
- Wake on RTC timer (e.g. deep sleep every 10 minutes for sample & transmit)
- Interrupt vector table routing for ultra-fast ISR handling
- Avoiding spurious wake sources — e.g., disable UART wake unless debugging
- Peripheral disable/shutdown immediately after use (not just sleep mode)
We select MCUs with ultra-low sleep current + flexible interrupt sources — STM32L series, nRF52840, etc.
3. Peripheral Power Management: GPIO-Controlled Rails and Sensor Gating
Every sensor, LED, or radio module that’s “idle” might still be drawing µAs.
Our hardware + firmware stack includes:
- GPIO-controlled load switches (e.g. TPS22910 or N-channel FETs) to fully disconnect sensors
- Pin-multiplexed SPI/I2C devices — disable clock and data lines when not in use
- Use of
HAL_PWREx_DisablePullUpPullDownConfig()(on STM32) to kill hidden leakage - ADC shutdown and GPIO analog input switching to digital low-z when inactive
- EEPROM write coalescing — write only every X changes to reduce active flash time
We measure leakage current at µA resolution during early prototyping — not just on final hardware.
4. Clock Scaling + Peripheral Throttling
MCUs don’t need to run at 64 MHz to blink an LED or sample once.
We implement:
- Dynamic clock scaling (e.g. drop core clock to 4 MHz during UI transitions or idle state)
- Disable PLL when not using USB or high-speed serial
- Use of low-speed internal oscillators (e.g. 32 kHz LSI) for RTC and WDT
- Throttle peripheral bandwidth — e.g., reduce I2C baud rate when time-sensitive reads not needed
The goal is to match clock speed to workload, not “go fast always.”
5. BLE & Radio Stack Optimization
BLE can destroy your battery if misused.
We manage:
- Advertising intervals (1000ms+ for low-demand)
- Connection parameters (e.g. slave latency to avoid constant wake-ups)
- Use of queued GATT updates instead of real-time streaming
- Auto-disconnect after inactivity
- Radio stack sleep enablement (depending on SDK — Nordic SoftDevice, ESP-IDF, Zephyr)
We benchmark energy per packet transfer vs. payload size — because a 1-second ping can use 5× the power of a well-batched 100 ms burst.
6. OTA Update Safety: Sleep-Aware + Flash-Safe
OTA systems often forget: writing flash consumes power and locks the CPU.
We design:
- OTA processes that buffer image in RAM or external flash, not MCU Flash during critical operation
- Wake-staged OTA: download in low-power bursts, apply only at next scheduled wake
- Firmware bank switch designed to fall back to known good image if boot fails after update
- Boot-time CRC validation — if CRC fails, revert via hardware-defined memory map
Field reliability beats pushing nightly builds.
7. Real Testing: Power Benchmarks, Battery Profiles, and Wake Analytics
Before we call it “low power,” we:
- Measure system sleep draw using µCurrent Gold + oscilloscope trigger
- Benchmark active current per task and per peripheral
- Profile battery under actual temperature, load, and usage curve
- Build “wake analytics” — a UART/debug log of how often and why the device woke up
- Cross-compare this against our power model from Step 1
Low-power engineering is science. Not guesswork.
This Is What We Ship
We don’t just “optimize” for low power.
We architect it — from schematic to firmware to battery analytics.
If you’re building a sensor, wearable, or smart device that must survive real-world cycles and sleep like a pro, we can build the system that lasts.
📩 Contact us to speak directly with our embedded engineering team. Bring your use case, and we’ll bring the design that runs for months — not hours.
