ESP32 Microcontroller Overview

In short: The ESP32 is a 40 nm, dual-core 240 MHz Xtensa LX6 SoC with 520 KB SRAM, integrated 2.4 GHz Wi-Fi and Bluetooth, and a rich peripheral set, so one cheap chip replaces an MCU plus a radio module, which is exactly why interviewers expect you to prefer it for connected products.

What the ESP32 actually is

Espressif's ESP32 is a system-on-chip, not a classic microcontroller. A classic 8-bit AVR or a Cortex-M0 part gives you a core, a little flash and some peripherals. The ESP32 packs two CPU cores, a full 802.11 b/g/n Wi-Fi MAC and baseband, a Bluetooth 4.2 controller (BR/EDR plus BLE), RF front end with balun and power amplifier, power management and security blocks onto a single die. You supply a 3.3 V rail, a 40 MHz crystal, an antenna and external SPI flash, and you have a networked computer.

Interviewers like this question because the answer reveals whether you think in systems. The right framing is integration: fewer chips, fewer RF layout risks, and a certified module (such as the ESP32-WROOM-32) that carries FCC and CE approvals, so your product skips months of radio compliance work.

Key fact: Typical ESP32 headline numbers: 2 x Xtensa LX6 at up to 240 MHz, 520 KB SRAM, 448 KB ROM, 34 GPIOs, 12-bit ADC, Wi-Fi 802.11 b/g/n, Bluetooth v4.2 BR/EDR + LE.

The dual-core Xtensa LX6

The cores are called PRO_CPU (protocol) and APP_CPU (application). Both are 32-bit Harvard-architecture Xtensa LX6 cores from Tensilica, now part of Cadence. Xtensa is a configurable ISA: designers choose which instruction options, such as a single-precision FPU, MAC16 multiplier or windowed registers, to synthesise. That configurability is a classic Cadence IP story and a nice talking point when asked how ESP32 differs from fixed Arm Cortex-M cores.

In ESP-IDF the default arrangement runs FreeRTOS in symmetric multiprocessing mode. The Wi-Fi and Bluetooth stacks normally sit on core 0, while your application tasks sit on core 1, which keeps radio timing jitter away from your control loop. You can pin a task with xTaskCreatePinnedToCore(). Interview trap: two cores do not mean two times the speed. Shared bus, shared cache and shared flash mean memory-bound code scales poorly, and a spinlock or critical section on one core can stall the other.

The LX6 has a hardware FPU for single precision only, so double arithmetic is emulated in software and is roughly an order of magnitude slower. Use float for DSP-style loops.

Memory: where interviews get tricky

The ESP32 has 520 KB of on-chip SRAM, split into SRAM0 (192 KB, instruction use and cache), SRAM1 (128 KB) and SRAM2 (200 KB), plus 8 KB of RTC slow memory and 8 KB of RTC fast memory that survive deep sleep. Code does not run from internal flash directly. External QSPI flash, typically 4 MB, is mapped through a cache into the address space, and code marked IRAM_ATTR is placed in internal RAM so that it can run while the cache is disabled during flash writes. Forgetting this is a classic cause of crashes in interrupt handlers.

Modules such as the ESP32-WROVER add 4 or 8 MB of PSRAM, which is useful for camera frame buffers or TLS with large certificates but is accessed over SPI at far lower bandwidth than SRAM. Also note that Wi-Fi plus Bluetooth together consume well over 100 KB of heap, so a real application often has only about 200 to 250 KB free.

Key fact: Internal SRAM read is single-cycle class; a cache miss to external flash can cost tens of cycles. Put ISRs and hot loops in IRAM, constants that are hot in DRAM.

Wi-Fi and Bluetooth radios

The Wi-Fi block supports station, soft-AP and combined modes, WPA3 in recent IDF releases, and a maximum PHY rate of 150 Mbit/s, with real TCP throughput near 20 Mbit/s. Transmit power is around +20 dBm at 802.11b rates, and radio current can spike beyond 240 mA, which is why a weak 3.3 V regulator or a missing bulk capacitor causes brown-out resets the moment Wi-Fi starts. Budget at least 500 mA for the supply and place 10 to 100 uF near the module.

