8 MCU vs MPU: Measurements and Boundaries

8.1 Start With the Situation

This section: Start With the Situation — Both controller classes could run the prototype.

Both controller classes could run the prototype. A microcontroller board runs a bounded device-control program; a microprocessor board can run an operating system and more services. Boot is the startup process, and boot time measures how long it takes. The team must compare measured boot time, power, timing, interfaces, and support. A hybrid boundary splits tasks between the two classes when that fits the evidence.

8.2 Overview

This section: Overview — This route turns platform comparison into a recorded controller and boundary decision.

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

This section: 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 Arduino and Raspberry Pi in Numbers

This section: 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.

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.

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.5 Raspberry Pi Bring-Up Record

This section: Raspberry Pi Bring-Up Record — A Raspberry Pi prototype needs more than the board.

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.6 Evidence Before the Choice

This section: Evidence Before the Choice — The controller choice should be backed by evidence, not preference.

The controller choice should be backed by evidence, not preference. Before freezing the direction, record the minimum measurements that could disprove the decision.

Figure 8.1 sets out the measurements needed before choosing an MCU, MPU, or hybrid.

+

The cold-room example splits local alarm timing from storage and upload work. A threshold crossing must reach the buzzer within the stated 500 ms budget, even when the radio is busy. Energy evidence must include sleep, wake, transmit, and fault states rather than a single idle reading. Application evidence asks whether the gateway can store readings and upload them later. Measure the busiest expected mode before comparing controller options. If local timing fails or the application path cannot recover, the choice needs a different boundary or more testing.

Use these checks during the prototype review:

8.7 Incremental Examples

This section: Incremental Examples

8.8 Hybrid Boundaries

This section: Hybrid Boundaries — Hybrid designs combine an MCU and MPU when neither side should own every task.

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.

Figure 8.2 assigns time-sensitive work to the MCU and application work to the MPU.

+

Sensor sampling, watchdogs, local alarms, and actuator safety stay on the MCU side because they must continue when the application side pauses or restarts. Configuration, storage, and network services sit on the MPU side, where a richer software stack can manage them. The boundary between the two needs explicit messages, timeouts, and ownership of failure recovery. A local alarm should still work if a gateway process is late; a stored reading should still have an identified path to the service. Test those crossings before calling the hybrid split reliable.

Keep these responsibilities clear:

8.9 Review Record

This section: Review Record — A controller review should record why the chosen class answers the current stage-gate question.

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.

Figure 8.3 ties the controller decision to the prototype stage and its measured evidence.

+

The example in Figure 8.3 ties a hybrid choice to distinct test results. Timing evidence covers endpoint response under radio retry and local alarm; energy logs separate sleep, wake, transmit, and fault states. Gateway service restart and offline queue tests support the software side, while missing-endpoint and missing-gateway cases check the boundary between them. The decision assigns sensing, wake, and local recovery to the MCU, and storage, technician display, and reconnect flow to the MPU. The next gate still asks for enclosure, cable, and recovery tests. Keep the evidence and remaining uncertainty with the choice so a later builder can repeat or challenge it.

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 tests

8.10 Try It Now

This section: Try It Now — Choose one prototype idea and classify each requirement as control evidence, application evidence, or boundary evidence.

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.11 Pick the First Disproving Test

This section: 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.

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.12 Concept Check: Endpoint Controller Fit

This section: Concept Check: Endpoint Controller Fit

8.13 Concept Check: Hybrid Boundary Ownership

This section: Concept Check: Hybrid Boundary Ownership

8.14 Match Controller Evidence

This section: Match Controller Evidence

8.15 Order the Controller Selection Review

This section: Order the Controller Selection Review

8.16 Extend The Decision Beyond MCU Versus MPU

This section: Extend The Decision Beyond MCU Versus MPU — The MCU/MPU split remains the first useful boundary: deterministic control versus application-level computing.

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.17 Common Failure Patterns

This section: Common Failure Patterns — The budget view in Figure 8.4 separates persistence from peak runtime use before optimisation is credited as recovered capacity.

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.18 Summary

This section: Summary — MCU and MPU choices are architecture decisions, not board preferences.

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.19 Key Takeaway

This section: Key Takeaway — MCU versus MPU selection depends on timing, power, operating system needs, memory, connectivity, security, and update model, not on raw compute alone.

MCU versus MPU selection depends on timing, power, operating system needs, memory, connectivity, security, and update model, not on raw compute alone.

8.20 See Also

This section: See Also — First, PCB Design - carry controller evidence into board layout and bring-up planning.

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.