Choosing an MCU Architecture and Connectivity Stack for a New Product

Every new embedded product starts with a handful of decisions that are expensive to unwind later: which microcontroller architecture, whether to run an RTOS or full embedded Linux, which wireless protocol gets the device its data, and how much of that needs to happen on-device versus in the cloud. This is the framework we walk clients through before any of that gets locked in.

MCU architecture: ARM Cortex-M, Xtensa, or RISC-V

ARM Cortex-M is still the default answer for most products: the tooling is mature, the ecosystem of HALs and vendor SDKs is enormous, and hiring for it is easy. Unless something specific points elsewhere, this is where we start.

Xtensa (the architecture behind chips like the ESP32) earns its place when WiFi and BLE need to be on the same die as the application processor, cheaply. The trade-off is a smaller, more vendor-specific tooling ecosystem.

RISC-V is the one to watch rather than default to today. It’s genuinely compelling when licensing cost matters at volume, or when a custom instruction extension would solve a real problem, but the tooling and third-party library support still lag ARM’s in most areas we’ve tested.

RTOS or embedded Linux

This is really a question about what the product needs to do, not which is “better”:

• RTOS or bare-metal when the product needs deterministic, low-latency response, has a tight power budget, or needs to boot in milliseconds. Most sensor nodes and motor controllers live here.
• Embedded Linux once the product needs a real application layer: a UI, a package manager, containers, or Python/Rust application code that a small team can iterate on quickly. The cost is a heavier boot path and a bigger security surface to manage.

A fair number of products end up as both: an RTOS-based sensor/actuator layer talking to a Linux-based gateway or head unit.

Wireless and cellular connectivity

The protocol choice comes down to range, power budget, and whether there’s existing infrastructure to talk to:

• BLE for phone-paired, battery-powered devices with modest range.
• WiFi when there’s already a network to join and power isn’t the tightest constraint.
• ZigBee / 802.15.4 for mesh networks of many low-power nodes.
• LoRaWAN for long range at very low data rates and very low power, often with no existing infrastructure required.
• NB-IoT / cellular IoT when the device needs to report from anywhere, with no local gateway to rely on, and the data volume is small.

Security, from the start

Secure Boot, encrypted firmware updates, and device identity aren’t features to bolt on before shipping; they shape the bootloader and partition layout from day one. On embedded Linux specifically, a TPM plus SELinux (or an equivalent MAC framework) gives a product a credible answer when a customer’s security team asks how a compromised process is contained.

Rust, C/C++, and containerization

C and C++ remain the default for firmware and for most embedded Linux application code, mainly because that’s where the libraries and existing codebases already are. Rust is a serious option for new application-layer code where memory safety matters and the team is willing to invest in the learning curve; we increasingly reach for it on new modules rather than whole rewrites. On the Linux side, Docker (or a lighter container runtime) is a practical way to keep an application’s dependencies reproducible across development, testing, and the field, without it needing to mean “just like a cloud server.”

Where Edge AI actually fits

Edge AI earns its place when a round trip to the cloud is the wrong answer, either because it’s too slow, too expensive at volume, or has to work with no connectivity at all. Wake-word detection (deciding whether to wake a bigger process at all) and anomaly detection (flagging something unusual in sensor data without shipping every sample to the cloud) are the two patterns we see most often, both running comfortably on a Cortex-M class part with a small enough model.

None of these decisions are made in isolation. The architecture affects what RTOS or Linux options are available, the connectivity choice affects the power budget which affects the MCU choice, and security requirements can rule out an otherwise-attractive option entirely. Worth spending a week on a proof-of-concept exploring the trade-offs before committing to a production design.