8 MCU vs MPU: Measurements and Boundaries
8.1 Start With the Situation
Both controller classes could run the prototype, so labels are no longer enough. The team must compare measured boot, power, timing, interface, and support evidence, then define where a hybrid boundary helps.
8.2 Overview
This route turns platform comparison into a recorded controller and boundary decision.
This is part 2 of 2. Review MCU vs MPU: Workload Fit when you need the first route.
8.3 Learning Objectives
By the end of this chapter, you will be able to:
- compare MCU and MPU measurements
- record controller bring-up evidence
- choose hybrid boundaries and disproving tests
8.4 Chapter Roadmap
Follow the original sections below in order. They begin at the reviewed split boundary and keep every worked example, figure, check, and supporting banner with the section that owns it.
8.5 Arduino and Raspberry Pi in Numbers
Arduino and Raspberry Pi are the two boards most prototype teams already recognize, which makes them a useful anchor for the MCU Fit and MPU Fit checklists above. Naming their actual numbers turns “microcontroller” and “microprocessor” from category labels into a measurable gap a team can plan a battery, a bill of materials, or a review record around.
| Property | Arduino-class MCU board | Raspberry Pi-class MPU board |
|---|---|---|
| Compute core | 8-bit AVR (for example, the ATmega328 on an Uno or the larger ATmega2560 on a Mega) | 64-bit Arm (for example, a quad-core Cortex-A72 in a Broadcom BCM2711 SoC) |
| RAM | 2 KB to 8 KB of on-chip SRAM | 1 GB to 4 GB of external DRAM, chosen at purchase |
| Non-volatile storage | 32 KB to 256 KB of on-chip flash for the sketch | A removable microSD card or onboard eMMC, gigabytes deep, holding a full OS image |
| Operating model | No operating system; firmware runs one loop after reset | A full OS (commonly a Linux distribution) scheduling many processes and services |
| Power-loss behavior | Resets and resumes the same loop automatically | Can leave the filesystem in an inconsistent state without an orderly shutdown |
| Expansion path | Shields stack directly on the header, largely plug-and-play | HATs and USB or camera-interface peripherals, closer to adding hardware to a small computer |
| Direct I/O | Roughly 20 digital pins wired straight to the core | A 40-pin GPIO header shared with OS-managed drivers and services |
| Prototype-quantity cost | A bare AVR chip runs a few dollars; an Uno-class dev board is usually well under $30 | A Pi-class board is usually in the $35 to $75 range, more with a compute-module carrier |
The same evidence sentence from earlier in this chapter decides between them in practice. A soil-moisture prototype that reads a probe and emails an alert once the reading crosses a threshold is proving a bounded, repeatable control loop, so an Arduino-class board can usually answer that question alone. The same prototype extended to check an online weather forecast before deciding whether to send the alert — so it can hold off an unnecessary email ahead of expected rain — is proving an application question: parsing a remote response, holding network and forecast state, and making a decision that depends on data the board does not own. That extended version is the more honest fit for a Raspberry Pi-class board. Neither board is the better one in general; the second prototype is simply answering a question the first prototype never had to ask.
8.6 Raspberry Pi Bring-Up Record
A Raspberry Pi prototype needs more than the board. The source-deck bring-up route begins with the display and input path, power supply, network cable where required, and removable storage. It then chooses an operating-system image, writes that image to the SD card, boots the system, and records the initial configuration before application work begins.
Keep the following evidence together:
First, Hardware path: HDMI or other display connection, monitor, keyboard and mouse where the first setup needs them, the 5 V supply, network connection, and SD card.
Next, Operating-system path: the selected supported or third-party image, the image file written to the card, the writer tool and target device, and the result of the first boot. The source deck illustrates this with Raspbian and Win32 Disk Imager.
Then, Remote-access path: whether SSH is required and, when following the deck’s route, the raspi-config Advanced Options step used to enable it.
After that, Storage path: whether the installed image uses the full card and, when following the deck’s route, the raspi-config filesystem-expansion step and its observed result.
Finally, Runtime role: which installed language or application answers the prototype question. The deck names Python, C, C++, Java, Scratch, and Ruby, and illustrates roles including media streaming, home automation, robot control, VPN service, and a lightweight IoT web server.
GPIO remains a hardware boundary after the operating system boots: a pin can be configured as a digital input or output, but the prototype record must still identify the pin, direction, expected high/low state, connected circuit, and test result. The bring-up record therefore joins the operating-system evidence to the direct-I/O evidence instead of treating a successful boot as proof that the hardware path works.
8.7 Evidence Before the Choice
The controller choice should be backed by evidence, not preference. Before freezing the direction, record the minimum measurements that could disprove the decision.
Inspect Evidence Needed Before Choosing and Timing budget in Figure 8.1 for evidence before the choice. Before carrying evidence before the choice forward, set Evidence Needed Before Choosing against Timing budget with it. The remaining question is under the busiest mode.
Read Evidence Needed Before Choosing with Timing budget in Figure 8.1 for evidence before the choice. Set its cases by setting Evidence Needed Before Choosing against Timing budget under under the busiest mode. under the busiest mode decides the category. The running argument in evidence before the choice therefore stays bounded.
Use these checks during the prototype review:
If a requirement can only be proven by deterministic hardware behavior, start with an MCU. If it can only be proven by operating-system behavior, start with an MPU. If both are true, draw the boundary explicitly before adding hardware.
8.8 Incremental Examples
8.8.1 Battery Door Sensor Endpoint
A door sensor reports open/closed state from a reed switch and sends a status message every few minutes. The prototype should start with an MCU such as an nRF52, ESP32-C3, RP2040 with a radio companion, or STM32 low-power board.
- The main evidence is wake time, GPIO interrupt behavior, sleep current, radio transmit current, and reset recovery.
- The firmware can be a small state machine: wake, read pin, debounce, send compact message, confirm local safe state, sleep.
- The acceptance test should measure current in sleep, wake, transmit, and fault states, then compare the result with the battery-life target.
This is a beginner case because the local control job is bounded. A Linux-capable MPU would add boot time, filesystem, package, and service-supervision risks that do not answer the main question.
8.8.2 Local Technician Kiosk
A maintenance bench needs a local display, USB barcode scanner, SQLite cache, browser-based setup screen, and Ethernet upload when the site network returns. A Raspberry Pi Compute Module, BeagleBone, or similar MPU-class board is the more useful starting point.
- The main evidence is boot time, display startup, USB scanner support, filesystem behavior after power loss, local database writes, and service restart behavior.
- The software stack can use Linux, systemd services, a web UI, local storage, and log collection.
- The acceptance test should pull power during a write, restart the application service, inspect logs, and confirm the queued records survive.
This case is harder because the controller is not only reading pins. The prototype is testing application behavior near equipment, so operating-system evidence matters.
8.8.3 Machine Room Monitoring
A team is building a machine room monitoring prototype. Several endpoints measure vibration, temperature, door state, and power interruption events. A local gateway stores recent readings, shows status on a maintenance screen, and forwards summarized records when the network is available.
The mathematical gist. A 200 Hz vibration signal needs at least 400 samples each second. A 12-bit ADC on 3.3 V divides the input into 4,096 steps of 0.806 mV and gives an ideal 74.0 dB signal-to-quantisation-noise ratio. At a catalog-typical 5 mA for 10 microseconds, one conversion costs 165 nJ, so continuous minimum-rate sampling costs 5.70 J/day while 288 door-sensor samples cost 47.5 microjoules/day.
8.8.4 Endpoint Controller
The endpoint should use an MCU because the important questions are local and time bounded.
8.8.5 Gateway Controller
The gateway should use an MPU because the important questions are application-level.
The mixed design is not indecision. It keeps timing-sensitive sensing in firmware while moving storage, interface, and operations work to the application side.
8.9 Hybrid Boundaries
Hybrid designs combine an MCU and MPU when neither side should own every task. The important design work is the boundary: what stays deterministic, what becomes an application service, and what happens when either side fails.
Inspect Hybrid Designs Need an Explicit Boundary and timeouts in Figure 8.2 for hybrid boundaries. For the evidence behind hybrid boundaries, trace Hybrid Designs Need an Explicit Boundary toward timeouts in it. The conclusion depends on Review reset: other side enters known state.
Read Hybrid Designs Need an Explicit Boundary with timeouts in Figure 8.2 for hybrid boundaries. Read its ownership map from the Hybrid Designs Need an Explicit Boundary responsibility across timeouts to Review reset: other side enters known state. A fault should remain attached to Hybrid Designs Need an Explicit Boundary or timeouts. Return to hybrid boundaries with timeouts explicitly tested.
Keep these responsibilities clear:
Unplug, reset, or pause one side of the hybrid prototype during review. The other side should enter a known state and leave enough evidence to explain what happened.
8.10 Review Record
A controller review should record why the chosen class answers the current stage-gate question. The record should be clear enough that a later builder can repeat the decision.
Inspect Controller Review Record and Decision in Figure 8.3 for review record. Before carrying review record forward, put Controller Review Record and Decision into the same reading of it. Record remaining uncertainty supplies the consequence.
Read Controller Review Record with Decision in Figure 8.3 for review record. Work through it by keeping Controller Review Record, Decision, and Record remaining uncertainty as separate entries. Both Controller Review Record and Decision need evidence. For review record, attach the next action to Record remaining uncertainty.
prototype=machine-room-monitor
stage=functional-prototype
decision=hybrid
mcu_role=endpoint sensing, wake behavior, local fault recovery
mpu_role=gateway storage, technician screen, reconnect workflow
timing_evidence=endpoint response measured under radio retry and local alarm
energy_evidence=sleep, wake, transmit, and fault states logged separately
software_evidence=gateway service restart and offline queue tested
boundary_evidence=missing-endpoint and missing-gateway behavior recorded
next_gate=engineering prototype with enclosure, cable, and recovery tests8.11 Try It Now
Choose one prototype idea and classify each requirement as control evidence, application evidence, or boundary evidence. Then write one sentence choosing MCU, MPU, or hybrid and name the first measurement that could prove the choice wrong.
8.12 Pick the First Disproving Test
A cold-room monitor uses an ESP32 endpoint, an SHT31 probe, a buzzer, MQTT telemetry, and a wall-mounted Raspberry Pi gateway with a small display. The alarm must sound within 500 ms when the probe crosses a threshold, while the gateway stores readings and uploads them when Wi-Fi returns.
Name the first test you would run for the endpoint and the first test you would run for the gateway. A strong answer separates timing evidence such as interrupt latency, sampling interval, buzzer drive, and watchdog recovery from application evidence such as boot time, service restart, SQLite or file writes, and reconnect behavior.
8.13 Concept Check: Endpoint Controller Fit
8.14 Concept Check: Hybrid Boundary Ownership
8.15 Match Controller Evidence
8.16 Order the Controller Selection Review
8.17 Extend The Decision Beyond MCU Versus MPU
The MCU/MPU split remains the first useful boundary: deterministic control versus application-level computing. It is not the final shortlist. An FPGA can expose deterministic parallel datapaths; a GPU can accelerate data-parallel kernels but needs a host and a supported software stack; an ASIC can reduce per-unit energy and cost at very high volume while creating large non-recurring engineering and change risk; and a SoC may combine several of these roles behind one memory, I/O, and lifecycle contract.
The selector below is a question generator. It does not name a purchasable part, and it deliberately scores lifecycle and toolchain readiness alongside raw compute. Any shortlisted family still has to pass the existing chapter’s timing, energy, memory, peripheral, update, security, and recovery evidence gates.
8.18 Common Failure Patterns
The prototype uses an application processor for direct control because it feels more capable. Later, boot delay, service restarts, storage corruption, or scheduling jitter interfere with hardware behavior that should have been deterministic.
The firmware grows into a local application platform with files, dashboards, protocol translation, and complex update logic. The memory map and debugging workflow become the real blocker.
The MCU and MPU share responsibilities informally. When a reset, timeout, or network outage occurs, neither side has a clear source of truth. Define the message contract before field testing.
The team picks a controller from habit and never measures timing, energy states, memory headroom, or recovery behavior. The issue appears later when the prototype is harder to change.
The budget view in Figure 8.4 separates persistence from peak runtime use before optimisation is credited as recovered capacity.
In Figure 8.4, FLASH · 32 KiB and EEPROM · 1 KiB retain different kinds of state, while SRAM · 2 KiB must survive peak Stack + heap + globals use. The FLASH RELEASE BUDGET shows 4 KiB free, but the SRAM PEAK BUDGET can still overflow independently; -Os and compressed instructions recover measured headroom, not interchangeable memory.
8.19 Summary
MCU and MPU choices are architecture decisions, not board preferences. Use an MCU when the prototype must prove deterministic embedded control. Use an MPU when it must prove application-level computing near the device. Use a hybrid boundary when both kinds of evidence are essential, and make the boundary measurable.
8.20 Key Takeaway
MCU versus MPU selection depends on timing, power, operating system needs, memory, connectivity, security, and update model, not on raw compute alone.
8.21 See Also
First, PCB Design - carry controller evidence into board layout and bring-up planning. Next, Hardware Platforms - compare platform roles without confusing boards with architecture. Then, Hardware Components - select sensors, actuators, modules, and power parts from prototype evidence. After that, Hardware Introduction - review the stage-gate process that frames hardware decisions.