18 Power and Interfaces: Decision Records

18.1 Start With the Decision

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 is part 1 of 2. Continue with Power and Interfaces: Supply Draw and Bus Choice.

18.3 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

• 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

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.

Phoebe’s Field Notes: Why “The Reference And Divider Settle” Is A Real Deadline

The mathematical gist. A 12-bit, 3.3 V ADC has $2^{12}=4096$ codes, so one step is $3.3/4096=0.806$ mV and the ideal quantisation SNR is 74.0 dB. A 5.0 Hz valve signal needs at least 10.0 samples/s. The same input must also settle: a 5.0 pF sample capacitor behind 10 kΩ needs about 0.451 µs, but 100 kΩ needs 4.51 µs. More bits cannot repair a voltage sampled before it settles.

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

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

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

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.

18.9 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.

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.

In the diagram Figure 18.2, State frames the question. RAM changes the responsibility; no motion closes the service and update check. Together they explain the no motion figure claim: 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.

18.10 Wake and Retention Plan

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?

Why pause at wake and retention plan? Beside Deep Sleep vs Light Sleep Comparison, the diagram Figure 18.3 makes 50 - 500 uA explicit within this relationship: Deep Sleep vs Light Sleep Comparison.

Three concrete diagram labels organize Figure 18.3: Deep Sleep vs Light Sleep Comparison, 50 - 500 uA, and LOW POWER. Between them, the wake and retention plan relationship becomes visible: Deep Sleep vs Light Sleep Comparison.

18.11 Interface Ownership

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

“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 Microcontroller I/O Interfaces label opens the diagram Figure 18.4. GPIO marks a different decision point, while I2C Bus prevents an early stop in interface ownership. Together Microcontroller I/O Interfaces and I2C Bus connect to the claim: Microcontroller Input/Output Interfaces.

18.13 Signal Boundaries

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

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