wedsamuel1230/arduino-skills/wiring-safety-check

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

1. Draw a rail and ground map, including USB/VIN/VSYS/3V3 paths and regulators.
2. 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.

1. Calculate steady and peak current with regulator, connector, wiring, and

thermal margin. Do not add per-pin absolute maxima into a board budget.

1. Check pull-ups for bus voltage, value, rise time, fanout, and duplicate

resistors. Check I2C/SPI/UART default pins against the board profile.

1. Add level shifting, divider, transistor/MOSFET driver, flyback protection,

decoupling, or isolation when the electrical contract requires it.

1. Define safe reset and fault states before enabling an output or motor.
2. 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

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.