Four families, four shapes of project
The "what board should I use" question is a beginner question with an experienced answer: it depends on the project's electrical, software, and operational shape. Below is the framework we use, with the reasons each family wins or loses in a given context.ESP32 (Espressif)
Strengths: WiFi + BLE on-die. Cheap (~$3 in volume). Active community. Arduino, ESP-IDF, MicroPython, Rust — all viable. Power management is workable.Weaknesses: not deterministic enough for hard real-time. The dual-core architecture is a quirk you have to learn (FreeRTOS pinning matters). Flash wear-out under heavy logging is real.
Default for: WiFi-connected sensor nodes, BLE peripherals, prototypes that need wireless without a separate radio. Anywhere "got an internet connection" is the answer.
STM32 (ST Microelectronics)
Strengths: enormous portfolio (F0 to H7 to U5), genuinely industrial-grade. Hardware peripherals (timers, ADCs, DMA, CAN) are class-leading. Extended availability — STM32 chips you spec today will be available in 2030+. STM32CubeIDE / Cube ecosystem is comprehensive (and divisive).Weaknesses: no built-in wireless on most parts (STM32WB / WL excepted). The vendor IDE is heavyweight; many teams move to PlatformIO or bare CMake + GCC. Pricing has crept up post-supply-chain-crisis.
Default for: industrial-grade embedded — CAN bus nodes, motor controllers, sensor interfaces, anything safety-relevant. The "boring, reliable" default.
Raspberry Pi (3 / 4 / 5 / CM4 / CM5)
Strengths: full Linux. The whole Python / OpenCV / Docker ecosystem is yours. CM4 / CM5 + carrier board is a credible industrial pattern. Compute Module variants are the right choice; the consumer Pi is harder to deploy at scale.Weaknesses: Linux is not real-time without effort. Boot times measured in tens of seconds. SD card wear-out is real (use eMMC on CM, or USB / NVMe boot). Industrial temperature range is limited (CM4 industrial variant helps).
Default for: gateways, edge inference targets that don't justify Jetson, kiosks, anything where the project is fundamentally a Linux app that happens to be in a small enclosure.
RP2040 (Raspberry Pi Foundation)
Strengths: cheap, dual-core Cortex-M0+, Programmable IO (PIO) is genuinely novel — the ability to bit-bang almost-anything in deterministic hardware is a differentiator. C/C++ SDK and MicroPython both first-class.Weaknesses: young ecosystem relative to STM32 / ESP32. Industrial extended-temp variants didn't exist initially (RP2350 improves the picture). Wireless requires an external module on the bare RP2040, or RP2040W variants.
Default for: specialised peripherals where PIO solves a problem that would otherwise need an FPGA — interfacing exotic protocols, bit-banging cameras, DIY logic analyzers. Less universal than the others but with a unique niche.
Decision matrix
- Need WiFi + BLE on a sensor node → ESP32
- Need rock-solid CAN / industrial peripherals → STM32
- Need Linux applications, OpenCV, Docker → Raspberry Pi (CM4/CM5)
- Need exotic timing-critical IO → RP2040 (or FPGA)
- Need long-term silicon supply (10+ years) → STM32, with caveats
- Need cheapest possible WiFi node → ESP32
- Need a dev kit yesterday → whichever you already have on the bench
One thing we'd warn about
Module vs raw chip: at any volume above 100 units, the right path is a custom PCB with the bare chip. Modules add cost, height, and FCC requalification surprises. Below that volume, a module saves you a re-spin and is worth the premium.What's your default? And — controversial — has anyone fully migrated from Arduino-IDE to PlatformIO or are folks still running both?
