MCU or MPU? The Decision That Locks In Before the Schematic Does
Most MCU-vs-MPU conversations start after someone has already picked one, usually because a dev board was on the desk or a previous project used it. By the time the question gets asked properly, the schematic is drawn and the answer is expensive to change.
The question is worth asking early because it isn't really about clock speed. It's about which category of problem you're willing to own for the life of the product.
What the Decision Actually Locks In
An MCU (STM32 Cortex-M class, for example) runs bare-metal or an RTOS directly against the silicon. Boot time is milliseconds. Power-down modes pull microamps. The toolchain is a C/C++ compiler and a debugger, no OS image, no filesystem, no driver stack to maintain. The tradeoff is that anything the silicon doesn't do in hardware, firmware has to do by hand: networking stacks, filesystem access, display compositing, anything with the complexity of a modern OS service.
An MPU (Cortex-A class, typically running Embedded Linux via Yocto) gets you a real filesystem, a networking stack that already handles the edge cases, package management for third-party libraries, and, critically, a much shorter path to a UI with a display and touch input. The tradeoff is boot time in the seconds, power draw in the tens to hundreds of milliamps even idle, and a Linux image that now needs security patching for the life of the product.
Neither list is a defect. They're different sets of problems, and a field device only has room for one of them.
The Questions That Actually Decide It
Does the device sleep? A battery-powered sensor node that wakes for 200ms once a minute is an MCU problem before anything else gets discussed. An MPU's idle draw makes multi-month battery life arithmetic that doesn't work. If the device is mains-powered or duty-cycled at close to 100%, this constraint disappears and the decision opens back up.
Does the interface need a screen with real graphics, or a handful of status LEDs and a Bluetooth link? A composited touch UI is a multi-week firmware project on an MCU and a solved problem on Linux with an existing toolkit. Status indication and a mobile companion app over BLE is the reverse, trivial on an MCU, unnecessary overhead on an MPU.
What's the certification and compliance scope? An MPU running Linux inherits Linux's CVE surface. Every field-deployed unit becomes something that needs a patch cadence, or it becomes a liability the moment a kernel vulnerability affects the version you shipped. An MCU running firmware you wrote and fully understand has a certification story that's smaller and more contained, there's no third-party kernel to audit.
What's the actual compute load? Signal processing on a handful of ADC channels, CAN bus frame handling, PID control loops, an MCU handles this natively and deterministically. Computer vision, on-device ML inference, or anything that benefits from a full Linux userland and its library ecosystem points toward an MPU, sometimes with a coprocessor MCU alongside it for the deterministic, real-time-critical parts.
Where This Goes Wrong
The failure mode isn't picking the "wrong" chip category in isolation, it's picking based on what's familiar rather than what the device needs, and discovering the mismatch after the PCB is laid out. An MPU chosen because "we might add a screen later" carries its full power and complexity cost from day one, whether the screen ships or not. An MCU chosen to avoid Linux's certification overhead, on a product that later needs a real UI, ends up hand-rolling a UI framework in firmware, a worse outcome than just starting on the right platform.
The other common pattern: MCU and MPU aren't mutually exclusive within a single product. A field device with a touchscreen HMI and a hard real-time motor control loop often runs both, an MPU for the display and connectivity, an MCU as a coprocessor for the control loop that can't tolerate Linux's scheduling jitter. Recognising that split early avoids retrofitting a coprocessor onto a board that wasn't designed for one.
Deciding Before the Schematic, Not After
This is the kind of call that's cheap to get right in a requirements conversation and expensive to unwind once a board is routed around a specific chip's pinout and peripheral set. The clock speed on the datasheet is rarely the constraint that matters, the power budget, the certification scope, and the actual interface requirement usually are.
If you're at this decision point on a field device, battery-powered or mains, sensor node or HMI-equipped, this is exactly the kind of architecture call MicroCore's engineering consultancy work starts with, before any silicon gets chosen or any schematic gets drawn.
MicroCore Systems, Auckland, NZ. Contact: jonathan@microcoresystems.co.nz