TunaTek ESP32

Serial monitor and debugging on the ESP32: stop guessing

2026-10-07T00:00:00+00:00

When something does not work, the temptation is to change code blindly. That makes it worse. What really saves time is seeing what is happening. And for that you have the serial monitor and logs.

The serial monitor, properly configured

void setup() {
  Serial.begin(115200);
  Serial.println("Starting…");
}

Three things almost everyone forgets:

The baud rate must match (115200 is the standard). If you see ��, it does not.
After Serial.begin() give it a moment before printing; the first lines are sometimes lost.
The monitor resets the board when it opens in many setups: do not panic if it “boots on its own”.

If you see nothing:

Is the monitor on the right port?
Does the board use native USB (S3/C3) and you are watching the wrong port?
Did you close another program holding the port open?

Leveled logs (if you use ESP-IDF)

Instead of printf everywhere, use levels:

#include "esp_log.h"
static const char *TAG = "app";

ESP_LOGI(TAG, "info");
ESP_LOGW(TAG, "warning");
ESP_LOGE(TAG, "error");

You can raise or lower the level per component from menuconfig, and in production keep only errors. A printf does not give you that.

The messages that are telling you the problem

On boot, the ESP32 prints a lot of useful information:

rst:0x... → why it reset: power-on, watchdog, panic, brownout.
Brownout detector was triggered → not enough power. Change the cable, the USB port, or add a capacitor.
Guru Meditation Error → a panic. Below it comes a backtrace with addresses; with idf.py monitor it is translated to function names for you.
Task watchdog got triggered → your loop() or a task got stuck.

Learning to read those four lines solves half the problems.

Techniques that work

Bisection: comment out half the code. The problem is in the other half. Repeat.
Strategic Serial.println: mark where it passes, not random values. Better [sensor] read: %d.
Status LED: a fast-blinking LED = “I am here”. No monitor needed.
Multimeter: measure power and levels before blaming the code.
Logic analyzer (cheap): essential for I2C/SPI. Seeing the bus is another level.
JTAG (S3/C3): real breakpoints when the bug is slippery.

Typical mistakes

Changing code at random without watching the monitor.
Ignoring a brownout thinking it is software.
Not reading the backtrace (the exact line is there).
Using delay() in the loop and hitting the watchdog.
Debugging at 9600 baud and expecting everything to come out.

A `loop()` that does not block (and does not trip the watchdog)

unsigned long last = 0;

void loop() {
  if (millis() - last >= 1000) {
    last = millis();
    // heavy work here
  }
  // the rest of the time, breathe
}

Summary

Set the monitor to 115200 and check port and speed.
Use leveled logs (ESP-IDF) instead of loose printfs.
rst:, brownout, backtrace and watchdog tell you what is wrong; learn them.
Bisection + status LED + multimeter solve most cases.
For buses (I2C/SPI), a logic analyzer is worth its weight in gold.
When the bug hides, JTAG (S3/C3).

Next step: with this you close Introduction to the ESP32. From here you can continue to Explore or go back to the series hub.

Reading a push button properly: pull-up, debounce and interrupts

2026-10-06T00:00:00+00:00

Reading a button sounds like the easiest thing in the world: digitalRead() and done. Then the usual happens: one press counts as five, or the pin reads random noise while nobody is touching it. Both have an explanation and a fix.

First: never leave a pin “floating”

If you wire a button between the pin and 3V3 with nothing else, when it is not pressed the pin floats and reads garbage. You need a resistor to pull it to a known level:

Pull-up: the pin is HIGH at rest; pressing pulls it to GND. What I use almost always.
Pull-down: the pin is LOW at rest; pressing pulls it to 3V3.

The ESP32 has an internal pull-up, so you usually do not need a resistor:

constexpr int BTN = 4;

void setup() {
  Serial.begin(115200);
  pinMode(BTN, INPUT_PULLUP);   // rest = HIGH, pressed = LOW
}

void loop() {
  if (digitalRead(BTN) == LOW) {
    Serial.println("pressed");
  }
}

Careful: GPIO34–39 have no internal pull-up (input only). If you use one of those, you need an external resistor.

Why it “bounces” (and why you see 5 presses)

A button does not go cleanly from HIGH to LOW. For a few milliseconds it makes and breaks contact several times. The ESP32, running at 240 MHz, sees it all. That is bounce.

Software debounce (my favourite)

constexpr int BTN = 4;
constexpr unsigned long DEBOUNCE_MS = 30;

bool stable = HIGH;
bool last = HIGH;
unsigned long change = 0;

void loop() {
  bool reading = digitalRead(BTN);
  if (reading != last) {
    change = millis();
    last = reading;
  }
  if (millis() - change > DEBOUNCE_MS && reading != stable) {
    stable = reading;
    if (stable == LOW) Serial.println("valid press");
  }
}

The idea: you only accept a change if it stays stable for 30 ms. That is enough for 99 % of buttons.

Hardware debounce

If the button is critical or noisy, an RC (10 kΩ + 100 nF) and, if needed, a Schmitt trigger (74HC14) fix it. More parts, but zero code.

Interrupts: powerful and dangerous

With attachInterrupt() the ESP32 runs your function instantly. Great for not missing presses, but it has rules:

volatile bool pressed = false;

void IRAM_ATTR onPress() {   // IRAM_ATTR: it must live in IRAM
  pressed = true;
}

void setup() {
  pinMode(BTN, INPUT_PULLUP);
  attachInterrupt(digitalPinToInterrupt(BTN), onPress, FALLING);
}

void loop() {
  if (pressed) {
    pressed = false;
    Serial.println("interrupt");
  }
}

Golden rules:

The shared variable must be volatile.
The function must be IRAM_ATTR (otherwise it can fail with Wi-Fi).
Do not do heavy work inside the ISR: set a flag and handle it in loop(). No Serial.print or delay in there.
Even with an interrupt, bounce still exists: debounce anyway.

Typical mistakes

A button with no pull-up and pins reading noise → you think the ESP32 is broken.
Using GPIO34–39 for a button and discovering there is no internal pull-up.
Putting Serial.println inside the ISR → random hangs.
Forgetting volatile → the compiler “optimizes” and the flag never changes.
No debounce and counting 5 presses per press.

Summary

Never leave an input pin floating: use INPUT_PULLUP.
Buttons bounce; 30 ms of debounce fixes it.
Interrupts: volatile, IRAM_ATTR, minimal work and debounce too.
GPIO34–39 have no pull-up: external resistor required.
With hardware (RC + Schmitt) you save code if the noise is serious.

Next step: serial monitor and basic debugging, to stop guessing why it is not working. Or go back to the series hub.

Getting started with ESP32: blink an LED

2026-10-05T00:00:00+00:00

The hardware Hello World is blinking an LED. It is a simple ritual, but it touches every important part of a new board: power, toolchain, GPIO and flashing.

What you need

Item	Detail
Board	ESP32 DevKitC, ESP32-WROOM-32 or similar
LED	Any color, ~2 V forward drop
Resistor	220 Ω to 330 Ω
Software	PlatformIO (recommended) or Arduino IDE 2.x

Tip: many DevKits already ship an LED on GPIO2. You can use it to test without wiring anything, though it is usually inverted.

The pinout in two minutes

The ESP32 has GPIOs numbered 0 to 39, but not all are usable:

GPIO6–GPIO11 are wired to the SPI flash. Do not touch them.
GPIO34–GPIO39 are input only (no internal pull-up).
GPIO1 (TX0) and GPIO3 (RX0) are used by the serial port.
GPIO0 selects the boot mode; avoid using it as an output.

For an LED, any output GPIO works. We will use GPIO2.

Arduino code

The Arduino core makes startup trivial:

#include <Arduino.h>

constexpr int LED_PIN = 2;

void setup() {
  pinMode(LED_PIN, OUTPUT);
}

void loop() {
  digitalWrite(LED_PIN, HIGH);
  delay(1000);
  digitalWrite(LED_PIN, LOW);
  delay(1000);
}

`delay()` blocks (and sometimes that matters)

delay() halts the whole CPU. For a blink it is fine, but as soon as you add Wi-Fi or several sensors you will want millis():

unsigned long last = 0;
constexpr unsigned long INTERVAL = 1000;

void loop() {
  if (millis() - last >= INTERVAL) {
    last = millis();
    digitalWrite(LED_PIN, !digitalRead(LED_PIN));
  }
}

The same in ESP-IDF (Rust)

If you prefer Rust, the esp-idf-hal crate offers a typed API. A blink with esp-idf-svc looks like this:

use esp_idf_svc::hal::delay::FreeRtos;
use esp_idf_svc::hal::gpio::PinDriver;
use esp_idf_svc::hal::peripherals::Peripherals;

fn main() -> anyhow::Result<()> {
    esp_idf_svc::sys::link_patches();
    let peripherals = Peripherals::take()?;
    let mut led = PinDriver::output(peripherals.pins.gpio2)?;

    loop {
        led.set_high()?;
        FreeRtos::delay_ms(1000);
        led.set_low()?;
        FreeRtos::delay_ms(1000);
    }
}

The big difference: in Rust the compiler forces you to declare the pin as an output before writing to it. Many hardware mistakes vanish at compile time.

PlatformIO setup

A minimal platformio.ini for the Arduino core:

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
monitor_speed = 115200

And for Rust with esp-idf:

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = espidf
monitor_speed = 115200

Troubleshooting

It will not flash / board not found. Install the cp210x or ch34x drivers matching your board’s USB chip.
It flashes but does not blink. Check the LED polarity and the resistor.
It reboots in a loop. Usually a power issue: use a USB port that can deliver at least 500 mA.

Next step

With GPIO under control you have the essentials. The natural next jump is connectivity (Wi-Fi, MQTT), which we will cover on the blog. For now you can move on to serial monitor and debugging or go back to the series hub.

VS Code + ESP-IDF: the official environment with JTAG included

2026-10-04T00:00:00+00:00

If you have decided to use ESP-IDF, the official VS Code extension gives you the best of both worlds: a modern editor and real JTAG debugging.

Installation

In VS Code, install the ESP-IDF extension (by Espressif).
Run the setup wizard (ESP-IDF icon → Setup). The extension downloads ESP-IDF, the toolchain and Python.
Pick the version: today ESP-IDF 6.1.

It takes a while because it downloads everything (ESP-IDF is big). That is normal.

Create a project

ESP-IDF: New Project → template (sample_project, blink…), name and chip. The layout is ESP-IDF’s:

my-project/
├── CMakeLists.txt
├── sdkconfig
└── main/
    ├── CMakeLists.txt
    └── main.c

