PHASE 01REQUIREMENTS
Before you pick a single part, decide what the board has to do and the limits it has to respect. These are the promises everything else has to keep — cheap to get right now, expensive to fix later.
Requirements are just the promises your board has to keep. The good news is that this board's promises are short and clear: power it from one USB-C port, run an ESP32-S3, bring its pins out to headers, and don't hurt the radio. Nail these down now and the rest of the build is mostly careful bookkeeping.
A USB-C-powered ESP32-S3 breakout: a small, hand-solderable board that brings the module's pins out to breadboard headers.
At the center is **U1**, the ESP32-S3-WROOM-1 — a module (a tiny computer on a single chip) with Wi-Fi and Bluetooth already built in. One USB-C port (**J1**) does two jobs at once: it powers the board and it loads your programs. The S3 can speak USB by itself, so it shows up on your computer and takes firmware directly — there's no separate USB-to-serial 'programmer' chip in the middle. Two snap-apart headers (**J2/J3**) bring the GPIO pins out to a breadboard. That's the whole mission: a clean, reliable way to get your hands on the S3.
| Ref | Part | Role |
|---|---|---|
| U1 | ESP32-S3-WROOM-1-N16R2 | The microcontroller module (native USB) |
| J2 J3 | 1×22 headers | Break the GPIO out to a breadboard |
Why does this board need no separate USB-to-serial programmer chip? Because the ESP32-S3 has native USB built in — it shows up on your computer and takes firmware over the USB-C port directly.
▸Deep dive· Native USB vs a separate bridge chip
Most older microcontrollers can't speak USB at all. They talk a simpler language called serial, so the board needs a little translator chip — something like a CP2102 or CH340 — sitting between the USB port and the chip just to load code. The ESP32-S3 has a USB controller built right into the silicon, so the USB-C port wires almost straight to the module. That's one fewer chip to buy, place, and solder — and you get a few things for free: the same port can act as a serial console and even a hardware debugger. The one tradeoff is that if your own program ever locks up the USB peripheral, you fall back on the BOOT and EN buttons to force the chip into download mode by hand. That's exactly why those two buttons are on the board.
Will the 3.3 V rail hold up when Wi-Fi transmits? Answer that now, on paper — it's a five-minute sum.
USB hands you 5 V. The (a kind of voltage regulator, **U2**) turns that into the 3.3 V the chip needs, at up to 600 mA. The ESP32-S3 sips current most of the time, but it gulps hard for a few milliseconds every time its radio transmits. Add up the worst case — that gulp plus everything else on the board — and make sure it fits under 600 mA with room to spare. That headroom is exactly why the board uses a 600 mA regulator and a 10 µF , not a tiny 150 mA part. Hang hungry loads (a motor, a servo) off the rail later and you invite a — the voltage sagging low enough to reset the chip.
The regulator can supply up to 600 mA. The ESP32 mostly sips current but gulps hard for a few milliseconds each time its radio transmits. What rides out those gulps so the rail doesn't dip? The bulk capacitor (C1) — a little local reservoir of charge, right where it's needed.
▸Deep dive· The power budget, with numbers
Add up the worst case. The ESP32-S3 can peak near 500 mA during a Wi-Fi transmit burst, and the rest of the board — LEDs, the regulator's own draw, anything you hang off the headers — is maybe 50 mA. That's about 550 mA against the 's 600 mA ceiling, leaving only ~50 mA of margin. A tiny 150 mA regulator would the instant Wi-Fi keyed up. The transmit spikes are also far faster than the regulator can react to, so C1, the 10 µF , holds a local pool of charge to cover them while the regulator catches up. Hang a motor or a servo on the rail and you blow the budget — those want their own supply.
On any Wi-Fi-connected ESP32, half the analog pins go dark.
Here's a rule that's easy to honor now and maddening to discover later: can't be used while the radio is active — and on a Wi-Fi board, the radio is basically always active. So every analog input you plan to read has to land on an pin. Decide this now, while you're choosing which pin does what — not at bring-up, when an analog reading comes back as garbage but only when Wi-Fi is on.
You wire a knob to an ADC2 pin and the reading is garbage only when Wi-Fi is on. What rule did you break? Analog inputs you sample must be on ADC1 — ADC2 is claimed by the radio.
▸Deep dive· Why ADC2 goes dark when Wi-Fi is on
The ESP32-S3 has two analog-to-digital converters, and . The Wi-Fi radio borrows ADC2's hardware while it's running, so a program that reads an ADC2 pin with Wi-Fi active gets an error or a meaningless number — and because this is a Wi-Fi board, the radio is essentially always on. The fix is a planning decision, not a code workaround: route anything you'll read as analog to an ADC1 pin (on the S3 those are GPIO1 through GPIO10). Settle it here, while the pins are still just names on a list, and you'll never hit the 'works until I connect to Wi-Fi' bug at bring-up.
Quick check — requirements
You've pinned down what this board has to do — powered and programmed over one USB-C port, a 3.3 V budget that survives a Wi-Fi burst, and the ADC1-only rule. Write those decisions up as your requirements note and attach it, then pass the quick check above. That's the gate — no formal design-review checklist on a build this size.