Wiring Safety Check
Check the electrical contract before code or power is applied. A board's input
voltage or per-pin maximum does not prove that a connected signal or total rail
is safe.
Intake
Record the exact board/module and logic voltage, sensor/actuator part number,
each rail, signal direction, VIH/VIL/input maximum, current and startup peak,
pull-up location/value, ground path, cable length, protection, default state,
and whether a level shifter, driver, flyback path, fuse, or current limiter is
present.
Process
- Draw a rail and ground map, including USB/VIN/VSYS/3V3 paths and regulators.
- Check every signal in both directions. A 5 V supply does not imply 5 V-safe
I/O; a 3.3 V MCU input must not receive an out-of-range high level.
- Calculate steady and peak current with regulator, connector, wiring, and
thermal margin. Do not add per-pin absolute maxima into a board budget.
- Check pull-ups for bus voltage, value, rise time, fanout, and duplicate
resistors. Check I2C/SPI/UART default pins against the board profile.
- Add level shifting, divider, transistor/MOSFET driver, flyback protection,
decoupling, or isolation when the electrical contract requires it.
- Define safe reset and fault states before enabling an output or motor.
- Stop at the physical gate until continuity, polarity, rail, and load
measurements are captured.
Required 5 V to ESP32 result
When a user says only "wire a 5 V sensor to ESP32", flag the missing level
compatibility immediately: ESP32 GPIO is 3.3 V class and is not generally 5 V
tolerant. Ask for the sensor's actual I/O levels and require a suitable level
shifter or divider for any 5 V signal entering the ESP32. A shared ground does not solve level incompatibility. Check whether the sensor accepts a 3.3 V supply
and whether its output is open-drain before choosing the circuit.
Anti-rationalization
| Shortcut |
Response |
| "It is a 5 V sensor, so its data pin is safe." |
Inspect the sensor datasheet and flag level shifting for a 5 V high. |
| "A shared ground fixes it." |
Ground reference is necessary but does not change logic thresholds. |
| "20 mA per pin is the board budget." |
Check rail, regulator, connector, total load, and peak current. |
| "The LED or motor is small." |
Check inrush, stall current, inductive kick, and driver topology. |
| "I already powered it." |
Stop, inspect, and record measurements; do not infer safety from survival. |
Verification
- Wiring table names source/destination, voltage, direction, and protection.
- Level-shifting and pull-up decisions cite a datasheet or are explicitly
unresolved.
- Continuity/polarity and unloaded/load rail measurements are captured.
- Build/upload evidence is not promoted to hardware or system proof.
Shared output contract
Use the shared Arduino skill contract:
state assumptions, required tools and versions, implementation steps,
tests/evidence by proof stage, known limitations, and recovery/security notes.
1---2name: wiring-safety-check3description: Use when wiring an Arduino, ESP32, ESP32-S3, Pico, or Pico W to sensors, LEDs, motors, relays, buses, or external supplies, especially when 5 V and 3.3 V logic, current limits, pull-ups, level shifting, inductive loads, or safe defaults matter.4---5
6# Wiring Safety Check
7
8Check the electrical contract before code or power is applied. A board's input
9voltage or per-pin maximum does not prove that a connected signal or total rail
10is safe.
11
12## Intake
13
14Record the exact board/module and logic voltage, sensor/actuator part number,
15each rail, signal direction, VIH/VIL/input maximum, current and startup peak,
16pull-up location/value, ground path, cable length, protection, default state,
17and whether a level shifter, driver, flyback path, fuse, or current limiter is
18present.
19
20## Process
21
221. Draw a rail and ground map, including USB/VIN/VSYS/3V3 paths and regulators.
232. Check every signal in both directions. A 5 V supply does not imply 5 V-safe
24 I/O; a 3.3 V MCU input must not receive an out-of-range high level.
253. Calculate steady and peak current with regulator, connector, wiring, and
26 thermal margin. Do not add per-pin absolute maxima into a board budget.
274. Check pull-ups for bus voltage, value, rise time, fanout, and duplicate
28 resistors. Check I2C/SPI/UART default pins against the board profile.
295. Add level shifting, divider, transistor/MOSFET driver, flyback protection,
30 decoupling, or isolation when the electrical contract requires it.
316. Define safe reset and fault states before enabling an output or motor.
327. Stop at the physical gate until continuity, polarity, rail, and load
33 measurements are captured.
34
35## Required 5 V to ESP32 result
36
37When a user says only "wire a 5 V sensor to ESP32", flag the missing level
38compatibility immediately: ESP32 GPIO is 3.3 V class and is not generally 5 V
39tolerant. Ask for the sensor's actual I/O levels and require a suitable level
40shifter or divider for any 5 V signal entering the ESP32. A shared ground does not solve level incompatibility. Check whether the sensor accepts a 3.3 V supply
41and whether its output is open-drain before choosing the circuit.
42
43## Anti-rationalization
44
45| Shortcut | Response |
46|---|---|
47| "It is a 5 V sensor, so its data pin is safe." | Inspect the sensor datasheet and flag level shifting for a 5 V high. |
48| "A shared ground fixes it." | Ground reference is necessary but does not change logic thresholds. |
49| "20 mA per pin is the board budget." | Check rail, regulator, connector, total load, and peak current. |
50| "The LED or motor is small." | Check inrush, stall current, inductive kick, and driver topology. |
51| "I already powered it." | Stop, inspect, and record measurements; do not infer safety from survival. |
52
53## Verification
54
55- Wiring table names source/destination, voltage, direction, and protection.
56- Level-shifting and pull-up decisions cite a datasheet or are explicitly
57 unresolved.
58- Continuity/polarity and unloaded/load rail measurements are captured.
59- Build/upload evidence is not promoted to hardware or system proof.
60
61## Shared output contract
62
63Use [the shared Arduino skill contract](../../docs/arduino-skill-contract.md):
64state assumptions, required tools and versions, implementation steps,
65tests/evidence by proof stage, known limitations, and recovery/security notes.
wedsamuel1230