`menuconfig` from VS Code

ESP-IDF: SDK Configuration Editor opens menuconfig in an integrated web view: change options, search by text and it saves sdkconfig. Much nicer than the terminal.

Build, flash and monitor

The bottom bar has the buttons:

Build, Flash, Monitor and Build + Flash + Monitor.
Serial port and monitor speed selection.
Target selection (esp32, esp32s3, esp32c3…).

It is equivalent to:

idf.py build
idf.py -p /dev/ttyUSB0 flash monitor

JTAG debugging

Here is the gem. With an ESP32-S3/C3 board (and its native USB) or an external probe, you get breakpoints, step over, variable inspection and call stacks — no printf.

In ESP-IDF it is set up with idf.py openocd, and the extension integrates it. This is one of the biggest time savers when a bug refuses to show itself.

Extensions that pair well

C/C++ (IntelliSense) — the extension configures it.
clang-format — automatic formatting on save.
Error Lens — errors inline, without opening the console.

When to choose it

Yes: you are serious about ESP-IDF, want a comfortable menuconfig and JTAG debugging.
No: if you use Arduino or MicroPython (not applicable) or the command line is enough.

Summary

The ESP-IDF extension installs the SDK and the toolchain for you.
Integrated menuconfig, with search.
Build/flash/monitor buttons and chip/port selection.
JTAG for real debugging (S3/C3 or an external probe).
Current ESP-IDF version: 6.1.

Next step: the hands-on block: blink an LED with what you already have set up. Or go back to the series hub.

VS Code + PlatformIO for ESP32: the environment I use every day

2026-10-03T00:00:00+00:00

If I had to keep just one environment for the ESP32, it would be this one. PlatformIO turns VS Code into a real IDE: build, upload, monitor and debugging, with the project config in a text file.

Installation

Install VS Code.
In Extensions, search PlatformIO IDE and install it.
Wait for it to prepare the toolchain the first time.

That is it. PlatformIO downloads compilers and tools for you.

Create a project

PlatformIO Home → New Project: name, board (Espressif ESP32 Dev Module) and framework (Arduino or ESP-IDF). The structure it generates:

my-project/
├── platformio.ini     # configuration
├── src/main.cpp       # your code
└── lib/               # your own libraries

`platformio.ini`: the heart

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
monitor_speed = 115200
upload_speed = 921600

Switching board is changing one line. This is gold when you have several projects:

[env:s3]
platform = espressif32
board = esp32-s3-devkitc-1
framework = arduino
monitor_speed = 115200

[env:c3]
platform = espressif32
board = esp32-c3-devkitm-1
framework = arduino

Pick the environment in the bottom bar and upload.

Upload and monitor

In the status bar:

✓ Build — compile.
→ Upload — compile and flash.
🔌 Serial Monitor — open the monitor at your configured baud.

Or from the terminal:

pio run -t upload
pio device monitor

Per-project libraries

Instead of installing them globally, you declare them:

lib_deps =
    adafruit/Adafruit BME280 Library@^2.2.4
    knolleary/PubSubClient@^2.8

Huge advantage: the project carries its own versions. If a library breaks tomorrow, your code stays the same.

Debugging

With a board that supports it (ESP32-S3/C3) and a JTAG probe:

debug_tool = esp-builtin

And you get real breakpoints, not printf. It is the quality jump once the project grows.

What I like (and what I do not)

Pros: one environment for almost everything, versionable config, per-project dependencies, real debugging, cross-platform.

Cons: the first build downloads a lot; and if you are new, there are more concepts than in the Arduino IDE.

Summary

Install PlatformIO IDE in VS Code and forget the rest.
All configuration lives in platformio.ini (versionable).
lib_deps pins libraries per project, not globally.
Switching board is one line: great for one env per variant.
With JTAG you get real debugging.

Next step: VS Code + ESP-IDF if you go deep with the official SDK. Or go back to the series hub.

Arduino IDE 2.x for ESP32: step-by-step setup (and the usual errors)

2026-10-02T00:00:00+00:00

Arduino IDE 2.x is the fastest way to get an LED blinking. It has known friction (boards, drivers, port), so here is the guide with the usual stumbles already solved.

1. Install the IDE

Download it from arduino.cc (2.x). It includes the editor, library manager, serial monitor and board manager.

2. Add ESP32 support

In File → Preferences → Additional boards manager URLs, paste:

https://espressif.github.io/arduino-esp32/package_esp32_index.json

Then go to Boards Manager, search esp32 and install esp32 by Espressif Systems. It takes a while: hundreds of MB.

3. Pick the right board

In Tools → Board, choose yours:

ESP32 Dev Module → the classic.
ESP32S3 Dev Module, ESP32C3 Dev Module, etc. → the variant.
ESP32-WROVER only if the module has PSRAM.

Pick the wrong board and it usually compiles and uploads, but does not run or boot-loops. It is the number one mistake.

4. The serial port and the drivers

Here is where 90 % of the problems live. Check which USB-serial chip your board uses:

Chip	Driver
CP2102 (Silicon Labs)	CP210x VCP
CH340 / CH341 (WCH)	CH341SER
Native USB (S3/C3/C6)	no driver needed

If the port does not show in Tools → Port, it is the driver. On Linux you may also need to be in the dialout group.

5. Upload the first program

void setup() {
  Serial.begin(115200);
  pinMode(2, OUTPUT);
}

void loop() {
  digitalWrite(2, !digitalRead(2));
  delay(500);
  Serial.println("blink");
}

Hit Upload. If it hangs at Connecting..., hold BOOT for a couple of seconds; that is the classic trick.

6. The serial monitor

Open it with the magnifier icon and set 115200 baud. If you see garbage (“��”), the speed does not match.

Typical errors and their cause

Symptom	Usual cause
“No such file” or missing port	USB-serial driver
Endless `Connecting........`	BOOT button, bad cable or wrong board
Uploads but does nothing	Wrong board (variant)
Boot loop	Not enough power or `GPIO12` held high
Garbage in the monitor	Baud rate not 115200

Settings that save time

Enable “Show verbose output during: upload” when something fails: it tells the truth.
Use a fixed port name if you have several boards.
Save your favourite boards so you do not pick each time.
For big projects, move to VS Code + PlatformIO: the Arduino IDE falls short.

Summary

Install the IDE and add Espressif’s board URL.
Install “esp32 by Espressif” from the Boards Manager.
Pick the right board (this breaks more projects than code).
Solve the USB-serial chip driver.
Upload, open the monitor at 115200 and enjoy.

Next step: VS Code + PlatformIO when the project grows. Or go back to the series hub.

Which IDE should you use for the ESP32? Arduino IDE, VS Code and friends

2026-10-01T00:00:00+00:00

Choosing an IDE looks like a small decision and it is not: it is where you will spend hundreds of hours. The good news is that the choice depends almost entirely on the framework you picked.

The table

IDE	Ideal framework	Pros	Cons
Arduino IDE 2.x	Arduino	Simple, all included	Limited, no real debugging
VS Code + PlatformIO	Arduino, ESP-IDF, Rust, MicroPython	Powerful, multi-board, debugging	More setup
VS Code + ESP-IDF	ESP-IDF	Official, JTAG, menuconfig	ESP-IDF only
Thonny	MicroPython	Great to start	MicroPython only
CLion / RustRover	Rust	Top refactor and debugging	Commercial / heavy

Arduino IDE 2.x

It is the “open and it works” option. Add the board URL, pick the board, hit upload. Done.

Pros: zero friction, built-in library manager.
Cons: weak editor, no serious IntelliSense, no JTAG debugging, and it struggles with large projects.
Ideal for: learning, small sketches, workshops.

VS Code + PlatformIO

My general recommendation. PlatformIO turns VS Code into a real IDE:

One environment for Arduino, ESP-IDF, Rust or MicroPython, with the same flow (build / upload / monitor).
platformio.ini: the project config is text, versionable.
Cross-platform and multi-board: switch from ESP32 to ESP8266, STM32 or RP2040.
Debugging with debug_tool and the right hardware.
Per-project dependency management (not global).

Ideal for: almost everything, especially if you will have several projects.

VS Code + the ESP-IDF extension

If you pick ESP-IDF, this is the official option: it integrates idf.py, menuconfig, the serial monitor and JTAG debugging inside VS Code.

Pros: official, real JTAG, Kconfig one click away.
Cons: it is meant only for ESP-IDF; the flow differs a bit from PlatformIO.
Ideal for: serious ESP-IDF projects.

Thonny (MicroPython)

For MicroPython, Thonny is the friendliest thing around: one button to flash the firmware, a built-in REPL and a file browser for the board.

Ideal for: teaching, learning, quick prototypes.

CLion / RustRover / VS Code (Rust)

If you program in Rust, the flow is cargo + espflash, so almost any editor works. VS Code with rust-analyzer is enough; CLion adds better refactoring and debugging.

How to choose (without getting it wrong)

If you use…	Use…
Arduino core	VS Code + PlatformIO (or Arduino IDE to start)
ESP-IDF	VS Code + ESP-IDF
MicroPython	Thonny
Rust	VS Code + `rust-analyzer`
Several frameworks	VS Code + PlatformIO

You do not have to decide forever: VS Code + PlatformIO covers almost every framework, so you can start there and add the ESP-IDF extension when you need it.

Extras that make a difference

Serial monitor with colors and timestamps: that is 30 % of your working time.
JTAG debugging (ESP32-S3/C3): real breakpoints, not printf.
Automatic formatting (clang-format) and linting.
Integrated Git: firmware deserves version control too.

Summary

Arduino IDE 2.x: start fast. PlatformIO: the most complete and versatile. VS Code + ESP-IDF: the official one for ESP-IDF. Thonny: MicroPython.
Choose based on your framework, not habit.
PlatformIO is the safest bet if you will touch several frameworks.
JTAG debugging is the quality jump once the project grows.

Next step: Arduino IDE 2.x step by step or VS Code + PlatformIO. Or go back to the series hub.

Rust on the ESP32: esp-idf-hal, esp-hal and embassy without drama

2026-09-30T00:00:00+00:00

Rust on the ESP32 stopped being an experiment a while ago. Today the esp-rs ecosystem is stable and surprisingly pleasant, with one huge advantage: the compiler saves you from memory and concurrency bugs that cost you an afternoon of debugging in C.

The trade-off: you have to learn Rust and set up a separate toolchain.

Two paths, not one

Path	What it is	Best for
`esp-idf-hal`	Rust on top of ESP-IDF, with `std`	Reusing ESP-IDF, Wi-Fi, larger projects
`esp-hal`	`no_std`, without ESP-IDF	Total control, small binaries, async
`embassy`	Async framework on `esp-hal`	Elegant concurrent tasks

