Low-Power Embedded Design
Low-power embedded design is the practice of making a small computer perform its sensing, control, or communication work while using as little energy as its requirements allow. It treats the processor, peripherals, circuit board, power supply, and firmware as one energy system.
itComputer architecture and hardware | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Low-Power Embedded Design
A small computer that runs on a battery has a peculiar accounting problem. It may spend most of its day waiting, yet the few moments when it wakes can consume much of the day's energy. Low-power embedded design means arranging the whole device so its useful work costs less energy while it still responds on time. The word "whole" matters: the processor does not get to file a separate electricity bill from the sensor, radio, regulator, and circuit board.
Think of a sensor that takes a reading once each second. It wakes, starts the sensor, measures, processes, perhaps sends a message, then waits again. The wait interval may look wonderfully quiet on a graph. The short burst still counts. Add current multiplied by time for each interval, then divide the total charge by the cycle time. That gives average current for this particular workload. A single low point on the graph gives you a pleasing number and very little else.
The obvious next move is to pick the deepest sleep state. Unfortunately, power states come with terms and conditions. A deeper state may wake more slowly, stop the timer you intended to use, or forget data you meant to keep. Exit latency is the time needed to return to useful work. Retention means which memory and registers survive while waiting. If the application has a response deadline, the lowest-current state can be the wrong state. That is not a paradox; it is a missed requirement.
There are also two separate knobs hiding under the word "sleep." System power management handles the CPU or whole-chip state. Device power management handles peripherals that are no longer in use. An idle CPU beside an awake sensor is still an awake product. A regulator can draw current with nothing useful happening at all. If the wait baseline remains high, inspect the powered rails and device requests before spending a week polishing the CPU idle loop.
The useful habit is to draw the supply boundary, record one complete work cycle, and then change one thing at a time. Include the active peaks as well as the quiet baseline. Keep the workload and measurement setup the same across comparisons. The Intro explains the device and its decisions; the Cheatsheet keeps the equations and state checks close by; the Practice Reference shows how to build and measure a budget. The Exercise lets you reject a tempting sleep mode when its wake time misses the deadline. That is the sort of rejection a battery can live with.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.microchip.com/en-us/application-notes/an1416-1
Supports
- MCU and system-level low-power design, duty cycling, clock and board-load tradeoffs
- Average-current budgeting and battery-life estimation limitations
- Quiz answers on the complete budget, clock tradeoff, and modeled current
- https://www.microchip.com/en-us/application-notes/an2515
Supports
- Oscillator, sleep mode, event system, brown-out, and unused-pin design choices
- Reference path and pin-configuration cautions
- https://onlinedocs.microchip.com/oxy/GUID-7CE1AEE9-2487-4E7B-B26B-93A577BA154E-en-US-2/GUID-389FF460-DF37-4C6F-92D6-E35FE4AD4C10.html
Supports
- Peripheral and GPIO settings affect total system current
- https://docs.zephyrproject.org/latest/services/pm/system.html
Supports
- Idle state, configured power states, policy selection, and wake-event responsibility
- State selection and quiz answer about wake sources
- https://docs.zephyrproject.org/latest/services/pm/device.html
Supports
- Separation of system and device power management
- Quiz answer about an active peripheral during CPU idle
- https://docs.zephyrproject.org/latest/services/pm/device_runtime.html
Supports
- Runtime device suspension and usage-count behavior
- Reference path and field note on persistent peripheral use
- https://docs.zephyrproject.org/latest/build/dts/api/bindings/power/zephyr%2Cpower-state.html
Supports
- Minimum residency and exit latency semantics
- Practice reference and quiz decisions about sleep eligibility
- https://docs.nordicsemi.com/r/bundle/ug_ppk2/page/ug/ppk/ppk_user_guide_intro.html
Supports
- Current profiles, average, peak, and charge measurement
- Practice reference and quiz measurement answer
- https://docs.nordicsemi.com/r/bundle/ug_nrf52840_dk/page/ug/dk/hw_measure_current.html
Supports
- Supply path and USB-related measurement cautions
- Field note on measurement boundary and quiz debugger answer
- https://docs.zephyrproject.org/latest/samples/boards/st/power_mgmt/serial_wakeup/README.html
Supports
- Debug mode can prevent low-power behavior
- Quiz debugger answer
- https://github.com/cifertech/free-embedded-dev-tools
Supports
- Discovery of Nordic Power Profiler Kit II, Joulescope, and TI WEBENCH
- https://www.nordicsemi.com/Products/Development-hardware/Power-Profiler-Kit-2
Supports
- Power Profiler Kit II awesome link and Landscape placement
- https://www.joulescope.com/products/js320
Supports
- JS320 current, voltage, energy, and charge measurement
- Joulescope awesome link and Landscape placement
- https://www.qoitech.com/otii-arc-pro/
Supports
- Otii Arc Pro supply and measurement role in Landscape
- https://www.ti.com/tool/ENERGYTRACE
Supports
- EnergyTrace measurement and platform-integrated analysis role
- https://www.st.com/en/evaluation-tools/x-nucleo-lpm01a.html
Supports
- STM32 Power Shield measurement role in Landscape
- https://www.ti.com/tool/WEBENCH-POWER-DESIGNER
Supports
- TI WEBENCH power-supply design path from the awesome list
