Energy & Power · Study deck
Low-Power Design: Firmware and Wake Policies
A sleeping node can still waste power through a pull-up or sensor rail.
Battery Bruno is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Select a sleep mode from wake latency, state retention, and wake-source requirements.
- Design time-based, event-driven, and adaptive duty-cycle policies.
- Identify hidden loads from GPIOs, pull-ups, regulators, sensors, LEDs, and radios.
- Use power gating and state reinitialization without corrupting measurements or firmware behavior.
Major section
Start With the Sleeping Device
Saving power is not simply making everything sleep; the device must still notice the event and preserve its meaning.
- The first decision is which service promise controls each wake-up.
- An application programming interface is a defined way for software parts to request work or data; API is its short name.
Major section
Start With the Sleeping Device (continued)
A low-power design begins by asking what must stay awake, what may sleep, and what event is allowed to wake the system again.
- Firmware means the software stored on a device.
- Latency means the time from an input event to the result that matters.
- The cheapest energy is the energy a device never draws.
Major section
Start With the Sleeping Device (continued)
This runway does not prove that the deepest sleep state is always best.
- The simple route is service policy first, wake policy second, power states third, and measurement last.
- If a strategy cannot be seen in the trace, it is still only a claim.
- “A strategy that isn’t in the trace is still just a claim — show me the charge it actually saved.”.
Major section
Minimum Viable Understanding
The deepest sleep mode is not always best; wake latency, retained state, and wake-source support matter.
- Peripherals can dominate sleep current unless they are disabled, held in a known state, or power-gated.
- Radio energy includes startup, association, receive windows, retries, and acknowledgments, not only transmit current.
- Every optimization claim should be checked against a before/after current trace.
Major section
Strategy Stack
Low-power design works best when decisions are layered from service policy down to board leakage.
- The separate: Wake label exposes the energy consequence, preventing the first two stages from being accepted on their own.
- The complete reading is that no-panel low-power strategy stack from service policy through wake policy, power states, load gating, and measurement evidence.
Major section
Sleep-Mode Selection
Sleep-mode selection is a requirements decision.
- A mode is viable only if it preserves the state you need, supports the wake source you need, and wakes quickly enough for the service requirement.
- The simplified worked example below shows why sleep percentage alone is not enough: every state contributes current multiplied by time.
Major section
Checkpoint: Sleep Policy Fit
The comparison makes the causal boundary explicit: oscillator and restore energy are paid once per wake, while sleep leakage grows with the interval.
- Idle or wait-for-interrupt.
- Wake must be nearly immediate and peripherals stay active.
- Milliamps of standby current can destroy long-life budgets.
- Frequent wake events need quick resume and retained RAM.
Major section
Checkpoint: Sleep Policy Fit (continued)
Retained clocks and peripherals may keep current high.
- Wake intervals are seconds to hours and limited state retention is acceptable.
- Boot and reinitialization cost may dominate frequent wakes.
- Full-cycle trace, wake cause, initialization time.
- Events are rare and only a small wake circuit must remain alive.
Deck summary
Key takeaways
Saving power is not simply making everything sleep; the device must still notice the event and preserve its meaning.
- A low-power design begins by asking what must stay awake, what may sleep, and what event is allowed to wake the system again.
- This runway does not prove that the deepest sleep state is always best.
- The deepest sleep mode is not always best; wake latency, retained state, and wake-source support matter.
- Low-power design works best when decisions are layered from service policy down to board leakage.
Retrieval practice
Recall check 1 of 2
Battery Bruno says: answer from memory, then check your reasoning.
Q1A battery node has a low sleep current but wakes too often for its service. Which design level should the team revisit?
Show answer
Answer: A The strategy stack starts with what the service needs and when the device wakes.
Retrieval practice
Recall check 2 of 2
Battery Bruno says: answer from memory, then check your reasoning.
Q2A deep sleep mode loses state required for the next action. How should the team judge that mode?
Show answer
Answer: D Viability depends on retained state, supported wake source, and response time.
Print reference
Answers
Answer key.
- A · The strategy stack starts with what the service needs and when the device wakes.
- D · Viability depends on retained state, supported wake source, and response time.