Choosing a Microcontroller — Not Just ESP32 for Everything

ESP32 has become the default MCU recommendation for maker projects, and the recommendation is reasonable. WiFi and BLE built in, dual-core 240MHz, generous GPIO, a rich ecosystem, widely available at reasonable cost. For most projects that need connectivity, it's a strong choice.

But "mostly reasonable default" isn't the same as "always right." Using an ESP32 for a project that needs to run on a coin cell for two years is wrong. Using an Arduino Uno for a project that needs to process audio in real time is wrong in a different direction. And using any microcontroller without understanding why you chose it means you can't systematically improve the choice.

This post is about the framework for MCU selection, not a recommendation that you should always use something other than ESP32.

The dimensions that matter

Connectivity: does the project need WiFi, BLE, Zigbee, LoRa, or no wireless at all? Connectivity adds cost, current draw, and code complexity. If you don't need it, you don't want to pay for it.

Processing power: what computation does the application need? Simple state machines on a handful of GPIO pins: an ATtiny85 handles this at a fraction of ESP32's cost and power. Real-time audio DSP: you need a Cortex-M4 with FPU or better. ML inference: ESP32-S3 or a dedicated AI SoC. Match the compute to the requirement.

Power budget: ESP32 active mode draws 80–240mA. Deep sleep is about 10µA. For battery-powered applications with rare wakeups, the sleep current is fine, but frequent active periods drain batteries quickly. ATtiny/ATmega in sleep draws ~0.1µA. STM32L series are designed specifically for ultra-low-power applications.

Real-time requirements: does the application have hard real-time constraints (motor control, high-frequency ADC sampling, safety-critical timing)? Arduino and ESP32 running FreeRTOS can handle many soft real-time requirements. Hard real-time with deterministic latency usually benefits from bare-metal or RTOS on Cortex-M.

Peripheral requirements: count your I2C devices, SPI buses, UART ports, ADC channels, PWM outputs, and timers. Microcontrollers vary significantly in peripheral count. Make sure your choice has enough of what you need.

When to use what

ATtiny/ATmega (Arduino): low-power, no connectivity, simple logic. LED controllers, sensor interfaces, actuator drivers that report over a serial link. Extremely cheap. Mature ecosystem. Good choice for the simple, low-cost, long-life node in a system.

ESP8266: cheaper and lower-powered than ESP32, single-core, WiFi only. If you need WiFi and don't need BLE or dual-core, it's a reasonable choice. Less used now that ESP32 prices have dropped.

ESP32 and ESP32-S3: the general-purpose wireless MCU. Good for most connected applications. S3 adds vector instructions for ML inference.

STM32 (Cortex-M): real-time applications, motor control, applications where precise timing or hardware peripheral capability matters. Steeper learning curve but the hardware capability exceeds most Arduino-compatible boards significantly.

Raspberry Pi (Linux SBC): when you need an operating system, camera interface, USB host, HDMI, or the ability to run Python and heavier software stacks. Not a microcontroller — different category.

The project fit checklist

Before selecting an MCU, answer: what does it need to connect to (network, sensors, actuators)? How often does it wake and for how long? What's the battery life requirement? Does it have hard real-time requirements? What's the cost target per unit?

If the answers point somewhere different from your default MCU, pay attention. The most common mistakes I see: ESP32 in battery-powered applications where the power consumption is only addressed with deep sleep hacks (when a lower-power MCU was the right answer from the start), and ATmega in projects that need to process significant data (when a Cortex-M4 was clearly needed but the Uno was familiar).

The comfort with a familiar MCU is real and has value — the ecosystem knowledge, the library support, the debugging familiarity. Just make sure the comfort isn't overriding a decision that should be made on technical merits.