The MCU selection decision sits at the heart of every IoT hardware design. Choose well, and everything downstream — firmware development, protocol support, power optimization, and manufacturing — is easier. Choose poorly, and you may find yourself six months into development discovering that your target MCU can’t run TLS without exhausting RAM, or that its sleep current is 10x higher than you modeled, or that supply chain issues make it unavailable. This guide gives you the framework and the specific chip knowledge to make confident MCU and hardware selection decisions.
The Hierarchy of Hardware Decisions
IoT hardware selection involves three levels of decision:
Level 1: Bare SoC vs. pre-certified wireless module A bare SoC (System on Chip — like the ESP32-S3 chip itself or the Nordic nRF5340) must be designed into a custom PCB with RF circuitry, antenna, power supply, and crystal. This gives maximum control and minimum unit cost at high volume but requires RF engineering expertise and regulatory certification of your custom RF design.
A wireless module (like the ESP32-WROVER-B, Nordic nRF9160-DK, u-blox SARA-R410M) integrates the SoC, RF circuit, antenna or U.FL connector, and regulatory certifications (FCC ID, CE mark) in a single component. You just solder it to your PCB and focus on the application. Higher unit cost than bare SoC but dramatically reduced engineering risk and faster time to market.
General rule: Use modules for volumes under ~50,000–100,000 units/year unless you have dedicated RF engineering talent. At high volumes, the unit cost premium of a module may justify moving to a custom RF design.
Level 2: MCU/SoC selection Within the approach chosen at Level 1, which specific MCU or SoC family is right? This depends on connectivity requirements, processing demands, power budget, and ecosystem.
Level 3: Module/variant selection Once the SoC family is chosen, which specific module or variant? Memory configuration, antenna type, form factor.
Key Selection Criteria
Connectivity requirements are usually the starting point:
- Need Wi-Fi + BLE → ESP32 family or Nordic nRF7002 (Wi-Fi 6 + BLE 5)
- Need BLE only → Nordic nRF52 family (gold standard for BLE)
- Need BLE + Thread → Nordic nRF52840, Silicon Labs EFR32MG
- Need cellular (LTE-M/NB-IoT) → Nordic nRF9160, Quectel BG95, SiMCOM SIM7080
- Need LoRa → STM32 + SX1276 radio, or LLCC68-based modules
- Need sub-GHz proprietary → TI CC1352, SiLabs EFR32FG
Processing requirements:
- Simple sensing and reporting: Cortex-M0+ (lower cost, lower power)
- Moderate computation (filtering, state machines, BLE + application): Cortex-M4 with FPU
- Heavy computation (ML inference, cryptography, multi-protocol): Cortex-M33, dual-core (ESP32-S3, nRF5340)
Power requirements:
- Sub-µA sleep with fast wakeup: Nordic nRF52 series (0.4µA System OFF), STM32L4+ (0.3µA Standby)
- Moderate power: ESP32 (150µA deep sleep — significantly higher than Nordic)
- Not power constrained: Raspberry Pi CM4, i.MX RT
Memory requirements:
- Class 1 (10 KB RAM): STM32L0, nRF51822
- Class 2 (50–100 KB RAM): nRF52832, STM32L4
- Unconstrained (256 KB+ RAM): nRF52840, ESP32-S3, STM32H7
Development ecosystem:
- Largest general IoT community: ESP32 (enormous community, tutorials, examples)
- Best BLE ecosystem: Nordic nRF52 with nRF Connect SDK
- Most vendor-neutral: STM32 (STMicro invests heavily in HAL libraries and IDE)
- Linux-friendly: Raspberry Pi, i.MX RT
ESP32 Family: The Developer Favorite
Espressif’s ESP32 family has become the most popular MCU family for IoT hobbyists and many professional IoT products due to its combination of features, cost, and ecosystem support.
Key variants:
| Chip | Cores | RAM | Flash | Connectivity | Notable Feature |
|---|---|---|---|---|---|
| ESP32 | Dual Xtensa LX6 | 520 KB | External | Wi-Fi + BLE 4.2 | Original, large community |
| ESP32-S3 | Dual Xtensa LX7 | 512 KB + PSRAM | External | Wi-Fi + BLE 5 | AI acceleration, USB OTG |
| ESP32-C3 | RISC-V | 400 KB | 4 MB built-in | Wi-Fi + BLE 5 | Cost-optimized |
| ESP32-C6 | RISC-V | 512 KB | 4 MB built-in | Wi-Fi 6 + BLE 5 + Thread | Thread/Matter support |
| ESP32-H2 | RISC-V | 320 KB | 4 MB built-in | BLE 5 + Thread/Zigbee | No Wi-Fi, ultra-low cost |
ESP32 strengths:
- Deep sleep current: 150µA (acceptable for many battery applications with careful firmware design)
- ESP-IDF — mature, feature-rich development framework
- Wi-Fi + BLE in one cheap chip
- Huge community on Arduino, ESP-IDF, and ESP-MDF frameworks
- Pre-certified modules (ESP32-WROOM, ESP32-WROVER) from Espressif and many third parties
ESP32 weaknesses:
- Deep sleep current (150µA) is much higher than Nordic nRF52 (0.4µA) — ESP32 is unsuitable for true ultra-low-power applications
- RAM can be limited for complex applications (single-application Class 2, despite the 520 KB figure some of RAM is reserved for the radio stack)
- Less deterministic real-time performance compared to ARM Cortex-M MCUs
Best for: Wi-Fi-connected devices, maker/prototype projects, devices not requiring ultra-low power, Matter/Thread products (ESP32-C6/H2).
Nordic Semiconductor nRF52 Family: The BLE Gold Standard
Nordic Semiconductor’s nRF52 family is the benchmark for BLE IoT devices. When power consumption and BLE performance matter, it’s the first consideration.
Key variants:
| Chip | RAM | Flash | Connectivity | Notable Feature |
|---|---|---|---|---|
| nRF52810 | 24 KB | 192 KB | BLE 5 | Ultra-low cost |
| nRF52832 | 64 KB | 512 KB | BLE 5 | Best value in family |
| nRF52833 | 128 KB | 512 KB | BLE 5 + 802.15.4 | Zigbee + BLE |
| nRF52840 | 256 KB | 1 MB | BLE 5 + 802.15.4 + USB | Most capable; Matter/Thread |
| nRF5340 | 256+64 KB | 1 MB+256 KB | BLE 5.3 | Dual-core; application + network |
Nordic nRF52 strengths:
- System OFF current: 0.4µA — exceptional deep sleep power for years of battery life
- SoftDevice BLE stack — highly optimized, well-validated BLE stack
- nRF Connect SDK (Zephyr-based) — mature, well-documented development environment
- Excellent hardware security: TrustZone-M, hardware crypto accelerators, hardware key storage
- nRF52840 is the reference platform for Matter/Thread certification
Nordic nRF52 weaknesses:
- No Wi-Fi support (requires external Wi-Fi module if needed)
- nRF Connect SDK (Zephyr) has a steeper learning curve than ESP-IDF or Arduino
- Higher unit cost than ESP32 at equivalent BOM level
Best for: BLE devices requiring ultra-low power (wearables, medical devices, beacons, asset trackers, smart home accessories), Thread/Matter products, any BLE device where battery life is the primary constraint.
STMicroelectronics STM32: The Professional’s MCU
STM32 is not primarily an IoT connectivity MCU — most STM32 devices don’t include a radio. It’s an extremely popular microcontroller family that excels when you need fine control over the MCU features and can add an external radio as needed.
Relevant families for IoT:
- STM32L0/L1 — ultra-low-power Cortex-M0+, ideal for battery-powered sensing without radio
- STM32L4/L4+ — Cortex-M4F with excellent power management, good for Class 2 devices
- STM32WB — STM32 + BLE 5.2 + 802.15.4 in one package (comparable to Nordic nRF52840)
- STM32WL — STM32 + LoRa radio — ideal for LoRaWAN sensor nodes
- STM32H7 — high-performance Cortex-M7, for edge computing with motor control or DSP
STM32 strengths:
- Enormous portfolio covering every performance/power/feature point
- Excellent HAL libraries and STM32CubeIDE development environment
- Hardware security with TrustZone-M on STM32L5/H5/U5
- STM32WL for integrated LoRa without external radio module
- Strong in industrial applications; -40 to +85°C or -40 to +125°C temperature grades available
STM32 weaknesses:
- Most devices don’t include wireless — requires external radio module or choosing STM32WB/WL
- STM32Cube HAL is somewhat verbose compared to some alternatives
- Slightly higher unit cost than ESP32 for comparable performance points
Best for: Industrial IoT where temperature rating and reliability matter, products requiring fine-grained peripheral control, LoRa products (STM32WL), products needing highest available hardware security (STM32L5 with TrustZone), anything running on bare metal or FreeRTOS without needing integrated radio.
Silicon Labs EFR32: Matter-Ready Silicon
Silicon Labs’ EFR32 family includes the EFR32MG series specifically designed for Zigbee, Thread, and Matter applications, and the EFR32BG series for BLE. The EFR32MG24 is one of the primary Matter reference platforms.
EFR32 strengths:
- Excellent Zigbee and Thread stack support (Silicon Labs’ commercial stack is well-regarded)
- Matter certification path well-defined
- Good security features with Secure Vault option
- Runs on Gecko SDK which includes Matter, Zigbee, and BLE protocol stacks
Module Selection: Making the Pre-Certified Choice
When choosing a module rather than bare SoC, evaluate:
Regulatory certifications included: Verify FCC ID and CE mark are included. Check that the certificate covers your intended use case (some module certifications have conditions about host PCB design).
Operating temperature range: Module specifications for temperature may differ from the bare SoC — verify the module temperature range meets your requirements.
Antenna options: Integrated PCB antenna, external antenna via U.FL connector, or chip antenna. PCB antennas work well in plastic enclosures; external antennas provide better performance and orientation flexibility.
Supply chain reliability: During 2021–2023, many popular IoT modules experienced severe supply chain disruptions. Consider modules with multiple second-source options or robust supply agreements.
Certification assistance: Some module vendors (Espressif, Nordic, u-blox) provide modular certification support — help ensuring your host board design doesn’t invalidate the module’s certifications.
Building the Selection Decision
Use this decision flow:
- Connectivity first: What radio technology is required? This often constrains the chip family.
- Power budget: Is ultra-low power required (sub-µA sleep)? Nordic. Is moderate power acceptable (100µA sleep)? Many options.
- Processing: Simple application? Cortex-M0+. DSP/float needed? Cortex-M4F. ML inference? Cortex-M55 or dual-core.
- Memory: Determine RAM and flash requirements from your firmware roadmap (see IoT device classes for guidance).
- Ecosystem: Does your team have existing expertise with a vendor’s SDK? Factor that in.
- Scale: Low volume (< 50K units)? Use a pre-certified module. High volume? Evaluate bare SoC.
- Supply chain: Verify availability at your projected build rate.
For expert guidance on MCU selection for your specific product requirements, UABit’s IoT device development team provides hardware architecture consulting as part of our development engagements.
Conclusion
Hardware selection for IoT is not about finding the “best” MCU — it’s about matching the MCU’s capabilities to your product’s specific requirements across connectivity, power, processing, memory, ecosystem, and economics. The ESP32 family dominates cost-sensitive Wi-Fi+BLE products. Nordic nRF52 leads for BLE devices where battery life is paramount. STM32 covers the widest range of professional IoT applications. Silicon Labs EFR32 leads in Thread/Matter/Zigbee.
Make this decision deliberately, with clear requirements in hand. A well-chosen MCU makes every subsequent development stage easier.
Further reading:
- Espressif product selector — ESP32 family comparison
- Nordic Semiconductor product portfolio — nRF series comparison
- STMicroelectronics MCU selector — STM32 family browser
- Microchip product selector — PIC and SAM MCU selection
- Hackster.io hardware comparison articles — community IoT hardware reviews
IoT & AIoT Weekly
Get the best IoT development content delivered weekly. No noise, just signal.