The rule: if you want easy Wi-Fi and Espressif APIs, esp-idf-hal. If you want to squeeze everything and do not mind no_std, esp-hal + embassy.

Toolchain

The official installer is espup:

cargo install espup
espup install          # installs Xtensa and RISC-V targets
. $HOME/export-esp.sh  # or the script it generates

And to flash, cargo-espflash:

cargo install cargo-espflash
cargo espflash flash --monitor

Current HAL version: esp-hal 1.2.0.

Example: blink with `esp-idf-hal` (with `std`)

use esp_idf_svc::hal::delay::FreeRtos;
use esp_idf_svc::hal::gpio::PinDriver;
use esp_idf_svc::hal::peripherals::Peripherals;

fn main() -> anyhow::Result<()> {
    esp_idf_svc::sys::link_patches();
    let peripherals = Peripherals::take()?;
    let mut led = PinDriver::output(peripherals.pins.gpio2)?;

    loop {
        led.set_high()?;
        FreeRtos::delay_ms(1000);
        led.set_low()?;
        FreeRtos::delay_ms(1000);
    }
}

Notice the detail: the compiler forces you to declare the pin as an output before writing. In C, a forgotten pinMode is a silent bug; here it does not compile.

Async with `embassy`

The best part of the no_std path is embassy: real asynchronous tasks, with no loop() and no hand-written state machines.

#[embassy_executor::task]
async fn blink(mut led: Output<'static, Gpio2>) {
    loop {
        led.toggle();
        Timer::after_millis(500).await;
    }
}

Two tasks “sleeping” at the same time without blocking each other: that is the modern way to write concurrent firmware.

Real advantages

Safety: no use-after-free, no data races, no null.
Honest concurrency: if it compiles, it usually does not stomp memory.
Small binaries in no_std.
cargo: dependencies, tests and docs in one place.

Downsides

Learning curve for Rust (borrows, async, no_std).
Younger ecosystem than Arduino: fewer ready-made libraries.
Separate toolchain: espup, targets, a specific Rust version.
Fewer examples and tutorials than in C/C++.

When to choose it?

Yes:

You care about reliability and want fewer weird bugs.
You already know Rust (or want to learn it properly).
You need real async or very small binaries.
It is a long-term project where maintenance matters.

No:

It is your first contact with microcontrollers: start with Arduino or MicroPython.
You need a specific library that only exists in C++.
You are in a hurry.

Summary

Two paths: esp-idf-hal (with std, on ESP-IDF) and esp-hal (no_std), plus embassy for async.
Toolchain with espup and flashing with cargo-espflash.
The compiler prevents errors that are silent in C.
esp-hal is on 1.2.0 and the ecosystem is now mature.
It is worth it if you care about maintenance and safety.

Next step: a change of scene with the IDEs: which one to use and why. Or go back to the series hub.

MicroPython and Lua on the ESP32: programming without compiling

2026-09-29T00:00:00+00:00

There is a way to program the ESP32 where you compile nothing: you flash a firmware, open a console and type Python. In five minutes you have an LED blinking. It is called MicroPython and it is the best on-ramp there is.

The other side: it is slower and not everything is covered. Let’s be honest about it.

What MicroPython is

It is a Python 3 implementation made for microcontrollers. It is small, fits on the ESP32 and gives you a REPL (interactive console) over USB or Wi-Fi.

Flash and connect

Install it with esptool (the firmware is published by micropython.org):

esptool.py --chip esp32 -p /dev/ttyUSB0 erase_flash
esptool.py --chip esp32 -p /dev/ttyUSB0 write_flash -z 0x1000 esp32-*.bin

And to talk to the board, mpremote:

mpremote connect /dev/ttyUSB0
>>> import machine, time
>>> led = machine.Pin(2, machine.Pin.OUT)
>>> while True:
...     led.value(not led.value()); time.sleep(1)

That is it. No compiling, no setup(), no loop(). Perfect for learning.

Upload your code

The ESP32 shows up as a file system (with boot.py and main.py):

mpremote cp main.py :main.py     # copy
mpremote run main.py             # run without copying

main.py runs automatically on boot.

The good

Minimal curve if you know Python (or if you do not).
Instant iteration: try a line and see the result.
Great for teaching and for workshops.
Good modules: machine, network, time, socket, json.

The bad (important)

Speed: it is interpreted, so forget fine timing or audio/video processing.
Memory: the interpreter takes part of the RAM; PSRAM helps, but it is not C.
Peripherals: not every ESP32 feature is exposed. If one is missing, you usually drop to C.
Real time: no real priority tasks like in FreeRTOS.
Production: for a serious product, you almost always end up in C/C++ or Rust.

And Lua (NodeMCU)?

It was popular with the ESP8266. Today it is largely parked: less support, fewer libraries, and MicroPython is nicer and more alive. For new projects, I do not recommend it.

Quick comparison

	MicroPython	Arduino	ESP-IDF
Compile	No	Yes	Yes
Speed	Low	High	High
Available RAM	Less	Lots	Lots
Tasks	No	1 loop	N tasks
Curve	Very low	Low	High
Best for	Learning, prototypes	Everything	Products

When to use it (and when not to)

Yes:

You are learning or teaching.
You want to try an idea in 10 minutes.
The project is a sensor that publishes and does not need speed.

No:

You need precise timing or DSP.
You are going to production with memory or power constraints.
You need a peripheral that is not exposed in Python.

Summary

MicroPython: Python on the ESP32, no compiling, with a REPL and a file system. Current version: 1.29.
It is the best way to start and to prototype fast.
It is slower and uses more RAM: it does not fit everything.
Lua/NodeMCU is no longer worth it for new projects.
You can start in MicroPython and drop to C/Rust when the project demands it.

Next step: Rust on the ESP32, the other extreme: maximum safety and control. Or go back to the series hub.

ESP-IDF in depth: projects, tasks, logs and partitions

2026-09-28T00:00:00+00:00

If the Arduino core hides the ESP32, ESP-IDF shows you everything. It is Espressif’s official SDK and the base everything else is built on. It has a steeper curve, yes, but it also gives you the control a product needs.

Let’s cover what matters without drowning in docs.

Project layout

my-project/
├── CMakeLists.txt          # project (almost always the same)
├── sdkconfig               # generated configuration
└── main/
    ├── CMakeLists.txt      # registers main
    └── main.c

The root CMakeLists.txt:

cmake_minimum_required(VERSION 3.16)
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
project(my-project)

And the one in main/:

idf_component_register(SRCS "main.c"
                       INCLUDE_DIRS ".")

The commands you will use

idf.py set-target esp32s3   # pick the chip
idf.py menuconfig           # configure (Kconfig)
idf.py build                # compile
idf.py flash monitor        # flash and open the monitor

menuconfig is one of the best things in ESP-IDF: you change options (Wi-Fi, logs, partitions, PSRAM) without touching code, and they are stored in sdkconfig.

Hello world with logs

#include "esp_log.h"

static const char *TAG = "app";

void app_main(void) {
    ESP_LOGI(TAG, "Starting…");
    ESP_LOGW(TAG, "This is a warning");
    ESP_LOGE(TAG, "And this an error");
}

No printf: use log levels. You can raise or lower the level per component from menuconfig, and turn almost all of them off in production.

Tasks: the heart of ESP-IDF

Here is the big difference from Arduino. Instead of a loop(), you create FreeRTOS tasks with their own priority and stack size:

