Sketch Generator
Build an Arduino/ESP32 sketch skeleton from the peripherals your project needs.
Project peripherals
Check at least one peripheral above to generate the code.
How pins are chosen
Every checked peripheral gets a free pin, with no conflict against the others or against reserved board functions (pins wired to the ESP32's internal flash, for example, are never used). When more than one candidate pin is left, the generator always prefers one with no caveat; it only uses a pin with a warning (e.g., an ESP32 strapping pin) when it's the only option left — and flags that in the generated code itself. The I2C LCD is the one exception: it always uses the board's two fixed I2C bus pins (A4/A5 on Uno/Nano, GPIO21/22 on ESP32), never competing for a pin with the other peripherals.
Libraries the generated code expects
The generated code assumes you already have each needed library installed in the Arduino IDE (Sketch menu → Include Library → Manage Libraries...): "LiquidCrystal I2C" for the LCD, "Servo" (or "ESP32Servo" on the ESP32) for the servo motor, "Adafruit NeoPixel" or "FastLED" for the WS2812 strip, and "DHT sensor library" (Adafruit) for the DHT sensor. None of them is a dependency of this site — only of the sketch you're going to compile.
Can two peripherals compete for the same pin?
It depends on the bus. I2C (this tool's LCD) is shared by nature — several I2C devices split the same two SDA/SCL pins with no conflict, as long as each has a different address on the bus. A regular digital pin (the LED, the button, the HC-SR04's TRIG...) can only serve one peripheral at a time, though — that's why the generator never assigns the same pin twice. Two HC-SR04 sensors, for example, always need 4 digital pins in total (2 each), never 2 shared ones.
Frequently asked questions
It's a real skeleton: setup() already initializes every peripheral correctly (right pin, right library, object instantiated), and reading a sensor (potentiometer, HC-SR04, DHT) already comes ready inside loop() — but what to do with each reading, and how each output (LED, servo, WS2812) should react, is your project's call, marked with a // TODO comment in the right spot.
Assignment is automatic and avoids reserved/flagged pins whenever a free alternative exists — the "obvious" pin (e.g., the Uno's D13, which doubles as the onboard LED) may not be the best choice for your circuit. If you already have a project with fixed physical wiring, just edit the generated code's #define lines to the real pins you used — only the automatic assignment changes, the rest of the code stays correct.
Not in this version — each peripheral is a single checkbox (checked or not), with no quantity counter. For a second HC-SR04 or a second button, copy the matching block in the generated code and adjust the pin/macro names by hand (never reuse the same #define, which would collide).
It means that, for that specific peripheral, every other free pin on the board had some other problem (wrong category, incompatible electrical direction), and the only candidate left carries a usage caveat — usually something that still works but deserves attention (e.g., an ESP32 strapping pin, which sets the boot mode). The comment points to the Pinout Reference so you can understand exactly what that caveat means before wiring the circuit.
Because it doesn't use a dedicated pin — it uses the board's two fixed I2C bus pins (A4/A5 on Uno/Nano, GPIO21/22 on ESP32), the same ones Wire.begin() already expects by default. Those two pins get reserved as soon as the LCD is checked, but they never compete for the general free-pin pool with the other peripherals.
Nexinon Principles
Privacy
Your data never leaves your browser.No account needed
Use it now, no account or password.Free
No usage limits, no paid plan.Trustworthy content
Full explanation behind every tool, not just the result.