Hardware safety

The review baseline above is not a promise about the installer currently being served. Confirm the active version, exact profile, and enabled action on the current firmware and flash page before provisioning or changing hardware.

Qualified firmwaredescribes firmware evidence. The table below describes this lesson's scope; it does not turn designed compatibility into hardware validation.

1. 01

   Power off and identify every exact part

   Disconnect board and peripheral power. Record the full board/carrier name and revision, component part number, supply voltage, signal voltage, and intended connection. Open the exact carrier documentation and each component datasheet—not a pinout for a similar board.

   Stop if: a suffix, board revision, component marking, voltage domain, or pin label is unknown.

2. 02

   Classify the code before choosing pins

   Decide whether the example is portable, capability-configured, or exact-board-only. Portable code assumes no physical peripheral. Capability code requires your explicit pins and circuit. Exact-board code applies only to the named carrier revision.

   Expected: you can name the example class and explain why your exact hardware is or is not in its designed scope.

3. 03

   Build a pin and conflict worksheet

   For each signal, copy the physical header location, GPIO or exact MicroPython pin name, mode, pull state, voltage capability, and shared peripheral use from the exact documentation. Check input-only pins, boot/strapping pins, flash or PSRAM connections, and pins already used by displays, USB, radio, or another device.

   Stop if: a selected pin is reserved, input-only for an output role, a boot/strapping risk, or shared in an incompatible way.

4. 04

   Review the electrical path

   Confirm supply and logic voltage, maximum source/sink current, polarity, component power demand, shared ground, current-limiting resistor or other required protection, and any level shifting or separate supply. Account for startup states before user code configures a pin.

   Stop if: a voltage or current limit is exceeded, grounds cannot be shared safely, or required resistor, protection, or level conversion is missing.

5. 05

   Bound the program before execution

   Read the complete source. Identify its maximum loop count or duration, highest output level, expected physical effect, Console progress, Stop behavior, exception behavior, and final cleanup state. Replace an unbounded effect with a finite test before first power-up.

   Expected: you can state the bounded effect, when to press Stop, and the exact cleanup that returns outputs and power to a safe state.

6. 06

   Wire cold, inspect, then power

   With all power removed, make the reviewed connections. Trace every wire from source to destination against the worksheet, check polarity and protection again, remove loose conductors, then apply power while ready to disconnect it.

   Stop if: the powered board resets, heats, smells unusual, draws unexpected current, or a component behaves before Run.

7. 07

   Run once, observe, Stop, and clean up

   Verify connected identity, choose Run explicitly, and compare the bounded physical and Console observations with the plan. Press Stop on any mismatch. When the test ends, drive outputs to their safe state when possible, disconnect peripheral power, then remove wiring.

   Expected: the finite effect matches the plan and the circuit finishes powered down in the documented cleanup state.