void sensor_task(void *arg) {
    while (1) {
        read_sensor();
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void app_main(void) {
    xTaskCreate(sensor_task, "sensor", 4096, NULL, 5, NULL);
}

Real benefits:

True parallelism: one task measures, another publishes over MQTT.
vTaskDelay does not block the rest of the system.
You control stack and priority, which is what prevents weird reboots.

Partitions and OTA

Flash is not a single block: it is partitioned (a partitions.csv table). By default there are two application slots (app0 and app1) so you can do OTA (Wi-Fi updates) with rollback if something fails.

# Name,   Type, SubType, Offset,  Size
nvs,      data, nvs,     0x9000,  0x4000
factory,  app,  factory, 0x10000, 1M

An OTA-style partition table:

# Name,   Type, SubType,  Size
nvs,      data, nvs,      0x4000
otadata,  data, ota,      0x2000
phy_init, data, phy,      0x1000
factory,  app,  factory,  1M
ota_0,    app,  ota_0,    1M
ota_1,    app,  ota_1,    1M

Wiring: Arduino or ESP-IDF?

	Arduino core	ESP-IDF
Curve	Low	High
Control	Medium	Total
Tasks	1 loop	N tasks
Memory	Automatic	You decide
OTA	Easy	Complete (rollback)
Logs	`Serial`	Per-component levels

When it is worth it

Yes: products, battery, fine timing, serious OTA, many peripherals.
No: if you just want to read a sensor and publish, Arduino gets you there in an afternoon and is more than enough.

Tip: you can mix them. The Arduino core is ESP-IDF underneath, so from a sketch you can call ESP-IDF APIs when you need them.

Summary

ESP-IDF is the official SDK: CMake + idf.py + menuconfig.
Use FreeRTOS tasks, not a loop().
Log levels with ESP_LOGx instead of printf.
Flash is partitioned; OTA with rollback comes almost for free.
Current version: 6.1.

Next step: MicroPython and Lua for the opposite extreme: zero compiling. Or go back to the series hub.

Arduino core for ESP32 in depth: install it, understand it, stop fighting it

2026-09-27T00:00:00+00:00

The “Arduino core for ESP32” is why half the world uses this chip. It lets you write pinMode() and digitalWrite() like on an Arduino UNO, but underneath there is an ESP32 running FreeRTOS. Understanding that layer is the difference between copying examples and knowing what you are doing.

What it actually is

It is not an emulated Arduino. Since version 3.x, the core is a wrapper over ESP-IDF: your setup() and loop() run inside a real FreeRTOS task (called loopTask), on core 1, with 8 KB of stack by default.

That explains two very typical things:

If your loop() hangs, the watchdog fires and the board reboots.
If the project grows, you can create tasks with xTaskCreatePinnedToCore().

Installation (two ways)

Arduino IDE — add the board URL in Preferences:

https://espressif.github.io/arduino-esp32/package_esp32_index.json

Then install “esp32 by Espressif” from the Boards Manager and pick your board.

PlatformIO (my recommendation) — platformio.ini:

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
monitor_speed = 115200

`setup()` and `loop()` under the hood

void setup() {
  Serial.begin(115200);
  pinMode(2, OUTPUT);
}

void loop() {
  digitalWrite(2, !digitalRead(2));
  delay(1000);
}

It works, but keep in mind:

delay() blocks the task. With Wi-Fi or several sensors, use millis().
setup() runs once; if you want parallel work, create tasks there.
The watchdog watches the loop: take too long and it reboots.

Anti-blocking version:

unsigned long last = 0;
constexpr unsigned long INTERVAL = 1000;

void loop() {
  if (millis() - last >= INTERVAL) {
    last = millis();
    digitalWrite(2, !digitalRead(2));
  }
}

Libraries: not all of them work

Generic Arduino libraries usually work if they do not touch AVR registers.
Those using timers or specific interrupts may fail.
For sensors, look for the “ESP32” version or use the vendor library.
Wire (I2C) and SPI exist, but you can choose the pins.

Differences from an Arduino UNO

Thing	Arduino UNO	ESP32
Voltage	5 V	3.3 V
Bits	8	32
EEPROM	1 KB	none (use `Preferences`)
ADC	10-bit	12-bit (and ADC2 with Wi-Fi, careful)
Wi-Fi	❌	✅
Cores	1	2

Saving something in the ESP32 “EEPROM” is done like this:

#include <Preferences.h>
Preferences prefs;

void setup() {
  prefs.begin("my-app", false);
  int boots = prefs.getInt("n", 0) + 1;
  prefs.putInt("n", boots);
  prefs.end();
}

Good practices

Do not block the loop: use millis(), tasks or vTaskDelay.
Serial at 115200, and wait a moment after begin() if needed.
Do not abuse String: it fragments memory. Use char[] and snprintf.
Split your code into files; a 2000-line .ino is painful.
Debug with logs, not Serial.println everywhere.

When to move to ESP-IDF

When you need fine control over tasks and memory, precise timing, serious OTA partitions, or to squeeze power. The Arduino core hides a lot, and sometimes that is fine… until it is not.

Summary

It is a wrapper over ESP-IDF; your setup/loop are a FreeRTOS task.
delay() blocks; learn millis() from day one.
3.3 V, no EEPROM (use NVS/Preferences), 12-bit ADC.
Not every Arduino library compiles: check compatibility.
Current core version: 3.3.11 (on ESP-IDF 5.5.5).

Next step: ESP-IDF in depth for when you need total control. Or go back to the series hub.

Which framework should you use on the ESP32? Arduino, ESP-IDF, MicroPython or Rust

2026-09-26T00:00:00+00:00

Here comes the most repeated question: what do I program the ESP32 with? The short answer is “it depends”, and the useful answer is this table. Pick based on where you stand and what you want to achieve.

The five paths

Framework	Language	Curve	Control	Best for
Arduino core	C++	Very low	Medium	Starting, prototypes, sensors
ESP-IDF	C (C++)	High	Total	Products, RTOS, performance
MicroPython	Python	Very low	Low	Learning, quick tests
Rust	Rust	Medium-high	High	Robustness, safety, no_std
Lua (NodeMCU)	Lua	Low	Low	Legacy, very simple scripts

Let us be clear: there is no best one, there is a better one for you right now.

Arduino core: where almost everyone starts

You write setup() and loop(), call pinMode(), digitalWrite(), and that is it. Thousands of libraries and examples.

Pros: you start in an afternoon, huge community, everyone can help you.
Cons: it hides things (tasks, memory, partitions), and when something weird happens, you do not know where to look.
Current version: 3.3.11 (built on ESP-IDF 5.5.5).

Use it if you are starting, building a prototype, or coming from Arduino.

ESP-IDF: the “real” one

It is Espressif’s official SDK. Here you control everything: FreeRTOS, tasks, queues, partitions, menuconfig, logs, power, security.

Pros: total control, better performance, fully documented by the vendor, the base of everything else.
Cons: more concepts to learn and more code for the same thing.
Current version: 6.1.

Use it if you are going to production, need fine timing, or want to squeeze the hardware.

MicroPython: understand it in 5 minutes

Flash the firmware, open a REPL and write Python. Perfect to learn and to tinker without compiling.

Pros: immediate, fun, great for teaching.
Cons: slower, more RAM, and not every peripheral is covered.
Current version: 1.29.

Use it if you want results now, or you come from Python.

Rust: power with a safety net

The esp-rs ecosystem gives you two paths: esp-idf-hal (on top of ESP-IDF, with std) and esp-hal / embassy (no_std, lighter and async).

Pros: the compiler prevents memory and concurrency bugs, very robust code, real async with embassy.
Cons: learning curve, separate toolchain (espup), younger ecosystem.
Current version: esp-hal 1.2.0.

Use it if you care about reliability, come from Rust, or want to learn something serious.

Lua (NodeMCU): the past

It was popular with the ESP8266. Today it is largely abandoned next to MicroPython. It only makes sense to maintain old projects.

The decision, in 20 seconds

Your situation	Start with
It is my first microcontroller	Arduino core
I can program, but not C/C++	MicroPython
I need control and performance	ESP-IDF
I want safety and robustness	Rust (`esp-idf-hal`)
I am building a battery product	ESP-IDF (or Rust)
I want to teach someone	MicroPython

Tip: you do not have to choose forever. Many people start with Arduino and jump to ESP-IDF when the project demands it. The concepts (GPIO, I2C, tasks) carry over.

What matters more than the framework

Understanding the hardware: ADC, reserved pins, power.
Knowing how to debug: logs, printf, measuring signals.
Reading the datasheet when something does not add up.

With that, switching frameworks is a weekend. Without it, none of them saves you.

Summary

Arduino: start fast. ESP-IDF: control and production. MicroPython: learn and prototype. Rust: robustness.
Lua is no longer worth it for new projects.
The current version of each is in the table above.
Choose by your experience and your goal, not by fashion.

Next step: let’s go into detail with the Arduino core, the most used one. Or go back to the series hub.

ESP8266 vs ESP32: when the little one is (not) worth it

2026-09-25T00:00:00+00:00

The ESP8266 put cheap Wi-Fi in everyone’s hands. It was the chip that turned makers into people able to run a web server in their living room for two dollars. It still sells, it still gets used, and it still has an audience.

The honest question is: does it make sense to buy one today? Almost always no, and here is why.

The differences that matter

	ESP8266	ESP32 (classic)
Cores	1 × Xtensa L106 @ 160 MHz	2 × LX6 @ 240 MHz
Usable RAM	~50 KB	~320 KB
Wi-Fi	Wi-Fi 4	Wi-Fi 4
Bluetooth	❌	BT 4.2 + BLE
Usable GPIOs	~11	~25
ADC	1 channel, 10-bit	18 channels, 12-bit
DAC	❌	✅
Native USB	❌	❌

It is not just “less powerful”: there is 10× less memory and very few pins. That constrains everything you can do.

Where the ESP8266 still shines

Pure price: under $2 on AliExpress.
Simplicity: to read a sensor and publish over Wi-Fi to one endpoint, it is plenty.
Legacy: tons of working code and tutorials.
Very low deep sleep current if the project is simple.

Where it falls short (and it hurts)

Memory: a big JSON parser or TLS leaves you out of RAM and with random reboots.
Single core: Wi-Fi and your code share the CPU, so any long task triggers watchdog resets.
Pins: with the ADC and the flash, you are left with very few GPIOs.
TLS: modern handshakes are expensive for this chip.
Relevance: the ecosystem is now centred on the ESP32.

The comparison that actually matters today

If the ESP8266 tempts you on price, compare it with the ESP32-C3, not the classic:

	ESP8266	ESP32-C3
Price	~$1.5	~$2–3
Core	Xtensa	RISC-V @ 160 MHz
RAM	~50 KB	400 KB
Bluetooth	❌	BLE 5
Native USB	❌	Yes (Serial/JTAG)
ADC	10-bit	12-bit

The price gap is a few cents and the C3 is better at everything. That is why I recommend forgetting the 8266 for a new project.

When to use each

Use the ESP8266 if…

Price is the only thing that matters (volume production, toys).
You have old working code and do not want to touch it.
The project is a minimal sensor that will never grow.

Use an ESP32 (C3) if…

You need BLE, more pins or more memory.
You are doing TLS, OTA or non-trivial logic.
You want native USB and decent debugging.
You think the project might grow (and it always does).

Migrating from the 8266 to the ESP32-C3

If you are coming from the 8266 and jumping to the C3, watch out:

ESP8266WiFi.h becomes WiFi.h (and some APIs get renamed).
The ADC is different: on the 8266 it is A0 (10-bit); on the C3 you use ADC1 with 12 bits.
Deep sleep is more flexible: specific GPIOs can wake it.
Libraries for the 8266 do not always compile: look for the ESP32 equivalent.
The pin mapping is nothing alike: do not copy the wiring.

Summary

The ESP8266 was revolutionary, but today it is dated next to the C3.
It has ~50 KB RAM, one core and few pins: it runs out of room quickly.
It only wins when price is everything or the code is inherited.
For new projects, an ESP32-C3 costs about the same and is far superior.
If you migrate, expect changes in Wi-Fi, ADC and pins.

Next step: that closes the variants. Now it is time to choose a framework: Arduino, ESP-IDF, MicroPython or Rust. Or go back to the series hub.

ESP32-P4 in depth: the radio-less ESP32 for displays and high performance

2026-09-24T00:00:00+00:00

The ESP32-P4 breaks the family mould: it has no Wi-Fi, no Bluetooth, no 802.15.4. No radios at all. In exchange, it is the most powerful ESP32 ever made and the first one designed as an application processor: displays, interfaces, light video and compute.

It sounds odd for an ESP32… until you get the trick: you choose the radio. Put a C6 next to it and you get the best of both worlds.

What it is

Thing	Value
Cores	2 × RISC-V @ 400 MHz
SRAM	768 KB on-chip (+ 8 KB TCM)
Radio	none (Wi-Fi/BT via a separate chip)
GPIOs	55
USB	OTG 2.0 high-speed
Others	MIPI-CSI/DSI, Ethernet, SDIO, CAN
AI	AI extensions + FPU

Two details set it apart: MIPI-CSI/DSI (real camera and display interfaces, not SPI) and high-speed USB.

You add the radio yourself

The P4 deliberately ships no connectivity. The usual setup pairs it with a C6 (which has Wi-Fi 6, BLE and 802.15.4) and splits the work:

The P4 handles the display, the camera and the logic.
The C6 handles talking to the world.

That is why the official kit, the ESP32-P4-Function-EV-Board, already includes a C6.

Pins: plenty

With 55 programmable GPIOs, this chip does not have the pin shortage of its smaller siblings. It also brings blocks for SPI, I2C, I2S, UART, CAN, SDIO, Ethernet (RMII) and the MIPI interfaces. For the exact mapping, the Espressif datasheet is the reference.

One important note: it does have an ADC, but forget the Wi-Fi that broke ADC2 on other models — there is no radio here to interfere.

Boards

ESP32-P4-Function-EV-Board — evaluation board with an integrated C6, a MIPI display and a camera. The easiest way to start.
ESP32-P4-Module — for your own PCBs.

The P4 (2024) closes the line: no radio, but as an application processor. Own illustration.

When to pick it (and when not to)

Yes, pick the P4 if…

You are driving large or touch displays (MIPI, not slow SPI).
You need a real camera, with MIPI-CSI.
You want high-speed USB, Ethernet or heavy compute.
You split the project into processor + radio (P4 + C6).

Do not pick it if…

You want something simple with Wi-Fi: a C3 or C6.
You want the cheapest: the P4 is not it.
You do not need a display or heavy compute: you would be overpaying.
You expect on-board connectivity: it has none (and that surprises people).

Typical mistakes

Buying it expecting built-in Wi-Fi (it has none; you need the C6).
Driving a serious display over SPI when you have MIPI-DSI available.
Forgetting it is a new chip: it needs a recent toolchain (ESP-IDF 5.3+, today 6.1).

Summary

Two RISC-V cores at 400 MHz, 768 KB SRAM and 55 GPIOs.
MIPI-CSI/DSI, USB 2.0 HS and Ethernet.
No radio: pair it with a C6.
It is the chip for HMI, displays and high performance, not a dumb sensor.
If you are torn between P4 and S3: the S3 is cheaper and already has radios; the P4 is for when you need a real display.

Next step: we close the variants block with ESP8266 vs ESP32 and then move on to frameworks. Or go back to the series hub.

ESP32-H2 in depth: the Wi-Fi-less ESP32 for battery Matter nodes

2026-09-23T00:00:00+00:00

It sounds like a joke: an ESP32 without Wi-Fi. But think about it twice and it makes perfect sense. The H2 is built for low-power home automation: sensors, switches and Matter/Thread nodes that have to last months on a battery.

Fewer radios on = less battery. And if you already have a border router at home, a device does not need its own Wi-Fi.

What it is

It is a single-core RISC-V SoC focused on low-power wireless, with the flash inside the chip itself (2 or 4 MB), which simplifies the design a lot.

Thing	Value
Core	1 × low-power RISC-V
SRAM	320 KB (+ 4 KB LP memory)
ROM	128 KB
Wi-Fi	none
Bluetooth	BLE 5
802.15.4	Thread / Zigbee / Matter
GPIOs	19 programmable, with ADC
USB	native Serial/JTAG
Flash	2 or 4 MB integrated (SiP)

Why no Wi-Fi (and why that is fine)

The H2 is a node chip, not a gateway. In a Thread network all devices talk to each other and only one (the border router) needs Internet access. The rest can spend their energy on what matters: measuring and sleeping.

Result: a well-slept H2 uses far less than a C6 with Wi-Fi on. And it does not compete for spectrum with your home Wi-Fi.

Pins: what you should know

The H2 brings 19 programmable GPIOs with ADC, SPI, UART, I2C, I2S, RMT, GDMA and PWM support. The exact mapping depends on the module, so for fine detail check the datasheet. What is worth keeping clear:

One block of pins acts as ADC; use it for analog sensors.
There are strapping pins and pins taken by the internal flash: do not use them.
USB Serial/JTAG to flash and debug with no external chip.

Boards and modules

ESP32-H2-MINI-1 — the small module (the usual one, with integrated flash).
ESP32-H2-DevKitM-1 — the development board.
ESP32-H2-WROOM-1 — the classic module.

ESP32-H2: BLE 5 + Zigbee/Thread, no Wi-Fi. Own illustration.

When to pick it (and when not to)

Yes, pick the H2 if…

You are doing Matter/Thread/Zigbee automation and want maximum runtime.
You need a small, cheap node that only speaks 802.15.4/BLE.
You want integrated flash to reduce parts on your PCB.
You already have a border router and do not need Wi-Fi on the node.

Do not pick it if…

The device needs to reach the Internet on its own → C6.
You are doing plain Wi-Fi → C3.
You need camera, audio or AI → S3.
You need lots of GPIOs → S3 or P4.

Typical mistakes

Buying it assuming it has Wi-Fi (it does not, and no firmware fixes that).
Trying to use it as a gateway: for that you need a C6 (or a C6 + H2).
Forgetting that its whole point is sleeping: keep it awake all the time and you lose the advantage.

Summary

Single low-power RISC-V, 320 KB SRAM and integrated flash.
BLE 5 + 802.15.4 (Thread/Zigbee/Matter) and no Wi-Fi.
19 GPIOs with ADC and USB Serial/JTAG.
It is the ideal chip for battery Matter nodes.
For a gateway or Wi-Fi, prefer a C6.

Next step: the ESP32-P4, the new radio-less chip for displays and high performance. Or go back to the series hub.

ESP32-C6 in depth: Wi-Fi 6, Matter and Thread in one chip

2026-09-22T00:00:00+00:00

The ESP32-C6 is the chip of modern home automation. Not because it is the most powerful, but because it brings something none of its siblings have: an 802.15.4 radio, the foundation of Thread, Zigbee and Matter. And on top of that, it ships Wi-Fi 6.

If you are building a genuinely connected home (one that talks to Apple Home, Google Home or Home Assistant without hacks), this is the chip.

What it is

The C6 uses two RISC-V cores: a high-performance one (HP, 160 MHz) and a low-power one (LP, 20 MHz) that can keep watching sensors while the rest sleeps.

Thing	Value
Cores	RISC-V HP 160 MHz + LP 20 MHz
SRAM	512 KB
Wi-Fi	Wi-Fi 6 (802.11ax, 2.4 GHz)
Bluetooth	BLE 5
802.15.4	Thread / Zigbee / Matter
GPIOs	30
USB	native Serial/JTAG

What makes it unique: 802.15.4 + Wi-Fi 6

802.15.4 is the radio behind Matter, Thread and Zigbee. Without it, your device cannot speak the language of the modern connected home.
Wi-Fi 6 is not marketing: it plays nicer with crowded networks and adds TWT (Target Wake Time), letting the device negotiate with the router when to wake up. Translation: less power for the same Wi-Fi.

And it can use Wi-Fi and 802.15.4 at the same time, so you can build a Thread border router… or simply be a Matter device that reaches the Internet over Wi-Fi.

Pinout: the essentials

Pin(s)	What for
GPIO12 / GPIO13	USB D− / D+
GPIO0–6	ADC1
GPIO8, GPIO9, GPIO15	Strapping
GPIO24–30	Internal flash (do not use)
GPIO5 / GPIO6	usual UART (RX / TX)

As across the family: no DAC, no touch, and ADC2 does not work with Wi-Fi (here, use ADC1).

Boards and modules

ESP32-C6-WROOM-1 — standard module.
ESP32-C6-MINI-1 — small version.
ESP32-C6-DevKitC-1 — development board.
ESP32-C6-DevKitM-1 — the reduced one.

ESP32-C6: Wi-Fi 6 + BLE 5 + 802.15.4 (Thread/Zigbee/Matter). Photo: Popolon (CC BY-SA 4.0).

When to pick it (and when not to)

Yes, pick the C6 if…

You are doing Matter, Thread or Zigbee.
You want Wi-Fi 6 and good power behaviour with TWT.
You need a device compatible with modern home ecosystems.
You want to build a Thread border router.

Do not pick it if…

You only do plain, cheap Wi-Fi: a C3 costs less.
You need camera, audio or AI: that is the S3.
You need classic Bluetooth or a DAC: the classic.
You do not need Wi-Fi: the H2 is cheaper for an 802.15.4/BLE node.

Typical mistakes

Buying a C6 “to try” without a recent toolchain: Matter needs ESP-IDF 5.1+ (today we are on 6.1).
Expecting a DAC or touch that do not exist.
Confusing Matter (application protocol) with Thread (network): the C6 has the radio for both.

Summary

Dual RISC-V (HP + LP), 512 KB SRAM.
Wi-Fi 6 + BLE 5 + 802.15.4: the only one in the family with hardware Matter.
30 GPIOs and USB Serial/JTAG.
It is the choice for modern home automation; for everything else, C3 or S3.
It needs an up-to-date toolchain (ESP-IDF 5.1+, ideally 6.x).

Next step: the ESP32-H2, its Wi-Fi-less sibling for battery Matter nodes. Or go back to the series hub.

ESP32-C3 in depth: the one I recommend to start with (and why)

2026-09-21T00:00:00+00:00

If you ask me “which ESP32 should I buy to start?”, the short answer is ESP32-C3. It is modern, cheap, has Bluetooth 5 and native USB, and for 90 % of sensor and home-automation projects it is more than enough.

It is not perfect: it has few pins and is missing a few things. Let’s see exactly what you get and what you do not.

What it is

The C3 is the “next generation” ESP32: instead of the usual Xtensa cores, it uses RISC-V, the open architecture Espressif adopted for its newest chips.

Thing	Value
Core	1 × RISC-V @ 160 MHz
SRAM	400 KB
Wi-Fi	802.11 b/g/n (2.4 GHz)
Bluetooth	BLE 5
GPIOs	22
ADC	2 × 12-bit (6 channels)
DAC	none
Touch	none
USB	native Serial/JTAG

The good

Cheap: it usually costs the same as an ESP8266 and beats it at everything.
BLE 5: great for talking to a phone (no classic Bluetooth).
Native USB: forget the CH340 and enjoy built-in JTAG, which means breakpoint debugging with no extra hardware.
Low power: in deep sleep it stays below the classic, ideal for battery-powered nodes.
RISC-V: modern toolchain and first-class support in ESP-IDF, Arduino and Rust.

The bad

Only 22 GPIOs, and you have to subtract the flash pins.
No DAC and no touch: if you need real analog output or capacitive buttons, go back to the classic or the S2.
Single core: you cannot split work across two CPUs.
Bluetooth is BLE only, no classic.

Pinout: the essentials

Pin(s)	What for
GPIO18 / GPIO19	USB D− / D+ (USB Serial/JTAG)
GPIO0–4	ADC1
GPIO5	ADC2
GPIO2, GPIO8, GPIO9	Strapping (careful with 9: it is the BOOT button)
GPIO11–17	Internal flash (do not use)
GPIO20 / GPIO21	UART (RX / TX)

As always: ADC2 does not work with Wi-Fi on, so for sensors use ADC1 (GPIO0–4).

ESP32-C3 pinout. Source: Wikimedia Commons, CC BY-SA 4.0.

Boards and modules

ESP32-C3-WROOM-02 — the standard module.
ESP32-C3-MINI-1 — small, for your own PCB.
ESP32-C3-DevKitM-1 — the small, stick-like board.
ESP32-C3-DevKitC-02 — with more pins and buttons.

An ESP32-C3 NodeMCU board: small, cheap and USB-C. Photo: Popolon (CC BY-SA 4.0).

When to pick it (and when not to)

Yes, pick the C3 if…

You are getting started and do not want to overspend.
You are building home automation, sensors or relays with Wi-Fi and BLE.
You want native USB and JTAG with no extra chip.
You want a battery node with good deep sleep.

Do not pick it if…

You need classic Bluetooth → classic ESP32.
You need a DAC or touch → classic or S2.
You need lots of GPIOs → S2 or S3.
You need camera, audio or AI → S3.
You need Matter/Thread/Zigbee → C6 or H2.

Typical mistakes

Counting on 22 GPIOs and forgetting that GPIO11–17 are the flash.
Putting the BOOT button on GPIO9 and having the chip boot into download mode.
Looking for the DAC or touch in the C3 docs (they do not exist).
Reading sensors on ADC2 with Wi-Fi connected.

Summary

1 × RISC-V core at 160 MHz, 400 KB SRAM, Wi-Fi 4 + BLE 5.
Native USB Serial/JTAG and good deep sleep current.
22 GPIOs, no DAC and no touch.
It is the best starter buy in 2026: cheap, modern and well supported.
If you need more muscle or pins, jump to the S3 or S2.

Next step: the ESP32-C6, with Wi-Fi 6 and a radio for Matter. Or go back to the series hub.

ESP32-S3 in depth: cores, PSRAM, AI and USB for serious projects

2026-09-20T00:00:00+00:00

If the S2 was the experiment, the ESP32-S3 is the one that worked out: two cores, Bluetooth, native USB and, on top of that, vector instructions that speed up AI. It is the chip inside camera boards, voice assistants and almost any “big” ESP32 project.

That said: it is the most expensive of the family and, if you are not going to use what it brings, you are overpaying.

What it is

Thing	Value
Cores	2 × Xtensa LX7 @ 240 MHz
SRAM	512 KB
Wi-Fi	802.11 b/g/n (2.4 GHz)
Bluetooth	BLE 5 (no classic Bluetooth)
GPIOs	up to 45
ADC	20 channels, 12-bit
Touch	14 channels
USB	native OTG
PSRAM	up to 8 MB (module dependent)

Notice two things: it has no DAC (unlike the classic and the S2) and its Bluetooth is BLE only, just like the C3.

What makes it special: vector instructions

The S3 adds 128-bit SIMD aimed at neural networks. In practice that means a small voice or gesture model runs several times faster than on a classic, with no GPU or external accelerator.

That is why camera boards and home “assistants” use an S3 instead of a C3.

PSRAM: quad vs octal (and the price in pins)

There is a trap here that bites many people. S3 modules come in several combos, for example N8R2 (8 MB flash + 2 MB PSRAM) or N8R8 (8 MB + 8 MB), and the PSRAM can be quad or octal:

Quad PSRAM — uses fewer pins.
Octal PSRAM — faster, but it eats GPIO33–GPIO37.

And in any configuration, GPIO26–GPIO32 are taken by the flash (and by the PSRAM when present). Translation: do not count on 45 GPIOs if the module has memory. Always check the specific module datasheet.

Pinout: the essentials

Pin(s)	What for
GPIO19 / GPIO20	USB D− / D+
GPIO1–10	ADC1
GPIO11–20	ADC2
GPIO1–14	Touch
GPIO0, 3, 45, 46	Strapping
GPIO26–32	Flash/PSRAM (do not use)
GPIO33–37	extra if the module has octal PSRAM

The usual peripherals are still there (SPI, I2C, I2S, UART, PWM, RMT) plus a camera interface (LCD_CAM) able to move video.

Boards and modules

ESP32-S3-WROOM-1 / 1U — the standard module (the “U” has an external antenna).
ESP32-S3-MINI-1 — small, for your own PCB.
ESP32-S3-DevKitC-1 / DevKitM-1 — the development boards.
ESP32-S3-EYE — board with camera and display, for vision.
ESP32-S3-DevKitC-1 N16R8 — the higher-memory version.

ESP32-S3: the most capable variant for edge AI and multimedia. Photo: VectorVoyager (CC BY-SA 4.0).

When to pick it (and when not to)

Yes, pick the S3 if…

You are doing vision, audio or on-device AI.
You need a camera or to drive displays.
You want two cores and native USB.
You need PSRAM for large buffers.

Do not pick it if…

You just want to read sensors and publish over Wi-Fi: a C3 does the same for far less.
You need classic Bluetooth (it only has BLE): that is the classic.
You need a DAC: the S3 has none; use the classic or the S2.

Typical mistakes

Buying an S3 without PSRAM and then wanting vision or audio.
Buying octal PSRAM and discovering you lose GPIO33–37.
Assuming it has classic Bluetooth (it is BLE only).
Counting on GPIO26–32 when they are taken by memory.

Summary

2 × LX7 cores, 512 KB SRAM, BLE 5 and USB OTG.
Vector instructions make it the best ESP32 for AI and multimedia.
Quad or octal PSRAM: octal is faster but uses more pins.
It has no DAC and no classic Bluetooth.
It is the “big” option: if you do not need camera/AI, a C3 is more than enough.

Next step: the ESP32-C3, the one I recommend to start with. Or go back to the series hub.

ESP32-S2 in depth: the ESP32 with real USB (and no Bluetooth)

2026-09-19T00:00:00+00:00

The ESP32-S2 is the odd sibling. It arrived in 2019 with a very clear idea: native USB, lots of pins and Wi-Fi… but no Bluetooth. That single decision splits opinion: for some it is perfect, for others it is a paperweight.

Let’s see what it is actually good for.

What it is (and how it differs from the classic)

The S2 uses a single Xtensa LX7 core at 240 MHz (the classic has two). That sounds like a downgrade, but in exchange it ships USB OTG, which is a more interesting peripheral than it looks.

Thing	Value
Core	1 × Xtensa LX7 @ 240 MHz
SRAM	320 KB
Wi-Fi	802.11 b/g/n (2.4 GHz)
Bluetooth	none
GPIOs	43
ADC	20 channels, 12-bit
DAC	2 channels, 8-bit (GPIO17 and GPIO18)
Touch	14 channels
USB	native OTG

The good part: USB OTG

This is not “USB for the serial port”. It is a full USB controller, and that lets you do things the classic needs an extra chip for:

HID: emulate a keyboard, mouse or gamepad.
CDC: your own serial port, with your own VID/PID.
MSC: make the computer see the ESP32 as a USB drive.
Host: read a flash drive, a USB keyboard or a reader.

And because it is native, forget the CH340 and its drivers. One cable and done.

The bad part: no Bluetooth

Here is the toll. If your project needs to send data to a phone over BLE, or talk to a speaker over classic Bluetooth, the S2 is not for you. Period. It is not a firmware issue: the radio simply is not there.

Espressif left it out to cut cost and complexity. It made sense at the time… but today it means that, when in doubt, you almost always want a C3 or an S3 instead.

Pinout: the pins that matter

There is no official S2 pinout on Commons, so here are the things you will actually look up (for the rest, see the Espressif datasheet):

Pin(s)	What for
GPIO19 / GPIO20	USB D− / D+ (do not reuse them if you use USB)
GPIO1–10	ADC1
GPIO11–20	ADC2
GPIO17 / GPIO18	DAC 1 and DAC 2
GPIO1–14	Touch
GPIO0, 45, 46	Strapping (boot)
GPIO26–32	Internal flash (do not use)

Two warnings that carry over from the classic:

ADC2 does not work while Wi-Fi is on. Use ADC1.
The strapping pins (especially GPIO45 and GPIO46) are best left alone.

Boards and modules

What you will find:

ESP32-S2-WROOM / WROOM-1 — the standard module.
ESP32-S2-MINI-1 — the small one, ideal for your own PCB.
ESP32-S2-Saola-1 — the DevKitC-style development board.
ESP32-S2-Kaluga-1 — kit with a display and camera.
ESP32-S2-DevKitM-1 — the reduced version.

ESP32-S2: native USB OTG, Wi-Fi 4 and no Bluetooth. Own illustration.

When to pick it (and when not to)

Yes, pick the S2 if…

You need real USB: HID, CDC, storage, host.
You want lots of GPIOs (43) and do not care about Bluetooth.
You are going to use DAC or touch and want native USB as a bonus.
You are building a USB device you want to emulate.

Do not pick it if…

You need BLE (very common): go for a C3 or S3.
You want the cheapest option: the C3 is more modern and usually costs the same or less.
You need two cores: the S2 has one.

Typical mistakes

Buying it assuming it has BLE because “all ESP32s do”.
Using GPIO19/20 for something else and then wondering why USB never shows up.
Reading a sensor on ADC2 with Wi-Fi on.
Forgetting that GPIO45/46 are boot pins and that holding them LOW can block boot.

Summary

1 × LX7 core, 320 KB SRAM, USB OTG and 43 GPIOs.
No Bluetooth: its biggest limitation.
It has DAC and touch, like the classic.
It is the clear choice when USB is the star of the project.
If you are torn between S2 and C3, the C3 almost always wins.

Next step: the ESP32-S3 — same USB, but with two cores, Bluetooth and AI acceleration. Or go back to the series hub for the full index.

The classic ESP32 in depth: pins, ADC, DAC and when it's still worth it

2026-09-18T00:00:00+00:00

When people say “ESP32” they almost always mean this one: the 2016 chip with two cores and 38 pins. It still has the most tutorials, it is the cheapest board with classic Bluetooth, and even though there are more modern options, it still makes a lot of sense in 2026.

But it has a few corners —pins you cannot use, an ADC that is not as nice as the marketing suggests— that you should know before soldering anything. I have wasted more than one afternoon by not knowing them, so let’s save you the trouble.

The chip: not every “ESP32” is the same

Inside the module there is a specific chip, and they are not all equal:

Chip	What is special about it
ESP32-D0WDQ6	The original, 2 cores, QFN 6×6 mm
ESP32-D0WD	Same but in a 5×5 mm package
ESP32-D0WD-V3	The current revision, used in new modules
ESP32-D0WDR2	With 2 MB of PSRAM inside the chip itself
ESP32-S0WD	Single core (rare to see)

For our purposes: 2 × Xtensa LX6 cores at 240 MHz, 520 KB of SRAM and 448 KB of ROM. That is the “classic ESP32”.

The modules: WROOM, WROVER and friends

The bare chip is not something you solder by hand. It lives inside a module with the flash, the crystal and the antenna. The ones you will find:

ESP32-WROOM-32E — the standard. 4 MB of flash, PCB antenna. Leaves GPIO16 and GPIO17 free.
ESP32-WROVER-E — same, but with 8 MB of PSRAM on top. Note: the PSRAM eats GPIO16 and GPIO17, so if you need those pins, you cannot use WROVER.
ESP32-WROOM-32UE / WROVER-IE — no PCB antenna, with a U.FL connector for an external antenna. The fix when the ESP32 lives inside a metal box.

The ESP32-WROOM-32: chip, flash and antenna in a single part. Photo: Ubahnverleih (CC0).

2026 note: for new designs, Espressif recommends the E series (ESP32-WROOM-32E / WROVER-E). The older modules without the “E” are marked as not recommended for new designs.

And on the back you can see where everything is:

On the back: the ESP32 chip on the left and the flash memory on the right. Photo: Ubahnverleih (CC0).

The board you will buy

The module is mounted on a development board (devkit) that adds USB, a regulator and two buttons: EN (reset) and BOOT (for flashing). The classic one is the ESP32-DevKitC.

ESP32-DevKitC: the module, the micro-USB port, the regulator and the two buttons. Photo: Ubahnverleih (CC0).

A warning worth money: these boards have no native USB. The port is a bridge chip (CP2102 or CH340) that talks to the ESP32 over UART. If you have trouble flashing, it is almost always that chip’s driver, not the ESP32.

Specs, no fluff

Thing	Value
Cores	2 × Xtensa LX6 @ up to 240 MHz
SRAM	520 KB
Wi-Fi	802.11 b/g/n (2.4 GHz)
Bluetooth	4.2 classic (BR/EDR) + BLE
GPIOs	34 total, ~25 usable
ADC	18 channels, 12-bit (ADC1 + ADC2)
DAC	2 channels, 8-bit
Touch	10 capacitive pins
Peripherals	3×UART, 2×I2C, SPI, 2×I2S, CAN (TWAI), SD/MMC, PWM, RMT

The classic Bluetooth bit is unique to the classic: neither the S2, nor the C3, nor the S3 have it. If your project talks to a speaker or an old-school Bluetooth gamepad, this is your chip.

The 38-pin pinout

ESP32 (DevKitC, 38 pins) pinout. Source: Wikimedia Commons, CC BY-SA 4.0.

If you come from Arduino, here is a mindset shift: not every pin does everything. There are input-only pins, pins that decide how the chip boots, and pins that are literally taken internally. Let’s go one by one.

The pins that rock

The DAC (GPIO25 and GPIO26)

The classic has two real analog outputs (8-bit). The C3, for example, has none. You can output an actual voltage, generate a waveform or build a mediocre but fun synthesizer.

Touch: 10 pins that sense your finger

With no extra sensor, the chip measures the capacitance of GPIO0, 2, 4, 12, 13, 14, 15, 27, 32 and 33. Perfect for buttons with no moving parts. (This peripheral disappeared in the S2 and S3, so if you need it, you go back to the classic.)

ADC1: the one that works with Wi-Fi

GPIO32 to GPIO39 are ADC1. They are the only ones you can use while Wi-Fi is on. Burn this into your memory, because it is the number one cause of “my sensor reads random values”.

And a few lesser-known extras

Internal Hall sensor, using no pin at all.
Internal temperature sensor (not very accurate, but it exists).
CAN (TWAI) in hardware, no external module.

The pins that will ruin your day

GPIO6 to GPIO11: the flash

They are wired to the flash memory. Never use them. If you touch them, the ESP32 stops booting and looks dead. It is not dead: re-flash it and breathe.

The boot (strapping) pins

On power-up, the chip looks at these pins to decide how to boot:

Pin	What happens if it is wrong
GPIO0	`LOW` enters flash mode; as an output it can block boot
GPIO2	Must be `LOW` or floating at boot
GPIO12	If it is `HIGH` at boot, bad news (it is about flash voltage)
GPIO15	Must be `HIGH`; otherwise the boot log is silenced

Rule of thumb: do not put anything critical on those pins and, if you do, check their state at boot.

GPIO34 to GPIO39: input only

They have no internal pull-up or pull-down and cannot be used as outputs. They are perfect for a sensor you only need to read, but if you try to light an LED with them it will not work and you will spend a while thinking the LED is broken.

The ADC lies (and how to tame it)

This is the detail that frustrates people most. The ESP32’s ADC is 12-bit, but:

It is not linear. It deviates a lot near 0 V and near 3.3 V.
It has an offset. With 11 dB attenuation it saturates earlier than the datasheet suggests.
It needs calibration. ESP-IDF ships an eFuse calibration API. Use it.
ADC2 does not work with Wi-Fi on. We repeat: use ADC1.

If you need decent, stable measurements, an external ADS1115 over I2C will save you a lot of headaches.

PSRAM: when you need it

PSRAM is extra memory (typically 8 MB on the WROVER). You need it if you are going to hold large buffers: images, audio, huge JSONs or network buffers.

If your project is sensors and a couple of LEDs, you do not need it and the WROOM is cheaper. And remember the toll: PSRAM uses GPIO16 and GPIO17.

When to pick the classic (and when not to)

Yes, pick the classic if…

You need classic Bluetooth (not just BLE).
You want DAC, touch or CAN without adding anything.
You need lots of GPIOs and GPIO16/17 free.
You are following a tutorial that assumes the classic and do not want to fight different pins.

Pick something else if…

You want the cheapest, most modern option: a C3 does almost the same for less.
You need native USB (HID, JTAG): S2, S3, C3 or C6.
You need camera, audio or AI: ESP32-S3.
You want Matter/Thread/Zigbee: C6 or H2.

Current tools (2026)

If you are going to program it, these are the living versions today:

Tool	Current version
ESP-IDF	6.1
Arduino core	3.3.11 (on ESP-IDF 5.5.5)
PlatformIO (`platform-espressif32`)	7.1.3
MicroPython	1.29
`esp-hal` (Rust)	1.2.0

Typical mistakes with the classic

Trying to use GPIO6–11 “because they look free on the drawing”.
Putting an LED on GPIO34–39 and not understanding why it stays dark.
Reading a potentiometer on ADC2 and getting wild values once Wi-Fi comes up.
Using GPIO12 as an output and having the board boot whenever it feels like it.
Buying a WROVER to use GPIO16/17 and discovering they are taken.
Blaming your code when the problem is the CH340 driver.

Summary

The classic ESP32 is 2 × LX6 cores, 520 KB SRAM, Wi-Fi 4 and classic Bluetooth + BLE.
The modules you will see: WROOM-32E (no PSRAM) and WROVER-E (with PSRAM that eats GPIO16/17).
It has unique things: DAC, touch, CAN and classic Bluetooth.
Watch out for GPIO6–11, the strapping pins (0, 2, 12, 15) and GPIO34–39 (input only).
ADC2 does not work with Wi-Fi; use ADC1 and, if you need precision, an ADS1115.

Next step: if you want something smaller, cheaper and with native USB, Part 3 is about the ESP32-S2. And if you do not have a board yet, start with Part 1: what the ESP32 is and its family.

Image credits

Photos from Wikimedia Commons:

ESP32-WROOM-32 module (front and back) and ESP32-DevKitC — Ubahnverleih (CC0)
ESP32 DevKitC pinout — Vishnu Maiea (CC BY-SA 4.0)

What is the ESP32? The complete family, pinouts and where to buy it

2026-09-17T00:00:00+00:00

The ESP32 is probably the most popular Wi-Fi + Bluetooth microcontroller in the maker world. It costs less than a coffee, is roughly 20× more powerful than an Arduino UNO, and comes in a dozen flavours: ESP32, S2, S3, C3, C6, H2, P4… Picking the wrong variant is the number one beginner mistake.

This guide is the one I wish I had read at the start: what it exactly is, how each family member differs, how to read a pinout without getting it wrong, which one to buy for your project, and where to get it.

The ESP32 in 30 seconds

An ESP32 is a chip (SoC) that includes:

A 32-bit processor (1 or 2 cores, Xtensa or RISC-V).
Wi-Fi and, depending on the variant, classic Bluetooth, BLE and/or Zigbee/Thread.
SRAM and, on some models, external PSRAM.
Plenty of peripherals: GPIO, ADC, DAC, PWM, I2C, SPI, UART, I2S, CAN…
All for $2–5 on a board that plugs straight into USB.

That mix of power, radio and price is what made it the de-facto standard for home IoT.

SoC, module and board are not the same thing

A detail that confuses many people:

Term	What it is	Example
SoC	The bare chip	`ESP32-D0WDQ6`
Module	SoC + flash + antenna + shielding	`ESP32-WROOM-32`
Board / devkit	Module + USB + regulator + buttons	`ESP32-DevKitC-32E`

An ESP32-WROOM-32 module: SoC, flash and antenna in one part. Photo: Ubahnverleih (CC0).

When you buy on AliExpress or Mercado Libre you almost always get a devkit (the full board). When you design your own PCB, you buy the module.

The ESP32 family

All relevant members, in chronological order:

The ESP family, from the ESP8266 (2014) to the ESP32-P4 (2024).

And the table that actually matters when buying:

Variant	Year	Core	Radio	GPIOs	Native USB	Best for
ESP8266	2014	Xtensa L106 ×1 @ 160 MHz	Wi-Fi 4	~11 usable	❌	Cheapest Wi-Fi projects
ESP32 (classic)	2016	Xtensa LX6 ×2 @ 240 MHz	Wi-Fi 4 + BT 4.2	~34 (25 usable)	❌	General purpose, cheapest
ESP32-S2	2019	Xtensa LX7 ×1 @ 240 MHz	Wi-Fi 4	~43	✅	USB, HID, lots of pins
ESP32-C3	2020	RISC-V ×1 @ 160 MHz	Wi-Fi 4 + BLE 5	~22	✅	Modern, inexpensive replacement
ESP32-S3	2020	Xtensa LX7 ×2 @ 240 MHz	Wi-Fi 4 + BLE 5	~45	✅	AI, camera, audio, USB
ESP32-C6	2022	RISC-V ×1 @ 160 MHz (+ LP core)	Wi-Fi 6 + BLE 5 + 802.15.4	~30	✅	Matter, Thread, Zigbee
ESP32-H2	2023	RISC-V ×1 @ 96 MHz	BLE 5 + 802.15.4	~26	✅	Matter/Zigbee nodes without Wi-Fi
ESP32-P4	2024	RISC-V ×2 @ 400 MHz	no radio	many	✅	HMI, displays, high performance

Quick rule: not sure? Buy an ESP32-C3 if you want something cheap and modern, or an ESP32-S3 if you need power, camera or USB.

Variant by variant

ESP8266 — the grandfather that still works

It is not an ESP32, but it is its predecessor and still sells for under $2. It has one core, no Bluetooth and few GPIOs — yet it is enough for a temperature sensor publishing over Wi-Fi.

ESP8266: the chip that put cheap Wi-Fi in makers' hands. Photo: Suyash Dwivedi (CC BY-SA 4.0).

Only consider it if price is the only thing that matters. For a little more you get a C3, which is better at everything.

Classic ESP32 — the all-rounder

The 2016 one. Two cores at 240 MHz, more GPIOs than almost any other, and the only variant with classic Bluetooth (plus BLE). It is the chip in most old tutorials and still a perfect choice to start.

An ESP32-DevKitC: WROOM module, USB, regulator and two buttons. Photo: Edwiyanto (CC BY-SA 4.0).

Downsides: no native USB (it uses a CH340 or CP2102 serial chip) and higher sleep current than modern variants.

ESP32-S2 — the one without Bluetooth

The S2 was the first ESP32 with native USB OTG and lots of GPIOs (~43). Its sin: no Bluetooth. If you do not need it, it is a great option for HID (keyboards, mice) or pin-hungry projects.

ESP32-S2: native USB OTG, Wi-Fi 4 and no Bluetooth. Illustration.

ESP32-S3 — the powerful one

The favourite for ambitious projects: two LX7 cores, BLE 5, native USB and, above all, vector instructions that speed up AI workloads (voice, vision). It is what camera boards and display boards use.

ESP32-S3: the most capable variant for edge AI and multimedia. Photo: VectorVoyager (CC BY-SA 4.0).

Downsides: pricier than a C3, and overkill if you are not using camera/AI.

ESP32-C3 — the balanced one

My default recommendation in 2026. It is RISC-V, with BLE 5, native USB Serial/JTAG and an ESP8266-like price. For sensors, relays, home automation and almost any normal project, it is more than enough.

An ESP32-C3 NodeMCU board: small, cheap and USB-C. Photo: Popolon (CC BY-SA 4.0).

Downsides: fewer GPIOs (~22) and no classic Bluetooth (BLE only).

ESP32-C6 — the Matter one

The first ESP32 with Wi-Fi 6 and, more importantly, an 802.15.4 radio: that means Thread, Zigbee and Matter. If you want modern, compatible home automation, this is the chip.

ESP32-C6: Wi-Fi 6 + BLE 5 + 802.15.4 (Thread/Zigbee/Matter). Photo: Popolon (CC BY-SA 4.0).

Downsides: it needs a recent toolchain (ESP-IDF 5.1+) and some modules are still hard to find locally.

ESP32-H2 — the one without Wi-Fi

Like the C6 but without Wi-Fi: only BLE and 802.15.4. It sounds odd, but for a battery-powered Matter node it is perfect (less radio, less power).

ESP32-H2: BLE 5 + Zigbee/Thread, no Wi-Fi. Illustration.

ESP32-P4 — the new one (no radio)

The P4 (2024) is different: no Wi-Fi or Bluetooth, but two 400 MHz cores and support for high-end displays/cameras. It is used as an application host, usually paired with a C6 for connectivity.

How do I know which board I have?

Look for the name printed on the metal module:

ESP-WROOM-32 or ESP32-WROOM-32 → classic ESP32.
ESP32-WROVER → classic with PSRAM (more memory, great for cameras).
ESP32-S3-WROOM-1 → S3.
ESP32-C3-MINI-1 or ESP32-C3-WROOM-02 → C3.
ESP32-C6-WROOM-1 → C6.
ESP32-S2-… → S2.
ESP32-H2-… → H2.

If you see nothing, look at the pin pattern: the classic’s GPIO34–39 are input-only, which is unmistakable once you probe a sensor.

Pinouts (the pin maps)

A pinout is the map that tells you what each pin does. Not all pins are equal: some are input-only, some set the boot mode and some are off-limits.

ESP32 (DevKitC) pinout. Source: Wikimedia Commons, CC BY-SA 4.0.

Guidelines worth gold on the classic ESP32:

GPIO6–11: wired to the flash. Never use them.
GPIO34–39: input only, no internal pull-up.
GPIO0, 2, 12, 15: they affect the boot mode. Avoid them as outputs.
GPIO1 (TX0) and GPIO3 (RX0): the serial port. Use with care.
ADC2 does not work while Wi-Fi is active: use ADC1 (GPIO32–39).

And the C3 pinout, increasingly common:

ESP32-C3 pinout. Source: Wikimedia Commons, CC BY-SA 4.0.

Official, always up-to-date pinouts live at docs.espressif.com. When in doubt, that is the source of truth.

Which one should I buy? (by project)

I want…	Buy
To start and learn	ESP32-C3 or classic ESP32
Home Assistant automation	ESP32-C3 or, for Matter, C6
Camera, audio or AI	ESP32-S3 (+ PSRAM)
A battery Matter/Zigbee node	ESP32-C6 or H2
Lots of pins or USB HID	ESP32-S2
The cheapest sensor node	ESP8266 or ESP32-C3
A big display / HMI	ESP32-P4 + C6

For your first board, buy two: a cheap C3 to tinker with and an S3 with PSRAM if you are thinking about cameras or displays. That way you will not run short.

Where to buy

Here is the part almost no Spanish-language tutorial covers well. Prices and shipping vary a lot by store and country, so treat this as a guide to where to look and what to watch out for, not a fixed ranking.

🇲🇽 Mexico

Mercado Libre — the most practical: domestic shipping, local payment and competitive prices. Watch the sellers: check reputation and make sure the photos are of the real product (not a generic render).
Amazon Mexico — fast shipping (Prime) and easy returns; usually a bit more expensive than Mercado Libre.
UNIT Electronics — Mexican electronics/development store. Good for buying loose modules, sensors and accessories in the same order, though board stock varies.
Local robotics/maker shops — many cities have one (CDMX, Guadalajara, Monterrey); worth it if you need the part today.

🌎 International

AliExpress — by far the cheapest. Downside: slow shipping (2–6 weeks) and variable quality. Great for ordering several boards and sensors at once.
LCSC — genuine components and modules at good prices; useful for volume or PCB design.
Adafruit / SparkFun — their own boards, great quality and excellent docs. Expensive to ship to Latin America, but the standard for serious prototypes.
Mouser / Digi-Key / Farnell — authorized distributors: guaranteed original chips and datasheets. They ship to Mexico, with cost and paperwork.
Espressif (official store) — original modules; useful if you manufacture.

How to avoid bad clones

Ask about the USB-serial chip. CH340 works, but some drivers are painful on macOS. CP2102 usually gives less trouble.
30 vs 38 pins. Many cheap classic boards only break out 30 pins: you lose GPIOs. If you can, pick the 38-pin one.
USB-C vs micro-USB. Micro-USB in 2026 is a pain; pay a little more for C.
Real PSRAM. If you buy an S3 for camera work, make sure it lists PSRAM (8 MB on the good ones).
Antenna. Boards with a U.FL/IPEX connector allow an external antenna if the ESP32 will live inside a metal enclosure.
BOOT and EN buttons. Make sure they exist: without BOOT you sometimes cannot flash.

Common beginner mistakes

Buying a board without native USB thinking the serial port is native.
Choosing the ESP8266 “because it is cheaper” when the C3 costs about the same and is better.
Buying an S3 without PSRAM for a camera project.
Forgetting that on the classic the GPIO34–39 are input only.
Trying to use ADC2 with Wi-Fi on.

Summary

The ESP32 is a SoC with radio, plenty of power and a ridiculous price.
The family is broad: ESP8266 → ESP32 → S2 → C3 → S3 → C6 → H2 → P4.
To start: C3 (cheap) or S3 (powerful). For modern automation: C6.
The pinout is not optional: there are forbidden pins and input-only pins.
Buy where you can return, and distrust boards that are “too cheap”.

Next step: pick your board and set up the toolchain. The next chapters of the ESP32 first steps series will appear on the blog; in the meantime, browse by topic or hit Ctrl + K to search.

Image credits

All photographs come from Wikimedia Commons and are used under their license (CC0 or CC BY-SA 4.0), with attribution:

ESP32-WROOM-32 module — Ubahnverleih (CC0)
ESP32-DevKitC — Edwiyanto (CC BY-SA 4.0)
ESP32-S3 — VectorVoyager (CC BY-SA 4.0)
ESP32-C3 — Popolon (CC BY-SA 4.0)
ESP32-C6 — Popolon (CC BY-SA 4.0)
ESP32-CAM — Nowforever (CC BY-SA 4.0)
ESP8266 — Suyash Dwivedi (CC BY-SA 4.0)
ESP32 DevKitC pinout — Vishnu Maiea (CC BY-SA 4.0)
ESP32-C3 pinout — Srdocdoc (CC BY-SA 4.0)

ESP32-S2, ESP32-H2 and family illustrations are our own.

Introduction to the ESP32

2026-09-16T00:00:00+00:00

This series is the gateway to the ESP32. It is designed to be read in order, but each article also works on its own.

We start by understanding what it is and which variant fits you, continue with the frameworks (Arduino, ESP-IDF, MicroPython, Rust) and editors, and finish by writing your first program on real hardware.

All the code is tested on real boards, with measurements and pinouts — no copy-pasting from other tutorials.

Explore

2026-01-16T00:00:00+00:00

About

2026-01-15T00:00:00+00:00

Hi 👋

This is a blog dedicated to the ESP32: the Wi-Fi and Bluetooth microcontroller that became the heart of countless IoT projects.

Here you will find:

Step-by-step tutorials, from the first blink to production IoT.
Complete projects with schematics, code and design decisions.
Engineering notes: power, antennas, RTOS, security and debugging.

All content is written in Markdown inside this very repository and built with Zola, a static site generator written in Rust. No database, no CMS: just text and Git.

This site’s stack

Layer	Technology
Generator	Zola (Rust)
Templates	Tera
Code highlighting	Giallo
Math	KaTeX
Search	elasticlunr (index generated by Zola)

If you want to suggest a topic or fix something, open an issue or a pull request.