The vendor's dev-kit demo always looks fine. The framework that survives contact with a real BOM, a real battery budget and a real regulatory deadline is different — here's how the three most common families actually compare.
For a battery-powered connected product, the MCU decision is really three decisions bundled into one: the processor core, the radio, and the ecosystem you'll be locked into for the life of the product. STM32 (STMicroelectronics), ESP32 (Espressif) and nRF52 (Nordic Semiconductor) are the three families that come up most often in early scoping conversations — and each one optimizes for a different one of those three axes.
STM32 is an Arm Cortex-M family with an unusually wide range — from low-cost Cortex-M0+ parts to high-performance Cortex-M7 and dual-core M4/M7 lines — and no integrated wireless radio on most of the catalog. That's a deliberate tradeoff: STM32 tends to win when the product needs serious compute or analog/peripheral density (motor control, sensor fusion, multiple high-speed buses) and connectivity is handled by a separate radio module or a cellular modem. The ecosystem (STM32CubeIDE, HAL/LL libraries, STM32CubeMX peripheral configuration) is mature and well-documented, and STMicroelectronics' distribution and second-source availability tends to be broad, which matters for supply resilience.
ESP32 (Espressif) bundles a capable core with Wi‑Fi and Bluetooth/BLE radios on a single chip, at a price point that's hard to match if the product genuinely needs Wi‑Fi. That integration is also the tradeoff: ESP-IDF is a heavier, more Linux-adjacent build environment than a typical bare-metal MCU toolchain, and Wi‑Fi's power draw makes ESP32 a poor default for a coin-cell or multi-year battery target unless the product's duty cycle is built around infrequent Wi‑Fi bursts.
Nordic's nRF52 series is built around ultra-low-power BLE (and in some parts, Thread/Zigbee via 802.15.4) as the primary use case, with a radio and RF front-end tuned specifically for that job. For a wearable, a sensor tag, or anything where the battery has to last months on a coin cell, this is usually the first family evaluated. The tradeoff is a narrower general-purpose compute envelope than STM32's higher-end parts, and an SDK (nRF Connect SDK, built on Zephyr) that's opinionated toward BLE-centric application structure.
In practice the choice comes down to answering three questions in order: what's the actual battery/duty-cycle target, what radio(s) does the product need, and what compute headroom does the rest of the firmware (sensor processing, display driving, edge inference) require. We generally reach for the nRF52 series on ultra-low-power, battery-operated BLE products — wearables, remote sensors — and ESP32 for rapid IoT deployments that need heavy Wi‑Fi connectivity and cloud-edge integration. On one battery-operated edge sensor project, microamp sleep currents and reliable BLE peripheral bridging were non-negotiable, and we chose Nordic's nRF52 over an ESP32 specifically because ESP32's power draw during active Wi‑Fi states would have blown through the battery-life target — the decision came down entirely to power budget versus network throughput. For more on how we scope firmware architecture generally, see our firmware work and RTOS vs. bare-metal.
