Low-Power Design and Power Management Questions

Overview
As an embedded developer I'd apply multiple firmware-level tactics beyond DVFS and deep sleep to reduce power on sensor/battery nodes. Key strategies:

1. Peripheral gating / selective shutdown

• Disable unused peripherals (ADC, UART, I2C) when idle via peripheral clock or power gating.
• Example: Turn off GPS and enable only when a fix is requested.

2. Duty cycling and batching I/O

• Aggregate sensor reads/transmits and sleep between bursts to amortize wake costs.
• Example: sample temperature every second but buffer and transmit once per minute.

3. Adaptive sampling / event-driven sensing

• Use threshold interrupts or low-power comparators to wake only on meaningful events.
• Example: accelerometer interrupt wakes MCU on motion; otherwise accelerometer stays in low-power FIFO mode.

4. Clock gating and reducing peripheral clock domains

• Lower or gate clocks for subsystems instead of whole CPU, reduce bus frequencies during idle.
• Example: run sensor interface at lower SPI clock when transferring low-rate data.

5. Tight code & ISR optimization

• Minimize ISR duration, avoid busy-wait loops, use non-blocking APIs to return to sleep faster.
• Example: replace delay loops with timer-driven callbacks and DMA for ADC transfers.

6. Use DMA and hardware offload

• Offload data movement and simple processing (CRC, filtering) to DMA/PWM/Crypto engines to keep CPU asleep.
• Example: DMA ADC samples to RAM and only process when buffer full.

7. Power-aware RTOS scheduling / tickless idle

• Use tickless kernel and wake scheduling to avoid periodic wakeups; coalesce tasks to reduce transitions.

Each tactic reduces active time or peripheral power; combine them based on hardware capabilities and latency/throughput constraints.

Overview
Below are the primary power sinks in a microcontroller-based IoT device, when each typically dominates (active vs sleep) and one concrete technique to reduce its contribution.

• CPU / MCU core

  • When it dominates: Active modes, heavy computation, high clock frequencies.
  • Reduction: Use dynamic frequency scaling / stop CPU when idle; move work to low-power co-processor or use event-driven, interrupt-based firmware.

• SRAM / Flash

  • When it dominates: Flash writes (program/EEPROM updates) and when large SRAM is continuously powered (deep-sleep without retention off).
  • Reduction: Minimize write frequency; use flash write buffering; disable SRAM banks or use retention-free modes during deep sleep.

• Peripherals (UART, SPI, I2C, timers)

  • When it dominates: When peripherals are enabled continuously (polling) or high-speed transfers.
  • Reduction: Gate peripheral clocks, use DMA to batch transfers, switch to low-power peripheral modes and wake on interrupts.

• Sensors (analog/digital front-ends)

  • When it dominates: Continuous sampling, high sample rates, or always-on sensors (e.g., IMU at full rate).
  • Reduction: Duty-cycle sensing (burst sampling), use sensor low-power modes, hardware threshold/interrupts for wake-up.

• Radio transceiver (BLE, Wi‑Fi, LoRa)

  • When it dominates: Active transmit/receive, long TX times, heavy connectivity.
  • Reduction: Reduce TX power, use efficient protocols (connection intervals, adaptive data rate), batch transmissions, use wake-sleep radio scheduling.

• Voltage regulators / power conversion

  • When it dominates: Inefficient regulators at low loads or when converting from much higher battery voltages.
  • Reduction: Use low‑Iq LDOs or high-efficiency switching regulators sized for expected load; enable regulators only when needed; optimize input voltage range.

• LEAKAGE (chip/package)

  • When it dominates: Deep-sleep long-term (weeks/months).
  • Reduction: Choose parts with low standby leakage, power-gate domains, and remove pull-ups/pull-downs on unused pins.

Each technique pairs firmware decisions (clock/peripheral gating, duty cycling) with hardware choices (low-leakage components, regulators) to maximize battery life.

Approach (brief)
I would monitor per-task running time over a sliding window, compute CPU utilization U = busy_time / window, smooth with an exponential moving average (EMA) to avoid oscillation, apply hysteresis and minimum dwell time, then map U to {LOW, MEDIUM, HIGH} and call change_frequency(level).

