Hardware

The Chip Everyone Reaches For

Why It Is in Everything

An ESP32 puts a 32-bit processor, Wi-Fi, Bluetooth, a large pile of peripherals and a mature free toolchain into a part that costs a couple of euros in ones. Before it existed, adding Wi-Fi to a product meant a separate radio module, a host processor, a licence conversation and a certification exercise. Espressif collapsed all of that into a component you can solder down, and the effect on the industry was not subtle.

That is genuinely why it is in everything, and it is a good reason. The failure mode is not choosing it; the failure mode is choosing it without noticing that the decision has consequences the prototype will never reveal. A device on a bench with a USB cable behaves nothing like the same design on a battery on a wall, and the gap between those two is where most ESP32 projects lose their schedule.

The Line, and What Actually Changed

The naming is unhelpful, because the parts are not a progression along one axis. They are a spread of different trade-offs that happen to share a toolchain.

The ESP8266 is the original, and it is a different animal. Single core, Wi-Fi only with no Bluetooth, very little usable RAM once the Wi-Fi stack has taken its share, one poor analogue input, and no secure boot or flash encryption worth the name. It is still cheap and there is an enormous amount of code for it. For a new product it is the wrong choice in almost every case, mostly on the security point: a device you cannot sign firmware for is a device you cannot safely update in the field.

The ESP32 proper added a second core, Bluetooth alongside Wi-Fi, hardware cryptography, secure boot, flash encryption and a low-power coprocessor. It is the part most people mean by the name and it is still perfectly good, with two known weaknesses covered further down.

Then the line splits rather than advances. The S2 is single core, has native USB, and, to a lot of people's surprise, no Bluetooth at all. The S3 is the one to reach for when the device has a screen or does signal work: dual core, BLE, native USB, more memory and vector instructions that make on-device processing viable.

The C3 is the quiet one that matters most. It moved to RISC-V, it is cheap, it has Wi-Fi and BLE and the modern security block, and it is positioned as what an ESP8266 design should become. For a small sensor or actuator it is usually the right answer and it is not the part people reach for by reflex.

The C6 adds Wi-Fi 6 and, more interestingly, an 802.15.4 radio, which is what puts Thread and Zigbee and therefore Matter in reach. The H2 is the same idea with the Wi-Fi removed, for mesh end devices that do not need it. Espressif has continued past these, including parts aimed at dual-band Wi-Fi and at application processing without a radio, and if that is your requirement it is worth checking what is currently in volume production rather than what has been announced.

	Cores	Radio	USB	Secure boot	Typical use
ESP8266	1	Wi-Fi	no	no	legacy only
ESP32	2	Wi-Fi + BT + BLE	no	yes	general purpose
ESP32-S2	1	Wi-Fi	yes	yes	USB peripherals
ESP32-S3	2	Wi-Fi + BLE	yes	yes	screens, audio, on-device processing
ESP32-C3	1 (RISC-V)	Wi-Fi + BLE	yes	yes	small sensors, ESP8266 replacement
ESP32-C6	RISC-V	Wi-Fi 6 + BLE + 802.15.4	yes	yes	Thread, Zigbee, Matter
ESP32-H2	RISC-V	BLE + 802.15.4	yes	yes	mesh end devices, no Wi-Fi

The Power Question, Answered Honestly

This is where projects go wrong, and it goes wrong because the number everyone measures first is meaningless.

A development board is not the chip. It carries a USB-to-serial bridge, a linear regulator chosen for convenience rather than quiescent current, a power LED that nobody thinks about, and often a level shifter or two. Those parts do not sleep. Measure a development board in deep sleep and you will see tens of milliamps, conclude that battery operation is impossible, and be wrong. Measure a bare module with a decent regulator and the same firmware and the datasheet figure of single-digit to low tens of microamps is achievable.

So the first thing to do on any battery design is build the actual power topology, not evaluate the dev board. Everything after that is arithmetic.

The arithmetic is worth doing in the open, because it is the part that decides the product. Take two good AA lithium cells, call it 2,500 mAh. Assume 20 microamps asleep and a fast, cached Wi-Fi join that takes two seconds at an average of 120 milliamps, which is optimistic but achievable when the credentials and the IP are already known. One join then costs about 0.067 mAh.

Reporting every fifteen minutes is 96 joins a day, which is 6.4 mAh, plus half a mAh of sleep. That is a shade under seven mAh a day and the cells last about a year. Move to hourly and it is 2.1 mAh a day and a little over three years. Move to every six hours and it is under one mAh a day and the cells outlive the product.

Nothing changed in that calculation except the reporting interval, and the answer moved by a factor of nine. This is why the reporting interval is a product decision made early and defended, not a configuration value someone tunes at the end.

A Wi-Fi device on a battery is not impossible. It is a device whose battery life is set almost entirely by how often it talks, and every conversation about extending it is really a conversation about talking less.

Two things wreck this in practice and both are avoidable. A join that has to scan, associate and run DHCP from scratch costs several times a cached one, so anything that causes a full reconnect on every wake is the single biggest power bug you can have. And a device that cannot reach the access point retries, which is the mechanism that turns a marginal signal into a flat battery in a fortnight. Bound the retries, back off, and treat a failed report as a normal event rather than something to fight.

The Analogue Weaknesses

The original ESP32's analogue-to-digital converter is the part's least pleasant feature, and it catches people who assume a modern microcontroller has a competent one.

