Popular. Yet, invisible.
Welcome, to the real world.
My introduction to Embedded Systems was, like it was for most of us, using an Arduino and blink an LED. A senior in college introduced me to it when I was in first year. What followed was 4 years of tinkering around with YouTube, Forums and channels. Tons of ideas, tons of libraries. It was fun. When my career started in embedded systems, these were nowhere to be found. Every project relied on STM32, NXP and other micro controllers. I noticed that many products do not rely on these hobby controllers and that there is a gap between what the hobby MCUs offer and what the real world demands. This post is a compilation of those observations.
The problem isn't that these boards are bad. It's that they're solving a different problem than what production demands.
What "Production" Actually Demands
The classic "it works on my machine" is a pretty low bar in embedded systems. Desk prototypes hide power, timing and reliability issues that only appear in production. You could think of a 100 issues and solve it on desk, production will always give you the 101st issue. And that is what causes returns, redesigns and cost overruns.
The supply chain is the primary consideration during production. When you design around a hobby MCU, you're locked into its vendor form factor like the PCB layout or the antenna design. You will have little to no tuning options. And during a shortage, which is far more common than you think in electronics, you cannot swap out to a different vendor like you would have been able to with a Cortex-M MCU. You'd have to redesign the whole thing from ground up. With STM32, NXP, or Renesas, alternate sourcing is a simple procurement decision.
Certification is next. Remember the locked vendor form factor? Getting an FCC or CE approval, which btw is pretty darn important, means you are trusting a third party's design considerations. Something you did not contribute to. This means, you own the certification costs and risks but not the design. Compare that to spinning your own hardware on a Cortex-M with an external radio module that's already pre-certified; your path to compliance is dramatically cleaner.
Then there's timing determinism. Recently, I was working on tuning an NFC controller to nanosecond precision (it was required to meet the emission compliance), i.e. tuning values at 0.0000000001 intervals. Good luck doing that with an ESP32.
ESP32 runs on an underlying FreeRTOS architecture that can provide concurrency but not determinism. And the higher your product is on the SIL Scale, the more determinism and control you need.
ARM's Dominance
People assume ARM won the embedded market on performance. That's not quite right. ARM's advantages, low cost, low power, low heat, made it useful across an enormous range of applications, but what really sealed its dominance in embedded was something less glamorous: ecosystem maturity.
The Cortex-M family is optimised for low-cost, energy-efficient microcontrollers, and has been embedded in billions of consumer devices. GCC for ARM has been production-tested across domains for decades. IDEs, when I used IAR Embedded Workbench or STM32CubeIDE, i could not go back to Arduino IDE, the tools, debugging options these IDEs offer are simply next level. Arduino IDE is still good but its not this.
There's also the portability argument. Every major silicon vendor, ST, NXP, Renesas, TI, Microchip builds their flagship MCU lines on Cortex-M cores. That means your FreeRTOS knowledge, your CMSIS peripheral driver patterns, your debugging methodology, all of it travels across vendors. If ST has a supply issue, you migrate to NXP. Your firmware architecture survives the transition because the underlying core is the same. That kind of portability doesn't exist when you're building on Xtensa (ESP32) or AVR (Arduino).
The Cortex-M4 also includes a Memory Protection Unit, DSP instructions, and a floating-point unit hardware features that production designs depend on for both performance and safety. The MPU alone is worth the conversation: it lets you partition memory regions between privileged and unprivileged code, catching stack overflows and rogue pointer writes before they corrupt critical data. ESP32 has no equivalent.
![Source: Wikipedia [https://en.wikipedia.org/wiki/ARM_Cortex-M]](https://cdn.hashnode.com/uploads/covers/698dd841e3c05e85cf1b7d63/0743579c-b6e3-40c8-9ff6-053088ba9b18.png align="center")
The Real Cost of Abstraction
The Arduino framework for the ESP32 is a compatibility layer running on top of ESP-IDF that flattens the complex, multi-threaded reality of the ESP32-S3 into the familiar setup() and loop() structure. As system complexity grows, this flattening becomes a significant constraint.
Here's a concrete example of where that bites. When high-throughput Bluetooth scanning overlaps with Wi-Fi transmission on the ESP32-S3 under the Arduino framework, the device can randomly crash or hang because Arduino abstracts the underlying FreeRTOS scheduler into a single-threaded mental model, making it nearly impossible to debug priority inversion between the Wi-Fi stack and the Bluetooth controller. [More on the Arduino's underlying FreeRTOS in an another post! ;)]
Memory management is the other silent killer. Dynamic allocation without careful lifecycle management leads to heap fragmentation in long-running devices. Arduino hides this entirely. ESP-IDF at least surfaces it. A Cortex-M with a properly configured MPU catches it at fault-time. The further down this chain you are, the earlier and cheaper your bugs become.
Is Arduino truly that bad?
This isn't a hit piece. For proof-of-concept work, hackathons, or validating a specific sensor integration, Arduino is unbeatable. The ESP32 in particular, with onboard Wi-Fi, BLE, dual cores, and a rich community, is genuinely one of the best rapid prototyping platforms available. It belongs in your engineering toolkit.
Knowing when to transition is the key! Early MCU decisions compound quietly, by the time problems are obvious, fixing them costs significantly more. The prototype that proved your concept is NOT the architecture your product should ship on.
Finally,
The transition from POC to production isn't just MCU or something technical. It's a shift in the questions you ask. On the bench, the question is "does it work?" In production, the question becomes: "will this work in 50,000 units, on hardware I haven't personally assembled, at -20°C, unattended, for five years?".
This post isn't about pros and cons, its just an account for the exploration I've done when moving from building final year projects to building for actual companies. Over time I understood that, every tooling choice, every abstraction, every dev board shortcut has a cost, and that cost gets paid in production.
Thank you for reading thus far! See you folks in the next one:)
Cheers...!
