18 Power and Interfaces: Decision Records

18.1 Start With the Decision

This section: Start With the Decision — A valve node must wake, sample, decide, and drive its load before its deadline.

A valve node must wake, sample, decide, and drive its load before its deadline. Trace power and signal timing across that path.

18.2 Route Overview

This section: Route Overview — This is part 1 of 2.

This is part 1 of 2. Continue with Power and Interfaces: Supply Draw and Bus Choice.

18.3 Part Objectives

This section: Part Objectives

• Measure power and interface decision route from current, time, and transition evidence.
• Validate signal boundaries with a concrete scenario and pass criteria.

18.4 Chapter Roadmap

This section: Chapter Roadmap

• Start With the Battery and Port
• In 60 Seconds
• Phoebe’s Field Notes: Why “The Reference And Divider Settle” Is A Real Deadline
• Overview
• Quick Check: Valve Node Wake Path Proof
• Power and Interface Decision Route
• State Ledger
• Wake and Retention Plan
• Interface Ownership
• Cortex-M Core Options and Portability
• Signal Boundaries

18.5 Start With the Battery and Port

This section: Start With the Battery and Port — Picture a battery weather box that reads a wet sensor and opens a small drain valve.

Prove One Signal From Pin to Physical Action

Picture a battery weather box that reads a wet sensor and opens a small drain valve. The design can fail even when every part works alone. The signal level, wire rule, power draw, and safe output all have to agree.

A microcontroller means the small computer inside the box. GPIO means general purpose input and output pins. An analog-to-digital converter means a circuit that turns a voltage into a number; it is called an ADC. Inter-integrated circuit (I2C), Serial Peripheral Interface (SPI), and universal asynchronous receiver-transmitter (UART) each mean a wired rule for moving data between parts. Pulse-width modulation means control made by changing how long a signal stays on; it is called PWM. An actuator means a part that creates a physical action.

Trace one wet reading from the sensor pin to the valve command. Reverse a lead, lower the battery, hold the data line, repeat a command, and restart the controller. The valve must return to a named safe state.

This runway does not select a board or size every component. The deeper sections compare electrical limits, power budgets, timing, ports, and evidence for a hardware release.

Power and interface choices become concrete when you picture a field technician holding the device. How is it powered, how long should it last, which port exposes data or debug access, and what happens when a cable, battery, sensor, or radio module changes?

Start with that physical story. The architecture needs evidence that power states, connectors, buses, protection, service access, and interface ownership support the deployment instead of becoming hidden failure points.

Math Bridge · guided foundationsCan a 12-bit ADC still read the wrong voltage?Let Phoebe connect code size, Nyquist sampling, source resistance, and acquisition time. Learn the maths

18.6 Overview

This section: Overview — IoT hardware touches the physical world through supply rails, sensors, actuators, and communication buses.

IoT hardware touches the physical world through supply rails, sensors, actuators, and communication buses. Small mistakes at those boundaries create field failures: a floating input wakes a device repeatedly, a wake pin cannot run from the retained rail, an actuator glitches during boot, or a sensor output exceeds the controller input range.

This chapter gives a decision method for power management and device interfaces. It is intentionally platform-neutral: use the same checks whether the design is a small controller board, an industrial node, a wearable device, or a gateway-supervised sensor.

18.7 Learning Objectives

This section: Learning Objectives

By the end of this chapter, you should be able to:

• build a power-state ledger for boot, active work, idle wait, sleep, fault, service, and update modes;
• connect wake sources, retained data, and safe output states to the device mission;
• select GPIO, ADC, PWM, I2C, SPI, or UART based on signal measurements rather than habit;
• identify voltage-domain, pull-up, debounce, level-shift, and protection needs at each boundary;
• write an interface decision record that can be tested, serviced, and reviewed when requirements change.

18.8 Power and Interface Decision Route

This section: Power and Interface Decision Route — Evaluate power and interfaces together.

Evaluate power and interfaces together. A bus that works on a bench can still fail a field device if it forces the wrong rail to stay powered, wakes too often, or leaves an actuator in an unsafe state during reset.

Do not apply power and interface decision route until its premise is visible near Power and Interface Decision Route in Figure 18.1: Power and interface decision route from device mission to state ledger, wake plan, signal map, boundary protection, measurements, and decision record. Inspect the span to Signal Map.

+

Interrogate Power and Interface Decision Route first, then find Signal Map in Figure 18.1. Apply the Signal Map review question before decision, then review. Those answers support power and interface decision route; the figure states: Power and interface decision route from device mission to state ledger, wake plan, signal map, boundary protection, measurements, and decision record.

Use this route:

1. Define the physical role and the failure the device must prevent.
2. List all states the device can enter, including service and update modes.
3. Assign wake sources, retained data, and safe outputs to each state.
4. Map every signal boundary and decide which component owns it.
5. Check voltage domains, pulls, filtering, debounce, isolation, and surge protection.
6. Measure the supply draw and timing that the design depends on.
7. Record the decision, rejected options, validation tests, and review conditions.

Practitioner Knowledge Check

Practitioner Knowledge Check

18.9 State Ledger

This section: State Ledger — A power design is traceable only when every state has a name, entry condition, exit condition, draw estimate, retained data, and output rule.

A power design is traceable only when every state has a name, entry condition, exit condition, draw estimate, retained data, and output rule.

One relationship governs service and update. The diagram Figure 18.2 states it as: Power-state ledger showing boot, active work, idle wait, sleep or retention, fault, service, and update states with entry rule, wake source, retained data, safe output, and measurement proof. Study State and RAM.

+

The ledger in Figure 18.2 lists each power state; check its wake, saved data, and safe output.

18.10 Wake and Retention Plan

