Prototyping · Study deck
MCU vs MPU: Workload Fit
This first route defines the decision and explains when an MCU or MPU fits the workload.
Voltage Vera is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Distinguish MCU and MPU architectures by integration, timing behavior, memory model, and software stack.
- Choose a controller class from evidence needs instead of platform popularity.
- Identify when a prototype should use an MCU, an MPU, or a hybrid boundary.
- Record the measurements needed to defend a controller decision.
Major section
In 60 Seconds
Bluetooth Low Energy (BLE) is a short-range radio method designed for low power.
- A small controller may suit fixed timing, sleep, simple inputs, and direct outputs.
- A larger computer may suit a screen, files, camera work, many services, or rich local tools.
- Some products need both, with a clear safety boundary.
Major section
Choose Computing Job First
MCU versus MPU is an architecture choice, not a popularity contest between development boards.
- The question is whether the prototype must prove deterministic control at the hardware boundary, operating-system behavior near the device, or a clean split between the two.
- The comparison reaches local recovery.
Major section
Choose Computing Job First (continued)
An MCU is usually the right starting point for battery endpoints, bounded control loops, low-latency inputs, PWM outputs, ADC sampling, watchdog recovery, and sleep-heavy operation.
- An MPU is usually the right starting point for local databases, displays, cameras, USB host workflows, Linux services, containers, and remote shell diagnostics.
- Neither: Controller Choice Starts With Evidence nor: What must this build prove? Wins without local recovery.
- A maintenance kiosk with a touch display, SQLite cache, USB scanner, Ethernet upload, and local log viewer mainly needs to prove application and service behavior, so an MPU-class board is more honest.
Major section
Compare Evidence, Not Boards
A controller comparison needs measurements that could expose a poor fit rather than a ranking of board names.
- MCU tests check sleep current, interrupt timing, recovery, and memory headroom under the intended firmware.
- MPU tests check boot behavior, storage resilience, service restart, and application load.
- EEPROM has a separate persistence job.
Major section
Compare Evidence, Not Boards (continued)
A Cortex-M, STM32, nRF52, ESP32, RP2040, or AVR board can look sufficient until the RAM, flash, radio, or sleep-current budget is measured.
- A Raspberry Pi, Compute Module, BeagleBone, or other Linux-capable MPU can look powerful until boot time, filesystem resilience, and power draw are tested.
- A power profiler or shunt plus oscilloscope can show whether an MCU really reaches the expected sleep current after sensor reads and radio retries.
- A logic analyzer can prove whether an interrupt, SPI transaction, PWM output, or watchdog window stays inside the timing budget.
Major section
Compare Evidence, Not Boards (continued)
On an MPU, collect boot logs, systemd restart behavior, filesystem-write tests, CPU and memory pressure, thermal state, and network reconnect traces.
- The winning board is the one whose measurements leave the fewest unexplained risks for the next gate.
- The 2 KiB SRAM limit is often more dangerous: a 512-byte radio buffer uses one quarter of the entire working memory before stacks or sensor libraries are counted.
- Code-size tactics have trade-offs. -Os asks the compiler to optimize for size, but the actual image and timing must be inspected because inlining, library selection, and arithmetic helpers can dominate.
Major section
Software Model Shifts Failure
The design pressure is timing, memory, peripheral ownership, and power-state control.
- An MPU normally runs Linux, Android, Yocto, Buildroot, Debian, Ubuntu Core, or a vendor BSP.
- The design pressure is boot chain, drivers, filesystem, service supervision, package updates, and process isolation.
- Within the MCU side, do not treat "Cortex-M" as one part.
Major section
Software Model Shifts Failure (continued)
Hybrid designs work when the real-time side can keep a safe local state even while the application side reboots or updates.
- The hardware boundary explains why the same C or Python feature can carry different risk on each class.
- Unit cost is the second ledger.
- Those historical prices are not offers.
Major section
Software Model Shifts Failure (continued)
Common blocks such as SysTick, interrupt handling, optional memory protection, bit-banding where supported, and the code/SRAM/peripheral address map make compiler, boot, and debug evidence portable.
- MCUs usually have tightly bounded RAM and flash, memory-mapped peripherals, DMA channels, interrupt priorities, and explicit low-power states.
- That distinction is why MCU and SoC review records should name the silicon family, not only the development board.
- That stack-overflow line item is rarely one dramatic crash.
Major section
Software Model Shifts Failure (continued)
The family gives a common 32-bit instruction-set and interrupt model, but M0/M0+, M3, M4/M4F, M7, M23, and M33 parts expose different arithmetic, protection, memory, and power tradeoffs.
- The vendor peripherals around that core are not portable: ADCs, timers, SPI/I2C/UART blocks, DMA engines, radio controllers, and low-power modes must still be tested on the exact chip.
- A Cortex-M4 SAM4L-style part may be chosen for low active energy, DMA, AES, USB, and mixed-signal interfaces.
- Exact variants and data-sheet revisions differ; the purpose is to show how a feature list becomes an energy-and-cost decision.
Major section
Software Model Shifts Failure (continued)
Integration can reduce pins, board area, and host-radio coordination energy, yet it can also bind the product to one radio generation and memory ceiling.
- A cheaper MCU plus radio can cost more as a product than an integrated SoC; a more expensive MCU can win if its DMA and faster completion materially shrink battery, test, or engineering cost.
- The board support package, bootloader, watchdog path, storage medium, and update partition scheme become part of the prototype evidence.
- Hybrid failure mode: stale command, lost acknowledgement, split configuration truth, MPU reboot while MCU is driving an actuator, or MCU watchdog reset without application-side diagnosis.
Major section
Decision Behind MCU and MPU · Avoid Platform-First Selection
A microcontroller unit (MCU) is a compact embedded controller.
- An MPU supports a richer application environment with operating-system services and external memory or storage.
- The prototype decision follows the behavior that needs proof rather than the physical size of the board.
- A microprocessor unit (MPU) is an application processor.
Major section
MCU Fit
An MCU fits a device whose main job is a bounded local control loop.
- Timers and interrupts support repeatable sensor reads and output changes close to the hardware.
- An MCU fits when the prototype behaves like an embedded controller: it observes local signals, runs a bounded decision loop, and drives local outputs with repeatable timing.
Major section
MCU Fit (continued)
For mcu fit, attach the next action to: Flash Memory.
- Predictable timing: Interrupts, timers, and output changes must happen in a bounded control loop.
- Energy state control: The device must spend most of its life asleep, wake for a short task, then return to a low-energy state.
- MCUs are not only for simple projects.
Major section
MCU Fit (continued)
Direct peripherals: The prototype needs analog inputs, pulse outputs, serial buses, timers, counters, or simple radio control close to the hardware.
- Small fixed behavior: The firmware is a known set of device functions rather than a local application environment.
- Fast reset recovery: The device must return to a known state quickly after power interruption, watchdog reset, or local fault.
- Repeatable hardware handoff: The build can be documented as pins, firmware version, timing limits, diagnostics, and test steps.
Major section
MPU Fit
An MPU fits a device whose main work depends on an operating system and application services.
- Local files, databases, displays, and camera processing create different evidence needs from a fixed sensor-control loop.
- Boot behavior, storage recovery, and power draw still need tests before those capabilities justify the controller choice.
- An MPU fits when the prototype behaves like a small computer attached to hardware.
- Software reuse: The prototype needs libraries, drivers, or application frameworks that assume a full operating system.
Major section
MPU Fit (continued)
Large local data: The device must buffer datasets, index records, serve files, or run a local database during disconnected operation.
- Rich interfaces: The prototype needs a display, camera, audio path, USB host workflow, keyboard, browser, or multi-window interface.
- Edge applications: Local analytics, computer vision, protocol translation, or gateway orchestration would be awkward in fixed firmware.
- Remote operations: The team needs shell access, service logs, remote updates, and field diagnostics that look like server operations.
Deck summary
Key takeaways
Bluetooth Low Energy (BLE) is a short-range radio method designed for low power.
- MCU versus MPU is an architecture choice, not a popularity contest between development boards.
- An MCU is usually the right starting point for battery endpoints, bounded control loops, low-latency inputs, PWM outputs, ADC sampling, watchdog recovery, and sleep-heavy operation.
- A controller comparison needs measurements that could expose a poor fit rather than a ranking of board names.
- A Cortex-M, STM32, nRF52, ESP32, RP2040, or AVR board can look sufficient until the RAM, flash, radio, or sleep-current budget is measured.
Retrieval practice
Recall check 1 of 2
Voltage Vera says: answer from memory, then check your reasoning.
Q1A battery endpoint needs bounded control, PWM, and long sleep periods. Which starting architecture fits the chapter?
Show answer
Answer: A The chapter places deterministic inputs, outputs, and sleep-heavy operation on the MCU side.
Retrieval practice
Recall check 2 of 2
Voltage Vera says: answer from memory, then check your reasoning.
Q2A powerful Linux board is proposed for a field gateway. Which test could reveal a poor fit?
Show answer
Answer: D The chapter tests filesystem resilience, boot behavior, and power draw on MPU systems.
Print reference
Answers
Answer key.
- A · The chapter places deterministic inputs, outputs, and sleep-heavy operation on the MCU side.
- D · The chapter tests filesystem resilience, boot behavior, and power draw on MPU systems.