Reference Architectures · Study deck

MCU vs MPU Selection for IoT

Imagine a remote pump monitor must sample all day but only send a rich report after a fault.

Blueprint Bina is your guide for this deck.

hardwarechar

Blueprint Bina, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

distinguish controller-class and processor-class hardware by proof, not brand or board familiarity;
decide when a full operating system is a requirement rather than a convenience;
connect memory, boot, sleep, interface, and update behavior to hardware class;
identify hybrid designs where a controller wakes or supervises a processor;

Major section

A Clear First Route

The team must choose a small control chip, a larger processor, or both.

A microcontroller is a small computer chip built to run a focused control job.
This page starts with one job.
A faster part can waste power and add upkeep.
A smaller part can fail when the job grows past its bounds.

Major section

A Clear First Route (continued)

This first route is a guide to the main choice.

The Practitioner sections add class fit, operating system needs, hybrid roles, and the proof record.
Under the Hood adds why the boundary shifts with memory, timing, drivers, threats, and field change.
They do not reverse its main claim.
A person may inspect the site.

Major section

A Clear First Route (continued)

If two sources differ, keep that fact in the record.

A late result may be true about the past and still be unsafe now.
A missing result is also useful news when the system shows it at once.
A local rule may hold a safe state.
A remote team may ask for more proof.

Major section

Start With the Device Job

The MCU-versus-MPU decision starts with the job the device must do every day.

A tiny controller may need predictable sensing, low power, and simple control.
A processor-based device may need rich networking, storage, graphics, Linux services, or local analytics.
The architecture should show why the chosen compute class fits timing, power, memory, update, security, interface, and support evidence for the deployment.

Major section

Overview

The MCU versus MPU decision is one of the first hardware boundaries in an IoT architecture.

A microprocessor unit usually provides stronger general compute but relies on external memory, storage, power management, and a richer operating-system environment.
It avoids platform-specific shopping lists and instead asks what the device must prove: workload shape, memory pressure, wake behavior, interface needs, update path, service records, and lifecycle margin.
Many controller-class IoT devices use reduced-instruction-set families such as ARM Cortex-M, MIPS, or RISC-V because the smaller control logic can fit low-cost, low-power embedded designs.

Major section

Selection Route

If the role is bounded sensing, local control, state retention, and compact reporting, controller-class hardware is usually the first candidate.

If the role includes a rich application runtime, large media buffers, local files, a web service, containerized software, or complex user-facing applications, processor-class hardware is usually justified.

MCU versus MPU selection route from device role through operating-system need, workload shape, memory and storage pressure, energy states, interface proof, lifecycle support, and final selection record.

Major section

Class Fit

The choice is clearest when the proof is arranged by hardware class.

The program usually runs as firmware with a small scheduler or a simple event loop.
The platform usually runs a full operating system.

Hardware class fit map comparing controller-class, processor-class, and hybrid choices against workload, operating-system need, memory pressure, energy states, and lifecycle proof.

Major section

Operating-System Boundary

The operating-system question is a boundary question, not a preference question.

A full operating system can simplify networking, files, drivers, application frameworks, and development workflow.
It also adds boot time, storage health, update complexity, background services, security maintenance, and larger energy states.
while the worst-case live RAM is approximately.
Standards names are not interchangeable badges.

The operating-system boundary: controller firmware with no OS, a processor operating-system runtime, and hybrid supervision between them.

Major section

Operating-System Boundary (continued)

The sums expose why “the kernel is only 8 KiB” is not a sizing argument.

Camera, audio, display, browser, and rich user-interface pipelines add another strong processor signal, as do application frameworks or libraries that cannot fit in embedded firmware.
In that design, deterministic local control owns its interfaces directly, state and logs remain compact, and updates use fixed images.
IEC 62304 governs medical-device software lifecycle processes.

Major section

Operating-System Boundary (continued)

Event-driven behaviour benefits from fast wake and a small retention burden, while the controller retains a safe output state even when the network is absent.

A useful historical rule of thumb is that a single-loop application using less than roughly 16 KiB of RAM and flash may not need an operating system.
A 14 KiB program can still need concurrency, isolation, or a certified scheduler; a 40 KiB program can still be safer and simpler as a bare-metal state machine.
A TCP/TLS session, radio driver, filesystem cache, update manifest, and four task stacks may dominate the kernel.

Major section

Operating-System Boundary (continued)

If two firmware slots are required for rollback, count both in nonvolatile storage even though only one executes.

If every responsibility can be expressed as bounded state transitions—sample, decide, report, sleep—with known interrupt latency and no blocking operation, bare metal may be the clearer boundary.
If independent deadlines, protocol timers, privilege separation, dynamic services, or several blocking drivers must coexist, a scheduler or OS can reduce application complexity.
IEC 61508 defines functional-safety lifecycle obligations and Safety Integrity Levels; a project must derive its required SIL and evidence rather than claim “SIL 3/4 support” from an OS feature list.