Pseudocode (C-style)

// config
#define WINDOW_MS        1000
#define EMA_ALPHA        0.3f    // smoothing factor 0 < alpha <= 1
#define HYSTERESIS       0.05f   // 5% hysteresis
#define DWELL_MS         200     // minimum time between freq changes

enum freq_level { FREQ_LOW, FREQ_MEDIUM, FREQ_HIGH };

struct task_stats {
    uint32_t busy_ms;      // accumulated in current window
    uint32_t last_update;  // timestamp ms
    float  ema_util;       // smoothed utilization [0..1]
};

void tick_task_run(struct task_stats *t, uint32_t delta_ms) {
    t->busy_ms += delta_ms;
}

// called every WINDOW_MS (timer or RTOS hook)
void evaluate_and_set_freq(struct task_stats tasks[], int n_tasks) {
    uint32_t now = ms_now();
    uint32_t window = WINDOW_MS;
    uint32_t total_busy = 0;
    for (int i=0;i<n_tasks;i++) {
        total_busy += tasks[i].busy_ms;
        tasks[i].busy_ms = 0; // reset for next window
    }
    float raw_util = (float) total_busy / (float) window; // >1 if multi-core; clip if single-core
    if (raw_util > 1.0f) raw_util = 1.0f;
    static float smoothed = 0.0f;
    smoothed = EMA_ALPHA * raw_util + (1.0f - EMA_ALPHA) * smoothed;

    static enum freq_level current = FREQ_HIGH;
    static uint32_t last_change = 0;

    // determine target with hysteresis
    enum freq_level target = current;
    if (smoothed >= 0.75f + HYSTERESIS) target = FREQ_HIGH;
    else if (smoothed >= 0.40f + HYSTERESIS) target = FREQ_MEDIUM;
    else if (smoothed <= 0.25f - HYSTERESIS) target = FREQ_LOW;
    // enforce dwell time
    if (target != current && (now - last_change) >= DWELL_MS) {
        change_frequency(target);
        current = target;
        last_change = now;
    }
}

Reasoning & edge cases

• EMA reduces rapid flips; hysteresis avoids boundary chattering; dwell time prevents frequent DVFS calls.
• For multi-core, normalize by (window * n_cores) or cap at 1.0 per core.
• Consider deadline misses: if scheduler detects missed deadlines, force FREQ_HIGH immediately.
• Complexity: O(n_tasks) per evaluation, lightweight for embedded RTOS.

Approach / summary
Choose LDO when simplicity, low EMI, fast clean transient for ADC, and low cost/size matter at moderate VIN-to-VOUT drop or very low duty/activity. Choose buck (switching) when conversion loss from high VIN or high average current dominates despite EMI and size complexity.

Efficiency & curves

• LDO efficiency ≈ Vout / Vin (linear). At 3.3 V out from 4.2 V battery: ~79%.
• Buck efficiency is non-linear: low-load efficiency drops due to switching/quiescent losses; at mid/high load often 85–95%.
• Draw qualitative curves: LDO flat slope (decreasing with VIN), buck low at microamp loads, rising to peak at 10s–100s mA.

Quiescent current / idle life

• LDO Iq often ~1–50 µA; many modern “nano” LDOs <1 µA. Buck Iq can be 10s–100s µA unless burst or PFM modes with penalties for EMI.
• For mostly-sleep systems, Iq dominates battery drain. Example: MCU sleep 5 µA + radio off: if buck Iq = 100 µA, battery life cut heavily → prefer LDO.

EMI & ADC impact

• Buck switching produces broadband noise; affects sensitive ADC or radio RX. Mitigations: spread-spectrum switching, good input/output LC filtering, layout, synchronous rectifiers, or use LDO for analog domain. For ADC measurements, use LDO or local LDO post-buck for reference/ADC rail.

Transient response to bursts

• LDOs respond instantly; transient headroom = Vin - Vout. Switchers may have slower loop response and require output capacitors/fast transient-mode ICs or hybrid: buck + local LDO/ceramic decoupling for bursts (radio TX current spikes).

Size / cost

• Buck: more components (inductor, diode/MOSFETs, larger caps), PCB area, higher BOM. LDO: tiny SOT package, cheaper.