This section: Wake and Retention Plan — Sleep is useful only when the device can wake for the right reason and recover enough state to act correctly.

Sleep is useful only when the device can wake for the right reason and recover enough state to act correctly. Treat wake behavior as a signal route, not as a firmware checkbox.

Key questions:

• Which events may wake the device: timer, threshold, button, bus event, radio event, watchdog, or external alarm?
• Is the wake source powered from a rail that remains available in the chosen state?
• Does the wake signal need pull-up, pull-down, debounce, filtering, or edge selection?
• Which data must survive sleep: calibration, sequence number, security material, last safe output, error counter, or time base?
• What is the first safe action after wake before the full application is running?

Use Figure 18.3 to decide which sleep state preserves enough context without consuming more current than the duty-cycle budget allows.

+

Begin with active mode as the reference, where the processor and radio can draw tens or hundreds of milliamps. Light sleep reduces current while retaining more state and waking quickly; its 0.5–5 mA range still matters in a long idle period. Deep sleep reaches roughly 50–500 µA, or 0.05–0.5 mA, but trades that saving for slower wake and less retained context. The correct choice therefore follows the latency and retention requirement, not the lowest current label alone, and the firmware must define the first safe action after wake.

18.11 Interface Ownership

This section: Interface Ownership — Every signal should have a clear owner.

Every signal should have a clear owner. Ambiguous ownership causes double-driving, unsafe defaults, timing faults, and service confusion.

18.12 Cortex-M Core Options and Portability

This section: Cortex-M Core Options and Portability — “Cortex-M” identifies a processor-core family, not a complete microcontroller.

“Cortex-M” identifies a processor-core family, not a complete microcontroller. The core supplies an instruction-set profile, exception model, interrupt controller conventions, and a standard system-control region. The silicon vendor still chooses flash, SRAM, clocks, pin multiplexing, DMA, radio, ADC, timers, and serial peripherals. That boundary explains both the family’s strong compiler portability and the real cost of moving firmware between chips.

Later Cortex-M cores also use Armv8-M and newer profiles, so never infer the architecture from the letter “M” alone. Read the core’s architecture manual and the vendor’s device reference manual together.

Three often-confused facilities illustrate the boundary:

• An optional Memory Protection Unit (MPU) divides memory into regions with access and execution permissions. It can contain a bad task or enforce privileged access, but it is not virtual memory and does not make drivers safe automatically.
• SysTick, where the core implements it, is a standard 24-bit down-counter commonly used for an OS tick or timeout base. Firmware can remain portable at the API level while availability, clock source, and low-power behavior still need device-specific proof.
• Bit-banding on supporting older profiles maps a bit in an aliasable region to a word-sized alias address. Writing the alias can change one underlying bit without a read-modify-write sequence. It is optional, is not present across all Cortex-M architectures, and should never be assumed by portable code.

Portability therefore stops in layers:

Suppose firmware moves from one Cortex-M vendor to another. The compiler may accept the same application source, and the scheduler may keep the same task model. The I2C temperature driver still has to be rebound to different clock gates, pins, status flags, and recovery semantics. Keep that work below an explicit hardware-abstraction contract, but test the contract with register-level fault cases; an abstraction layer relocates vendor dependence, it does not erase it.

Why pause at interface ownership? Beside Microcontroller I/O Interfaces, the diagram Figure 18.4 makes GPIO explicit within this relationship: Microcontroller Input/Output Interfaces.

+

The interface map in Figure 18.4 places different electrical duties around the microcontroller. An ADC input needs a known voltage range, reference, source impedance, filter, and sample time; extra bits cannot rescue a reading taken before it settles. GPIO can command a driver for a valve, but the high load needs its own power path and protection. SPI needs clock mode, chip-select ownership, and sharing checks, while I2C needs a pull-up rail and stuck-bus recovery. These are interface contracts, not just connector names. Prove them across boot, active, sleep, and powered-off states before moving a driver between boards.

18.13 Signal Boundaries

This section: Signal Boundaries — Signal compatibility is a boundary decision.

Signal compatibility is a boundary decision. A signal is not approved just because the connector fits.

Work outward from the receiver. Establish the voltage domain across normal, boot, sleep, service, and fault states, then record the line’s pull behavior: pulled high, pulled low, actively driven, tri-stated, or held externally. Where logic ranges differ, choose the appropriate level shifter, divider, isolator, or open-drain arrangement rather than treating connector compatibility as electrical compatibility.

Next, follow the energy and signal paths together. A GPIO that reaches a high-load actuator needs a driver stage plus flyback or transient protection; an ADC input needs evidence for source impedance, reference rail, filtering, and sample timing. At an external connector, extend the review to electrostatic discharge, surge, reverse polarity, and miswiring. Finish by testing the powered-off state so an energized peripheral cannot back-feed the controller through a signal pin. This sequence turns the boundary from a parts list into a set of states the design can prove.

The chapter needs visual evidence for signal boundaries. Figure 18.5 provides it: Signal boundary check showing voltage domain, pull behavior, level shift, driver stage, analog filter, connector protection, and back-feed prevention. Examine Controller Domain together with Protection.

+

For signal boundaries, the diagram Figure 18.5 uses Controller Domain as the entry and Protection as a later checkpoint. Finish at logic range. The full reading conveys: Signal boundary check showing voltage domain, pull behavior, level shift, driver stage, analog filter, connector protection, and back-feed prevention.

18.14 Continue to the Next Part

This section: Continue to the Next Part — Carry this evidence into Power and Interfaces: Supply Draw and Bus Choice, which begins with Supply Draw Ledger.

Carry this evidence into Power and Interfaces: Supply Draw and Bus Choice, which begins with Supply Draw Ledger.