19 Power and Interfaces: Supply Draw and Bus Choice
19.1 Start With the Decision
The active portion often dominates even when it is brief. A radio join, actuator burst, sensor warm-up, flash write, or display refresh can outweigh long sleep intervals.
19.2 Route Overview
This is part 2 of 2. Review Power and Interfaces: Decision Records for the preceding evidence.
19.3 Learning Objectives
- Measure supply draw ledger from current, time, and transition evidence.
- Measure why sleep-ready boards fail from current, time, and transition evidence.
19.4 Chapter Roadmap
- Supply Draw Ledger
- Choosing a Bus
- Serial Interface Boundary Addendum
- Walkthrough: Remote Water Valve Node
- Service and Update Interfaces
- Interface Resource Handoff Addendum
- Interface Decision Record
- Common Pitfalls
- Define Wake Pins Electrically
- Sleep Is Not Firmware-Only
- Direct Actuator Pin Drive
- 4. Ignoring Boot and Fault Output States
- 5. Sharing a Bus Without Recovery Rules
- Knowledge Check
- Quiz: Power and Interface Readiness
- Match Proof to Boundary Question
- Order the Power and Interface Decision
- Key Concepts
- Prove State and Signal Together
- Valve Node Proof Record
- Why Sleep-Ready Boards Fail
- Summary
- Key Takeaway
- See Also
- What’s Next
19.5 Supply Draw Ledger
Supply draw is a measured state ledger. Estimates are useful early, but approval should depend on measured draw for the modes the device will actually use.
Use a simple weighted model: average draw is the sum of each state draw multiplied by that state’s fraction of the reporting cycle.
The ledger should include:
- state name and trigger;
- expected duration or fraction of the reporting cycle;
- measured supply draw for the whole device, not only the controller;
- rail dependencies, including sensors, radio, storage, converters, pull-ups, and indicators;
- wake delay and time spent returning to useful work;
- environmental margin for temperature, battery age, and sensor tolerance;
- validation method and measurement instrument.
The active portion often dominates even when it is brief. A radio join, actuator burst, sensor warm-up, flash write, or display refresh can outweigh long sleep intervals. Measure those bursts at the device input so the ledger includes converter loss and peripheral behavior.
19.6 Choosing a Bus
Interface selection should follow the signal need.
19.6.1 Use GPIO When
The signal is binary, event-driven, or used for a simple enable. Confirm idle level, wake capability, and safe state before approval.
19.6.2 Use ADC When
The physical value is analog and the required resolution survives sensor tolerance, noise, input range, and reference behavior.
19.6.3 Use PWM When
The output can be controlled by a duty pattern through a proper driver. Confirm frequency, output stage, and safe shutdown behavior.
19.6.4 Use I2C When
Multiple low-rate board-level devices share a short bus. Confirm pull-up rail, addresses, bus recovery, and sleep-state behavior.
19.6.5 Use SPI When
The device needs faster synchronous transfers or deterministic chip-select ownership. Confirm mode, line length, and shared-bus rules.
19.6.6 Use UART When
The module or service port expects a serial stream. Confirm wake, flow control, boot messages, and debug exposure.
19.7 Serial Interface Boundary Addendum
Choose I2C, SPI, or UART from signal measurements, wiring conditions, timing, and recovery behavior. The bus choice should stay connected to the same power and interface decision record used for GPIO, ADC, PWM, and service access.
| Interface | Fit proof | Failure mode to test |
|---|---|---|
| I2C | Short shared board-level bus, low-rate sensors, address map, pull-up rail, capacitance margin, and clock-stretching behavior. | Duplicate fixed addresses, missing pull-ups, cold-start readings, noise on an enclosure path, and stuck-bus recovery after brownout or reset. |
| SPI | Predictable burst transfers for flash, displays, data converters, or high-rate sensors with explicit chip-select ownership. | Wrong clock mode, inactive device driving the shared line, reset during transfer, partial transaction, trace-length margin, and not-ready behavior. |
| UART | Point-to-point module, debug, service, modem, or boot-console stream with clear baud, framing, ground reference, and message boundary rules. | TX/RX crossover errors, incompatible logic level, boot-log exposure, burst flow-control loss, long noisy service leads, and missing recovery commands. |
| Field boundary | Any bus or service port that leaves the board, crosses noisy wiring, or reaches field-accessible connectors. | Need for isolation, protection, transceiver choice, authentication or physical-access assumption, timeout, and safe output behavior during service. |
A mixed design is normal: I2C for short local sensors, SPI for burst peripherals, and UART for service or module links. The design is acceptable only when each link has its own pin, voltage, timing, logging, and recovery proof.
19.8 Walkthrough: Remote Water Valve Node
Consider a remote water valve node that closes a valve when a leak sensor trips and reports periodic health data to a gateway. The device must sleep for long intervals, wake immediately on leak detection, keep the valve safe during reset, and allow service staff to test the actuator at the site.
State ledger
| State | Entry Condition | Exit Condition | Required Proof |
|---|---|---|---|
| Boot | Battery inserted or watchdog reset | Firmware owns outputs | Valve driver disabled by hardware default |
| Sleep | No leak, no service session, no report due | Timer, leak interrupt, service button | Leak wake pin powered and debounced |
| Active sample | Scheduled health report | Reading accepted or marked suspect | Sensor rail enabled only during sample window |
| Leak response | Leak interrupt asserted | Valve closed and report queued | Wake latency and driver enable verified |
| Fault | Brownout, stuck bus, actuator feedback mismatch | Local reset or service action | Valve moves to safe state |
| Service | Service button and authenticated tool | Timeout or service close | UART isolated from external wiring faults |
Interface map
- Leak sensor: GPIO input with retained pull behavior and interrupt wake.
- Valve driver: GPIO output through a driver stage; boot default disables movement.
- Position feedback: ADC input with range clamp and low-pass filter.
- Gateway radio: serial or SPI module on a switchable rail.
- Service tool: UART with access control, timeout, and physical protection.
Decision result
The design is acceptable only if bench measurements prove wake timing, actuator default state, sensor rail sequencing, ADC range, and radio burst draw. The decision record should also name the review conditions, such as a new actuator, longer cable, colder enclosure, different battery chemistry, or a service-port change.
19.9 Service and Update Interfaces
Service access is part of the hardware design. A hidden debug header, boot console, firmware update pin, or factory calibration connector can become a field failure path if it is not checked.
Check service interfaces for:
- authentication or physical access assumption;
- timeout and exit behavior;
- safe output behavior while a service tool is attached;
- update rollback or recovery path;
- logging needed to diagnose failed wakes, brownouts, and bus recovery;
- protection from miswiring, electrostatic events, and accidental back-feed;
- whether service mode keeps rails awake longer than normal operation.
Make the service and update interfaces premise visible in the diagram Figure 19.1: Service interface record showing debug access, update mode, calibration, fault logs, safe outputs, timeout, recovery path, and review conditions. Begin by distinguishing Service Interface Record from brownouts, bus recovery.
Figure 19.1 becomes useful when Service Interface Record is read alongside brownouts, bus recovery. failed diagnostic adds the remaining acceptance cue. This supports service and update interfaces. The visual summarizes: Service interface record showing debug access, update mode, calibration, fault logs, safe outputs, timeout, recovery path, and review conditions.
19.10 Interface Resource Handoff Addendum
A hardware interface is only ready when the downstream firmware, message, service, and support resources preserve the same meaning. Keep a short handoff record for every interface that crosses a signal, driver, payload, API, or service boundary.
| Boundary | Handoff proof to keep |
|---|---|
| Signal to driver | Pin map, voltage domain, connector, timing, reset state, interrupt or wake behavior, bus capture, and error-reporting rule. |
| Driver to payload | Units, calibration state, timestamp, identity, quality flag, timeout, retry, stale-reading behavior, and schema version. |
| Payload to service | Topic or endpoint, authentication, authorization, duplicate handling, command expiry, retention, monitoring, and replay proof. |
| Resource to support | Datasheet or reference-design revision, driver/HAL version, SDK adapter limit, fixture or simulator coverage, release note, and service procedure. |
| Review condition | Pin change, sensor replacement, schema change, SDK update, service-port exposure, failed diagnostic, or field proof that contradicts the old interface record. |
This keeps GPIO, ADC, bus, UART, service-port, and API choices connected. A sample program proves a path only when its contract can be diagnosed, updated, and handed to the next owner.
19.11 Interface Decision Record
A good decision record is short, testable, and easy to review.
- Device role: Remote water valve node.
- Approved states: Boot, sleep, active sample, leak response, fault, service, update.
- Wake sources: Leak interrupt, scheduled timer, service button, watchdog.
- Critical boundaries: Leak input, valve driver, position feedback ADC, radio rail, service UART.
- Validation: Measure state draw at device input, wake latency, boot output default, stuck-bus recovery, service timeout, and fault output behavior.
- Review conditions: New actuator, longer external cable, new battery chemistry, service-port change, firmware update path change, or failed wake proof from the field.
Treat interface decision record as a system decision around Power and Interface Review Flow. The visual in Figure 19.2 places bench tests: draw, wake within this relationship: Power and interface decision flow from proof collection to approval, validation, field proof, and review conditions.
Map Power and Interface Review Flow to the current requirement in Figure 19.2. Map bench tests: draw, wake to the next duty and A failed field wake proof reopens the whole review to the later proof. This continues interface decision record: Power and interface decision flow from proof collection to approval, validation, field proof, and review conditions.
19.12 Common Pitfalls
A wake input without a defined idle level can wake repeatedly, miss real events, or draw extra energy through a partly enabled input buffer. Define the idle level, pull method, debounce, edge, and retained rail.
Firmware can request sleep, but hardware decides what remains powered. Check sensor rails, pull-ups, wake sources, output drivers, clocks, and service ports before approving a sleep state.
Motors, relays, solenoids, valves, and long cables need driver stages and protection. A GPIO pin should command the driver; it should not be the power path for the load.
Outputs can move before firmware starts or after a reset. Use hardware defaults, pull behavior, and driver enables so actuators remain safe through boot, brownout, watchdog reset, and update mode.
I2C, SPI, and UART buses need ownership and recovery rules. A stuck device, wrong chip select, or boot console message can block a sensor path unless the decision record defines recovery behavior.
19.13 Knowledge Check
Key Concepts
Use these terms as one state-and-signal vocabulary. A power state defines what is active and retained; wake sources move between states; GPIO, ADC, PWM, and shared buses carry the signals that can wake, measure, or actuate; level shifting and open-drain behavior keep voltage domains compatible; and back-feed identifies a path that can defeat the intended state. Reading the definitions together prepares the proof route that follows.
Apply the vocabulary to the physical product rather than the microcontroller alone. External pull-ups, sensors, radios, converters, drivers, service cables, and protection components can change current draw or pin state during boot, sleep, fault, and update. The review succeeds when rail measurements and signal observations agree with the named state and safe output behavior.
When they disagree, diagnose the path in order: confirm the active rail and voltage domain, identify the signal owner and default, observe the transition that woke or drove it, and check retained state afterward. This route links every definition below to a measurable electrical consequence and a concrete recovery action.
- Power state: A named operating condition with entry rule, exit rule, supply draw, retained data, and output behavior.
- Wake source: A timer, pin, watchdog, radio event, service action, or external signal that can move the device out of a lower-power state.
- Retained state: Data or hardware context preserved while the rest of the device is paused or unpowered.
- GPIO: A configurable digital input or output used for simple signals, enables, interrupts, chip selects, and status lines.
- ADC: An analog-to-digital converter used when a physical value must be measured as a voltage within a defined range.
- PWM: A duty-pattern output used with a driver stage to control brightness, speed, heat, or actuator position.
- Level shifter: A circuit that makes logic signals compatible across different voltage domains.
- Open-drain bus: A bus style where devices pull a line low and an external pull-up sets the high level, common for I2C and shared alert lines.
- Back-feed: An unintended power path through a signal pin into an unpowered device or rail.
19.14 Prove State and Signal Together
If you only need the selection shortcut, this layer is enough: a low-power interface design is ready when every state has a wake rule, every signal has an owner, and the measured behavior matches the decision record.
For a valve node, state proof and signal proof have to be reviewed together. A low-power STM32L or nRF52-class controller may sleep well on its own, but the product still fails if the leak switch is powered from a rail that turns off, if the pull-up keeps drawing current through a wet connector, or if the valve driver briefly enables while reset pins float. The record should name the sleep rail, retained timer or GPIO wake source, valve-driver default, ADC reference, radio or modem burst, service UART timeout, and the test instrument used for current measurement.
The same record should say which interface is allowed to wake or move the product. GPIO inputs need idle level, debounce, interrupt edge, and ESD or surge assumptions. ADC feedback needs voltage range, divider current, source impedance, reference rail, and filter settling. PWM or enable outputs need a driver stage, flyback or transient protection, and a hardware default that keeps the valve safe before firmware starts. I2C, SPI, and UART links need ownership, voltage domain, recovery, and service-access rules.
For prove state and signal together, inspect the linked figure in Part 1 at Microcontroller I/O Interfaces. Its visible premise is: Microcontroller Input/Output Interfaces. Then compare GPIO.
Begin the diagram the linked figure in Part 1 with Microcontroller I/O Interfaces. Continue through GPIO before checking I2C Bus. This path preserves the chapter’s prove state and signal together argument: Microcontroller Input/Output Interfaces.
State proof
Name boot, active, sleep, fault, service, and update states with entry rules, exit rules, retained data, safe outputs, and measured draw.
Signal proof
Map each GPIO, ADC, PWM, I2C, SPI, UART, wake line, actuator driver, and service port to one owner and one safe default.
Boundary proof
Check voltage range, pull behavior, debounce, level shifting, protection, back-feed, and recovery in the states that matter.
19.15 Valve Node Proof Record
For the remote water valve node, the decision should read like a field test plan. It should prove that the device can sleep, wake on a leak, close the valve safely, report health, and support service without creating a new electrical failure path.
Start the record with measured states rather than expected battery life. Measure sleep current with the leak input connected, pull network installed, sensor rail in its intended state, radio or modem fully off, and the service connector in its field configuration. Then measure the wake sequence: interrupt assertion, controller resume, sensor-rail enable, ADC feedback sample, valve-driver enable, actuator current, event write, and radio burst. Keep the oscilloscope capture, current trace, firmware build, board revision, ambient condition, and test temperature beside the table so the result can be repeated.
Next, map each boundary to a failure test. Pull the leak input high and low, short the sensor cable within the protected assumptions, reset the controller while the valve driver is attached, brown out during a flash write, hold I2C low, disconnect the radio module, and leave the service UART attached until timeout. The record is strong only when those tests return the device to a safe output state or a diagnosable fault state. Add pass limits for maximum wake latency, maximum sleep current, minimum ADC headroom, and service-session duration so later board revisions can be compared without guessing.
Wake path
Record the leak sensor rail, idle level, pull method, debounce, interrupt edge, retained state, wake latency, and first safe action after wake.
Output path
Show the valve driver default, enable timing, feedback range, brownout behavior, watchdog behavior, actuator current, and fault-state output rule.
Service path
Define the UART or tool boundary, authentication assumption, timeout, rail impact, logs, update recovery, and review conditions.
19.16 Why Sleep-Ready Boards Fail
Most failures come from a mismatch between the power state and the physical boundary. A signal can look correct during active testing and still fail when rails, pulls, clocks, service tools, or external modules change state.
The hidden problem is often a current path or ownership path that was invisible in the active demo. An I2C pull-up tied to the wrong rail can power a sleeping sensor through its data pin. A UART boot log can command or confuse a field modem before the application owns the port. A high-side driver can leak enough current to move a small actuator, while a low-side driver can leave the load referenced to an unsafe supply during reset. ADC dividers, status LEDs, sensor warm-up circuits, and protection networks all need the same state-by-state review as firmware.
- Retained rail mismatch: a wake source, pull-up, sensor, or timer is not powered in the sleep state that depends on it.
- Unsafe defaults: an actuator driver, chip select, enable pin, or PWM output moves during boot, brownout, reset, service, or update.
- Hidden current path: pull-ups, indicators, converters, external modules, or signal back-feed keep the device awake or drain the battery.
- Missing recovery: a stuck I2C device, noisy service cable, failed update, or watchdog reset has no tested path back to safe operation.
Recovery proof should include the path back from each fault, not only detection. For I2C, document whether firmware clocks the bus free, power-cycles the sensor rail, or disables the feature until service. For SPI, prove chip selects stay inactive during reset and that a partial flash or converter transfer does not corrupt the next sample. For UART, prove boot messages cannot enter the command stream, service sessions expire, and field tools cannot hold rails awake after the enclosure is closed. For ADC, prove the reference and divider settle before the sample is trusted.
19.17 Summary
Power management and device interfaces must be checked as one design surface. The state ledger explains when the device wakes, sleeps, faults, updates, and services. The interface map explains which component owns each signal and how that signal remains safe across voltage domains, boot, sleep, and fault behavior. The decision is complete only when measurements, wake behavior, boundary protection, and review conditions are recorded.
19.18 Key Takeaway
Power and interface decisions must connect electrical limits, sleep behavior, connectors, buses, and measurement proof before a hardware choice is trusted.
19.19 See Also
Choose the next route by locating the unresolved physical boundary. Hardware selection and SoC architecture address compute and block ownership; energy and sensing chapters deepen state budgets and analogue paths; edge-fog architecture tests whether responsibilities belong on the device or upstream. Keep the current rail, wake, signal, and failure records attached so the next chapter extends the design rather than restarting it.
Hardware selection
- MCU vs MPU Selection - choosing controller-class or processor-class hardware from workload and lifecycle proof
- IoT System-on-Chip Architecture - internal SoC blocks, memory, clocks, power islands, and accelerators
Energy and sensing
- Energy-Aware Considerations - duty cycling, harvesting, and low-power design patterns
- Sensor Interfacing and Processing - sensor signal paths, sampling, conditioning, and processing
System architecture
- Edge-Fog Computing - deciding what runs on the device, gateway, and cloud path
19.20 What’s Next
| Direction | Chapter | Focus |
|---|---|---|
| Next | IoT System-on-Chip Architecture | SoC blocks, clocks, memory, and power islands |
| Back | MCU vs MPU Selection | Controller-class versus processor-class selection |
| Related | Energy-Aware Considerations | Low-power operation and duty cycling |
19.21 Continue Your Route
This final part closes the route from Supply Draw Ledger through What’s Next. Return to Power and Interfaces: Decision Records or continue from the reference-architectures module index.