Bluetooth is classic BR/EDR plus BLE 4.2. Wi-Fi and Bluetooth share one 2.4 GHz radio and antenna, so the chip time-slices them with a coexistence arbiter. Heavy Wi-Fi traffic reduces BLE connection reliability, an honest limitation to state in an interview. Later family members (ESP32-C3, S3) moved to Bluetooth 5 and RISC-V or newer Xtensa LX7 cores, but the original LX6 part is still the one most question banks mean.

Peripherals

The GPIO matrix is a good example of flexibility trading speed: routing through the matrix adds delay, so very fast signals such as SPI above 40 MHz should use the dedicated IO_MUX pins.

Power modes

Active mode with both cores and radio draws roughly 160 to 260 mA. Modem sleep drops the radio, light sleep pauses the CPU, and deep sleep keeps only the RTC domain, about 10 uA for the chip, with real boards often 100 uA or more because of the LDO and USB-serial chip. A battery sensor node that wakes every 15 minutes, sends 2 s of Wi-Fi traffic at 100 mA, will average around 0.23 mA, so a 2000 mAh cell lasts roughly a year in theory.

Why ESP32 beats classic MCUs in IoT interviews

Compare it with an STM32F103 (Cortex-M3, 72 MHz, 20 KB RAM) or an ATmega328P (8-bit, 16 MHz, 2 KB RAM). Those need an external Wi-Fi module such as an ESP8266, which then needs UART AT commands and its own firmware. With an ESP32 the TCP/IP stack (lwIP), TLS (mbedTLS), MQTT and OTA update client run on the same silicon as your application.

• Cost: modules sell for a few US dollars, with the radio included.
• Security: flash encryption (AES-256-XTS), secure boot, eFuse key storage and hardware accelerators for AES, SHA, RSA.
• Ecosystem: ESP-IDF, Arduino core, MicroPython, and OTA with two app partitions.
• Weaknesses to concede: non-deterministic latency from cache misses and radio activity, high active current, and weaker hard-real-time guarantees than a Cortex-M4 or Cortex-R part, so motor control with microsecond jitter budgets is better served by a dedicated MCU.

The strongest answer states the trade-off: ESP32 for connected, cost-sensitive, medium-performance products; classic MCU for hard-real-time or ultra-low-power work. Keep following the rest of the series, for instance FreeRTOS task scheduling for interviews.

Where silicon design fits in

An SoC like this is built with the same flow you would learn for any chip: RTL in Verilog, verification in Siemens Questa or Synopsys VCS, synthesis in Synopsys Design Compiler or Cadence Genus, and place-and-route in Cadence Innovus or Synopsys IC Compiler II, at TSMC 40 nm. Mixed-signal verification of the RF block is a separate discipline. If you want hands-on design flow skills, ChipXpert's VLSI training programs cover the full RTL-to-GDS path, and our CourseTron courses cover the embedded side.

Ready to go from block diagrams to working firmware? Join the CourseTron Embedded Systems course and build a Wi-Fi sensor node on an ESP32 with hands-on labs. Browse CourseTron courses.

FAQ

Is the ESP32 a microcontroller or an SoC?

Both terms are used. It has MCU-style peripherals and flash-based firmware, but integrates radios, two cores and security blocks, so SoC is the more accurate label.

Why does my ESP32 reset when Wi-Fi starts?

Radio transmit bursts draw up to several hundred mA. A weak regulator or small decoupling capacitor droops the rail, triggering the brown-out detector. Use a 500 mA or better supply and a bulk capacitor.

Can ESP32 run real-time tasks?

Yes, with FreeRTOS, but not hard real time at microsecond scale. Pin critical tasks to the core not running the radio stack and keep ISRs in IRAM.

ESP32 or STM32 for a product?

Choose ESP32 when connectivity and cost dominate. Choose STM32 for deterministic control, richer analog or very low power.