Why the ESP32 became my favorite blank page

Every maker has a default. Some people reach for a notebook, some for a whiteboard. When an idea shows up at 11 p.m., I reach for an ESP32 dev board.

It wasn't always that way. My career started in avionics and electronics, then spent two decades in networks, data centers and enterprise systems. Hardware was something I supported, not something I made. The ESP32 is what pulled me back to the bench, and I want to explain why it earned the job.

A whole system on one cheap chip

The classic ESP32 gives you two 240 MHz cores, roughly half a megabyte of SRAM, Wi-Fi, Bluetooth, and a long list of peripherals: ADCs, DACs, PWM, I²C, SPI, UART, capacitive touch, a pulse counter and a remote-control peripheral that's great for generating odd timing. Newer parts in the family trade some of that for other strengths:

• ESP32-S3 adds native USB and vector instructions that help with small ML and DSP jobs.
• ESP32-C3 / C6 move to RISC-V cores, and the C6 adds Wi-Fi 6 and an 802.15.4 radio for Thread and Zigbee.

For a prototype, that means one part number covers the controller, the radio and a lot of the glue logic. Fewer chips is fewer decisions, and fewer decisions means you get to the interesting part faster.

The network engineer in me loves the radio

I spent years making sure 3,000 hospital users could reach their applications no matter what. So the first thing I notice on any board is: how does it talk to the world?

With an ESP32 the answer is "however you want." Serve a small web page for configuration. Push readings to a FastAPI endpoint. Use ESP-NOW for low-latency device-to-device messages without an access point. Bridge to a LoRa radio for distance. The radio stops being a feature you bolt on and becomes part of the design from day one.

The toolchain grows with you

You can start in Arduino in ten minutes and graduate to ESP-IDF and FreeRTOS when you need real control over tasks, memory and power. Or try MicroPython when you want to poke at hardware interactively. The same chip carries you from "blink an LED" to "shipping product firmware," and that continuity matters. You don't throw away what you learned.

What it taught me about constraints

Half a megabyte of RAM forces honesty. You can't hide a sloppy data model behind a gigabyte of headroom. You think about:

• Which data lives in RAM and which goes to flash.
• Which work happens in an interrupt and which gets deferred to a task.
• What happens when the Wi-Fi drops in the middle of a write.

Those are the same questions I asked about Citrix farms and failover pairs — just at a much smaller scale.

When I don't reach for it

The ESP32 isn't the right answer every time, and pretending it is would be bad engineering:

• Ultra-low-power, battery-for-years sensors. It can sleep efficiently, but radios are hungry. A smaller MCU plus a dedicated low-power radio may win.
• Hard real-time, cycle-exact I/O. The RP2350's PIO state machines are hard to beat for bit-banged protocols.
• No radio needed at all. Then you're paying for and powering silicon you don't use.

I'll dig into that comparison in a later note.

The real reason

Honestly? It's the feedback loop. Idea, wire, flash, test, change, flash again — sometimes thirty times in an evening. Few platforms make the loop between thinking and seeing that short. That loop is where SolveBlock came from, and where most of what I write about here comes from.

If you have an idea and a $10 dev board, you're closer than you think.