It is noticeably nonlinear across its range and it is noisy, so a reading taken naively will not agree with a multimeter. Espressif ships per-chip calibration data in the fuses and a correction routine that uses it, and applying that is not optional if the number matters. Averaging helps with the noise and does nothing for the nonlinearity.

The second issue is a genuine trap: on the original ESP32, one of the two converters shares hardware with the Wi-Fi radio and is unavailable while Wi-Fi is running. A design that puts a sensor on the wrong pin works perfectly during development, when the radio is often idle, and then returns nothing in the field. Check which converter a pin belongs to at schematic stage.

The later parts improved this and none of them are precision instruments. Where a measurement genuinely matters, and particularly where it will be compared across a fleet or over years, put an external converter on the board. A dedicated part with a proper reference costs a euro or two and removes an entire category of argument.

Security Is a One-Way Door

The ESP32 family has a real security story: signed firmware, encrypted flash, hardware cryptography. It is good, and it has a property that surprises people, which is that enabling it is permanent.

Secure boot and flash encryption are armed by blowing fuses on the die. Fuses do not un-blow. A device that has been through that process cannot be returned to an open state, which is correct behaviour and also means a mistake in the key material or the process is a scrapped unit rather than a re-flash.

The consequences are all about sequencing. Decide before production whether the product needs signed firmware, because retrofitting it to units already in the field is not possible. Establish where the signing key lives and who can use it before the first device is provisioned, because that key is the product's identity for its whole life and there is no recovery from losing it. And exercise the whole flow, including an over-the-air update to a secured device, on units you are prepared to destroy, because the first time it goes wrong you want it to go wrong on the bench.

Whether you need any of it is a judgement rather than a default. A device that will never be updated and holds no credentials worth stealing does not require secure boot. Anything that receives firmware over the air does, because an unsigned update path is an open invitation, and the security article covers why that ends up on a review board's list.

The Certification Argument

The commercial reason to use a module rather than a bare chip is worth stating plainly, because it is usually larger than the price difference.

A pre-certified module arrives with its radio approvals already done for the major regions. Designing with the bare silicon and your own antenna means the radio approvals become yours, which is a test-house engagement, a schedule and a cost that a small product often cannot carry. The module costs a little more per unit and removes that entirely.

The exception is volume, where the certification cost amortises and the per-unit saving starts to matter, and designs where the antenna has to be integrated into the product in a way no module allows. Both are real, and both are decisions to make deliberately rather than to drift into.

Where the S3 Earns Its Place

Seeed's SenseCAP Indicator is a good illustration, because it is an ESP32-S3 doing exactly what the S3 is for rather than what people usually ask an ESP32 to do.

It is a small desk device built around a four-inch capacitive touchscreen, powered over USB-C, running Wi-Fi and Bluetooth, with Sensirion air quality sensing on board and, in some configurations, a LoRa radio on an external antenna. Nothing about it is trying to be frugal, and that is the point: it is mains powered, so the entire power argument above simply does not apply, and the S3's memory and processing go into driving a display and a touch interface smoothly. The Grove headers on the back say the same thing in a different way, since a device expecting you to hang more sensors off it is not one counting microamps.

The detail worth borrowing is that it does not ask the S3 to do everything. There is a second, smaller microcontroller on board handling the sensor and radio side, which keeps the timing-sensitive work away from a processor that is also running a graphical interface and a network stack. That split is a pattern worth copying whenever a device has both a user interface and a measurement job, because the two have completely different failure modes and debugging them in one firmware image is unpleasant.

It also happens to carry the parts from the other articles here, which makes it a convenient thing to have on a desk: the carbon dioxide measurement behaves the way the SCD piece describes, including the self-heating offset on its own temperature channel, and the volatile organic compound reading next to it is the inferred rather than measured kind.

When to Use Something Else

Four situations where I recommend against it, and the first is the common one.

If the device must run for five years or more on a primary cell, Wi-Fi is the wrong transport and the chip choice follows from that. The arithmetic above tops out around three years at hourly reporting under favourable assumptions, before cold weather and self-discharge take their share. A low-power radio and a microcontroller built for microamp operation is a different class of design, and the connectivity article works through when that is the right shape.

If the product is safety-related or subject to functional safety requirements, this is not the part and Espressif does not claim it is. That is a different silicon vendor and a different development process.

If certification, longevity commitments and supply guarantees have to be contractual, read what is actually offered before designing it in. Espressif publishes longevity commitments and they are reasonable; the point is to check them against your product's expected life rather than assume.

And if the radio requirement is something the family does not cover, five gigahertz Wi-Fi historically, or a cellular link, then the decision is being made by the radio and the host processor follows.

What I Provide

Most of my involvement with these parts is at the point where a working prototype has to become a product, which is a different exercise from making it work. That means the power topology built and measured rather than assumed, the reporting interval decided from a battery target rather than from a habit, the analogue path put on a converter that can be trusted if the measurement matters, and the secure boot flow exercised end to end before anything is provisioned.

Where a device is already in the field and the batteries are not lasting, the diagnosis is nearly always in one of three places: a reconnect that is not using cached credentials, a retry loop with no ceiling, or a rail that is not actually going to sleep because something on the board is holding it up. All three are measurable in an afternoon with a supply and a shunt, and all three look identical from the server side, which is why they tend to get misdiagnosed as a sensor problem.