Major section

Hardware Class Proof Checklist

Include boot, active work, idle wait, sleep or retention, fault recovery, service mode, and update mode.

Examples include new media processing, larger local models, stricter wake behavior, or field-service limits.

MCU versus MPU proof checklist with workload, memory, energy, interfaces, lifecycle, and review-condition proof feeding the selection decision.

Major section

Hybrid Boundary

Some systems need both.

A controller can remain responsible for wake, safety, sensing, and low-state behavior while a processor is powered for heavier work.
This boundary is useful only when the responsibilities are explicit.

Hybrid controller and processor boundary showing always-ready sensing, wake decision, heavy burst processing, safe output ownership, and shared decision proof.

Major section

Walkthrough: Remote Pump Monitor

A facilities team needs a remote pump monitor.

The device reads vibration and temperature, detects abnormal conditions, stores a short event history, drives a local alarm output, and reports status to a gateway.
The device may lose network connectivity and must keep local alarm behavior working.
The initial selection is controller-class hardware.

Major section

Walkthrough: Remote Pump Monitor (continued)

A hybrid design may fit if the controller must always watch the pump while a processor occasionally performs deeper diagnostics after a confirmed abnormal event.

Sampling is bounded, the decision rules are small, wake and safe output behavior matter, and local state is compact.
The controller can own sensor reading, alarm output, event record, and retry behavior.
The decision should still reserve memory and interface margin for update, calibration, sensor replacement, service logs, and future diagnostic changes.

Major section

Selection Record

The record should explain the decision in a way that another engineer can challenge.

The proposition under review is: MCU versus MPU selection record linking device role, chosen class, proof groups, rejected class, validation tests, and review conditions.

MCU versus MPU selection record linking device role, chosen class, proof groups, rejected class, validation tests, and review conditions.

Deck summary

Key takeaways

The team must choose a small control chip, a larger processor, or both.

This first route is a guide to the main choice.
If two sources differ, keep that fact in the record.
The MCU-versus-MPU decision starts with the job the device must do every day.
The MCU versus MPU decision is one of the first hardware boundaries in an IoT architecture.

Retrieval practice

Recall check 1 of 3

Blueprint Bina says: answer from memory, then check your reasoning.

Q1A remote pump monitor reads vibration and temperature, stores a short event history, drives a local alarm output, and reports compact status to a gateway that may be unavailable. Which first check keeps the hardware-class decision traceable?

AReview processor-class hardware first to reuse familiar networking packages and remote administration tools for the pump monitor.

BApprove controller-class hardware from one bench sample, one alarm toggle, and one gateway message.

CRecord workload, memory, wake states, alarm authority, outage behavior, update recovery, service access, and review conditions.

DAdd both classes before assigning alarm, log, update, wake, recovery, and service ownership.

Show answer

Answer: C A traceable MCU-versus-MPU decision proves the real workload, memory, energy state, interface, update, service, and lifecycle needs before choosing controller-class, processor-class, or hybrid hardware.

Retrieval practice

Recall check 2 of 3

Blueprint Bina says: answer from memory, then check your reasoning.

Q2A remote pump monitor reads two sensors, stores a short event record, drives a local alarm output, and reports compact status messages to a gateway. It must keep local alarm behavior working when the network is unavailable. Which hardware class should be reviewed first?

AReview processor-class first to reuse a full OS network stack and its remote diagnostics tools.

BReview controller-class first because bounded sensing, compact state, and local alarm authority fit firmware.

CReview processor-class first to use Linux package tools for future deployment updates and field maintenance.

DReview hybrid hardware first because using both classes avoids a selection decision.

Show answer

Answer: B The hardware class follows the device role.

Retrieval practice

Recall check 3 of 3

Blueprint Bina says: answer from memory, then check your reasoning.

Q3A remote pump monitor originally fits controller-class hardware, but a new requirement adds local waveform storage, a browser dashboard, and downloadable diagnostic files. What should happen to the selection record?

AKeep the controller choice because compact status reporting already worked once.

BSwitch to processor-class automatically without checking boot, alarm, power, or recovery.

CAdd a processor beside the controller without assigning alarm, log, update, or recovery ownership.

DRecheck class fit because files, dashboard services, waveform storage, and support may need processor or hybrid hardware.

Show answer

Answer: D The device role changed from bounded monitoring toward richer local services and storage-heavy diagnostics.

Print reference

Answers

Answer key.

C · A traceable MCU-versus-MPU decision proves the real workload, memory, energy state, interface, update, service, and lifecycle needs before choosing controller-class, processor-class, or hybrid hardware.
B · The hardware class follows the device role.
D · The device role changed from bounded monitoring toward richer local services and storage-heavy diagnostics.