Break-even numeric example
Assume battery capacity 1000 mAh at 3.7 V (3.7 Wh). Device average load = Idle 10 µA for 99% time, active 30 mA for 1% time at 3.3 V. Compare LDO (Iq = 1 µA, eff = Vout/Vin = 3.3/4.2 = 0.786) vs Buck (Iq = 50 µA, eff = 90% when active).

Compute average power (approx):

• Active power drawn by load at 3.3 V: Pact_load = 3.3 V * 30 mA = 99 mW (1% duty → 0.99 mW average)
• Idle load: Pidle_load = 3.3 V * 10 µA = 33 µW (99% duty → ~32.7 µW average)

LDO losses: converter Iq at Vin ~1 µA → Piq = 4.2 V * 1 µA = 4.2 µW
Total input power = (Pactive/eff_active + Pidle/eff_idle) + Piq ≈ (0.99 mW /0.786) + (32.7 µW /0.786) + 4.2 µW
≈ 1.26 mW + 41.6 µW + 4.2 µW = 1.316 mW

Buck losses: Iq = 50 µA → Piq = 4.2 V * 50 µA = 210 µW
Active: 0.99 mW / 0.9 = 1.1 mW
Idle: 32.7 µW / 0.9 = 36.3 µW
Total ≈ 1.1 mW + 36.3 µW + 210 µW = 1.346 mW

Here LDO slightly better overall due to low Iq and low idle current. Break-even vin/load occurs when extra buck savings during active periods offset higher Iq:
Formula:

Iq_buck * Vin + P_active*(1/eff_buck - 1/eff_ldo) + P_idle*(1/eff_buck - 1/eff_ldo) <= Iq_ldo * Vin

Plug numbers to solve for active duty or load where buck wins.

Practical recommendations

• If average current > ~10–30 mA or VIN much higher than VOUT, prefer buck.
• If device sleeps most of time and ADC/radio sensitivity matters, prefer LDO or buck+local LDO for analog.
• Consider hybrid: buck for bulk conversion + low-Iq LDO for noisy rails.
• Prototype with oscilloscope/ADC and measure real quiescent, EMI, and transient performance.

Clarify constraints

• Vmem must always be >= Vcore. CPU freq changes may require Vcore up/down. Sequence must prevent transient where Vcore > Vmem.

High-level ordering

• Increase Vcore: first raise Vmem (if Vmem < target Vcore), then ramp Vcore.
• Decrease Vcore: first lower Vcore, then lower Vmem (but only after verification).
• For frequency increase: request target Vcore; driver computes required Vmem = max(current Vmem, target Vcore) and sequences accordingly.

Ramp rates & timing

• Use conservative ramp rates: e.g., 10 mV/us (configurable). Insert settling delay after each step (e.g., 50–200 µs) based on datasheet.
• Break large changes into steps (e.g., 20–50 mV steps) and verify at each step.

Monitoring points

• Readback voltages after each step via PMIC ADC or VMON GPIO.
• Verify Vmem >= Vcore before enabling higher CPU clock domain.
• Watch PMIC fault/status registers (thermal, OVP, UVLO).

Rollback & error handling

• If readback deviates beyond tolerance or PMIC flags an error:
  • Immediately request safe state: lower Vcore to last-known-safe, hold CPU in reduced frequency or enter idle.
  • If Vmem fails, force Vcore down to safe margin and halt CPU clocks if necessary; report error to higher layer and attempt retry with backoff.
• Log events and increment a retry counter; after N failures escalate to watchdog reset or safe boot.

Firmware ↔ PMIC driver interaction

• Firmware issues high-level requests: set_freq(target_freq) / set_rail(rail, target_mv).
• PMIC driver implements sequencing state machine with APIs:
  • prepare_voltage(target_vcore_mv, target_vmem_mv, callback)
  • commit / abort
  • read_status()
• Driver exposes synchronous and async calls; firmware uses synchronous for boot, async with callbacks for runtime DVFS.
• Include capability queries (min/max, ramp granularity, readback support) so firmware adapts behavior.

Safety testing

• Unit tests for edge cases, hardware-in-loop tests for ramp/fault injection, and timeout/failure validation in CI.