Engineers online — usually reply within the hour
Home/Articles/Engineering Choices
Articles · Engineering Choices

STM32 vs ESP32 vs nRF52: which microcontroller should your product use?

A practical comparison of the three most common IoT microcontroller families — STM32, ESP32 and Nordic nRF52 — and how to choose between them for real products.

Published 09 August 2026 · Inventors Tech engineering team

As a rule of thumb: choose Nordic nRF52 for battery-powered Bluetooth Low Energy products, ESP32 when you need Wi-Fi on a budget and power is less critical, and STM32 when you need fine-grained control, wide peripheral choice, or an industrial-grade part with a long supply lifetime. Most real decisions come down to connectivity, power budget and supply chain — not benchmark numbers.

What is each family actually good at?

  • STM32 (ST Microelectronics) — the broadest general-purpose family: everything from tiny low-power parts to powerful cores, an enormous peripheral set, industrial temperature ranges and long product-longevity commitments. The default choice for control-heavy and industrial designs.
  • ESP32 (Espressif) — integrated Wi-Fi and Bluetooth at a remarkably low price, with generous memory. Ideal for mains- or USB-powered smart devices; its sleep-mode power story has improved but still trails Nordic for coin-cell-class products.
  • nRF52 (Nordic Semiconductor) — the industry benchmark for Bluetooth Low Energy: excellent radio, very low sleep currents and a mature BLE stack. The default for wearables and battery-first BLE products.

Which questions actually decide it?

Start with connectivity: if the product needs Wi-Fi, ESP32 earns its place; if it's BLE-only and battery-powered, nRF52 is hard to beat; if connectivity is secondary to control, sensing or motor drive, STM32's breadth wins. Then power: products expected to run months on a battery need the sleep-current discipline Nordic parts are built around. Then supply chain: for a product you'll manufacture for years, part availability and second-sourcing matter more than any spec-sheet difference. Finally, ecosystem: your team's existing tooling and the quality of vendor SDKs are real costs, not soft preferences.

Does the choice lock you in?

Less than founders fear, more than nobody admits. Well-architected firmware isolates hardware-specific code behind drivers, so a port is weeks, not a rewrite — that's one reason firmware architecture matters early. But the radio stack, power architecture and certification work don't transfer for free, so it's worth choosing carefully the first time.

What do we actually use?

All three, daily — the right answer genuinely depends on the product. Our own CanvasBT e-ink frame is a battery-first BLE device, and the architecture choices behind its year-long battery life came directly from this kind of analysis. If you're weighing MCUs for a product, describe it to us on WhatsApp — an engineer will give you a straight recommendation, free.

Building something like this?

Talk it through with an engineer — free, honest, no sales pitch.

Have a project? Let's talk
WhatsApp us Call now