Running a model on a single MCU means the inference lives inside the controller the product already has. There is no separate accelerator, no application processor, no operating system to boot. The same chip samples the sensor, runs the network, and acts on the result inside the loop it already owns. For a narrow job that fits, this is the smallest and cheapest way to put intelligence on a device, and it changes the bill of materials more than any other choice in this corner of edge AI.

It holds when the model is small and the task is fixed. A few hundred kilobytes of flash for the weights, tens to low hundreds of megahertz of clock, and a known input shape are the budget a microcontroller brings. Inside that budget a keyword spotter, a vibration classifier, or a simple gesture model runs in a few milliseconds and a few milliamps. Step outside it, with a large vision network or a model meant to grow over time, and the part fights its own memory while a different class of silicon waits to do the job properly.

The appeal is what leaves the board.

When one chip can be the whole system

The case for a single MCU is strongest when the alternative is plainly oversized. A separate accelerator buys throughput a low-rate job never touches, and it brings a second supply line, extra board area, and a host-to-device data path that all have to be designed and kept working. Knowing when an MCU with a neural block replaces a separate accelerator comes down to being honest about two numbers: how large the model is once quantised, and how often it has to run. If the network fits in on-chip memory and the device infers a handful of times a second, the extra chip earns nothing it is paid for.

What disappears is concrete. One part stands in for three; one firmware image replaces a host plus its driver stack; a power figure in milliwatts replaces one in watts. The limit is concrete too, and it bites early. The model has to be shaped for the part from the first day, because once the flash and RAM are allocated there is no headroom to grow into, and a network that creeps over budget late in a project forces either a painful prune or a jump to a bigger part.

MCUs with a neural block built in

The middle of this range is the microcontroller that carries a small hardware neural unit alongside its core. The core runs the firmware as before; the neural block does the multiply-accumulate work of the model at a fraction of the energy and time the core would need for it. That division is what lets a microcontroller handle real vision or audio inference without turning into a full accelerator, and it is the part of the market moving fastest at the moment.

The parts differ in how hard they push the idea. STM32N6 as a high-end MCU with a built-in NPU sits near the top, with a neural unit capable enough to run models that would have demanded a separate accelerator only a generation ago, while keeping the STM32 toolchain, ecosystem, and supply that a team may already be standardised on behind it. That continuity is often what tips the decision toward it over a less-supported part with a larger headline number, because staying on a known toolchain saves weeks that a benchmark win never returns. Alif Ensemble E7, which pairs an NPU with the MCU, takes a more aggressive position, placing a dedicated neural processor and several cores on one device for a design that wants accelerator-class inference inside a microcontroller power budget. Both parts pose the same question in return: how much of the model the vendor's compiler can map onto the neural block, because every operator that falls back to the core runs an order of magnitude slower and quietly cancels the advantage that justified the part. The figure that settles a battery design, energy per inference, appears on neither front page; it comes out of profiling the real model on the real silicon, and it can differ by a wide margin from the marketing number depending on how cleanly the network maps. Measuring it on a development board before the part is locked is the step that separates a design which meets its battery life from one that misses and has nowhere left to cut.

For a product that has to last on a small cell and still classify in real time, this class is frequently the only one that closes both constraints at once, which is why it draws the attention it does.

Running it on clock speed alone

Not every microcontroller needs a neural block. STM32H743VIH6 running a vision model on a high-clock MCU takes a different route, leaning on a fast Cortex-M7 and a capable DSP rather than a dedicated neural unit. It pushes the model through in software at a clock well above a typical microcontroller, which suits a team already committed to STM32 that wants to add a light vision or signal task without opening a new part family or learning a new toolchain. The trade is energy: doing the math on the core costs more per inference than a neural block would, so this answer fits a line-powered or generously-batteried design better than a coin-cell one, and it runs short of room as the model grows.

The always-on, battery-bound case

At the lowest-power end the binding constraint is not throughput but idle current. A device that has to listen or watch without pause spends almost all of its energy in the gaps between inferences, so the number that governs battery life is what the part draws while it waits, not how fast it computes when it wakes. Apollo4 for ultra-low-power always-on inference in a wearable is engineered around that number, holding sleep and active currents low enough that a coin cell or a small lithium cell can keep a model running around the clock for the service life of the product.

This is a different problem from the rest of the page, and it rewards a different instinct. Peak inference rate barely registers; what counts is that the part can stay powered without flattening the cell, that the model is small enough to run inside the energy a wearable can spare each wake, and that the wake itself is cheap. A design that gets the duty cycle and the sleep current right will outlast one with twice the compute and a careless idle path.

Prototyping and the light end

Not every reason to put a model on a microcontroller is a production reason. Sometimes the point is to find out whether the idea holds up at all, before any of the harder commitments are made.

RP2040 for a first pass at TinyML is a common place to begin: inexpensive, thoroughly documented, and easy to get a small model running on, which makes it a low-stakes way to learn whether a network fits the rough shape of a microcontroller before committing to a part with a neural block. What it teaches about model size and structure carries forward; what it shows for speed and power does not, since a production part with different memory and a different core behaves on its own terms.

ATMEGA2560-16AU in light on-device sensing and control sits at the opposite edge, where the work is barely a model at all: thresholds, small state machines, and steady sensor handling on an 8-bit core that has done this kind of job dependably for years. It is a standing reminder that a sensing task is not automatically an inference task, and that the cheapest part which does the work is sometimes the right one.

Between those poles, many teams end up matching the part to the prototype they built rather than the one they sketched at the start, and the gap between those two is where a good deal of schedule goes.

The light end is easy to underrate. A problem that looks like it needs a network often resolves to a clean threshold and a little hysteresis, and seeing that early saves a part, a power budget, and a month spent tuning a model that was never required.

Shaping the model to the part

Whichever part wins, the model has to meet it halfway. A network trained in floating point gets quantised to eight-bit integers before it fits a microcontroller, which shrinks the weights by about four times and hands the work to the integer math the core or the neural block does well. Quantisation costs a little accuracy, and getting it back means training with the quantisation in the loop rather than bolting it on at the end.

The tools carry as much weight as the part here. A flow such as TensorFlow Lite for Microcontrollers, or a vendor's own converter, decides which layers survive the trip onto the device and which drop back to slow software on the core. A model built against the target from the start, using operators the toolchain supports and a footprint inside the part's RAM, reaches the device whole; one built in the abstract and ported late tends to arrive in pieces.

This is why the part and the model are chosen together rather than in sequence. Settling the silicon before the network is sized risks a part with too little memory; freezing the network before the part is picked risks a model no affordable microcontroller can hold. The teams that ship tend to move both at once on a development board until the pair fits.

What decides it

The model size and the duty cycle set the floor here, the same as anywhere in edge AI. On a single-MCU design they press harder, because there is nowhere to absorb an underestimate once the flash and RAM are committed.

Above the floor, the toolchain carries more weight than the headline rating. A neural block returns only what its compiler can place on it, and a part with thin tools can leave the bulk of a model running on the core at a speed that defeats the reason it was chosen. The maturity of the conversion flow and the community around it earn their keep on a real schedule.

Supply settles the rest. A microcontroller picked for a product that ships for years has to be one that can still be bought in volume across that span, with a second source named before the first build rather than hunted down after a shortage stops the line.

The part that ships is rarely the one that won the benchmark. It is the one whose memory, energy, and supply matched the product, chosen with a clear view of how the model would grow.