32  MCU vs MPU Selection for IoT

In 60 Seconds

MCUs (ESP32 at $4) integrate CPU, memory, and I/O on one chip for battery-powered sensors lasting years; MPUs (Raspberry Pi at $55) need external components but run full Linux for AI and video. The first hardware decision: “Do I need an operating system?” If yes, MPU. If no and battery-powered, ultra-low-power MCU.

Minimum Viable Understanding

• MCUs (e.g., ESP32 at $4) integrate CPU, memory, and I/O on one chip – perfect for battery-powered sensors lasting years; MPUs (e.g., Raspberry Pi at $55) need external components but run full Linux for complex tasks like AI and video.
• The first decision in IoT hardware design is: “Do I need an operating system?” If yes, use an MPU. If no and battery-powered, use an ultra-low-power MCU.
• Cost at scale matters: choosing MCUs over MPUs for 1,000 simple sensors saves $51,000 in hardware alone, plus $12,000/year in battery replacement costs.

Sensor Squad: The Two Types of Brains

Max the Microcontroller was showing off to the team. “Look at me! I have everything I need built right into my tiny body – processor, memory, and connections to all of you. And I barely use any of Bella the Battery’s energy!”

Percy the Processor walked in carrying a big bag of extra parts. “Sure, Max, but I need these extra memory sticks and storage cards to work. However, I can run a WHOLE computer operating system! I can browse the web, play videos, and even do fancy AI stuff!”

Sammy the Sensor laughed. “You two are like a Swiss Army knife versus a full toolbox. Max is the Swiss Army knife – small, efficient, does everything you need for simple jobs. Percy is the toolbox – heavier and needs more space, but handles the really complex work.”

Bella the Battery whispered to Lila the LED: “Between you and me, I prefer working with Max. He lets me rest most of the time, so I can last for YEARS. Percy drains me in just a few hours!”

The lesson: MCUs are like Swiss Army knives (compact, efficient, self-contained) and MPUs are like full toolboxes (powerful but bulky and energy-hungry). Pick the one that matches your actual needs!

32.1 Learning Objectives

By the end of this chapter, you will be able to:

• Contrast MCUs and MPUs: Distinguish microcontrollers from microprocessors and justify processor selection for specific IoT applications based on integration, cost, and power
• Interpret Hardware Specifications: Analyze processor datasheets including clock speed, memory capacity, power modes, and I/O capabilities
• Select IoT Platforms: Choose between Arduino, ESP32, Raspberry Pi, and other platforms based on cost at scale, power budget, and processing requirements
• Apply Decision Frameworks: Use systematic criteria to match processor capabilities to application requirements, starting with the “Do I need an OS?” question

32.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• Basic Electronics: Understanding of voltage, current, resistance, and digital logic (HIGH/LOW states) is helpful for comprehending GPIO operations and power calculations
• Networking Basics for IoT: Familiarity with communication protocols helps understand connectivity options and how devices communicate in IoT systems
• Edge, Fog, and Cloud Overview: Understanding where edge devices fit in the IoT architecture provides context for MCU vs MPU selection based on processing requirements

32.3 Getting Started (For Beginners)

New to IoT Hardware? Start Here!

This section is designed for beginners. If you’re already familiar with microcontrollers, microprocessors, and embedded systems, feel free to skip to the technical sections below.

32.3.1 What’s Inside an IoT Device? (Simple Explanation)

Analogy: Think of IoT hardware like different types of workers:

Worker Type	IoT Equivalent	What They Do
Specialist (does one job well)	Microcontroller (MCU)	Simple tasks: read sensor, send data
Manager (handles complex work)	Microprocessor (MPU)	Complex tasks: run apps, process video

32.3.2 The Two Main Types of “Brains”

Microcontroller (MCU) — The “Swiss Army Knife”

Figure 32.1: Microcontroller (MCU) Architecture: Integrated All-in-One Chip Design

Alternative View:

Figure 32.2: Timeline showing MCU evolution from 8-bit Arduino-era chips to modern AI-enabled IoT SoCs. Each generation added capabilities (32-bit, Wi-Fi, AI) while reducing power consumption. ESP32 family now dominates hobbyist and commercial IoT due to integrated Wi-Fi, low cost ($4), and excellent deep sleep (10µA).

Microprocessor (MPU) — The “Desktop Computer”

Figure 32.3: Microprocessor (MPU) Architecture: Modular Design with External Components

MCU vs MPU Architecture: Microcontrollers integrate all components on one chip for simplicity and low power. Microprocessors use separate chips for more power and flexibility.

32.3.3 When to Use Which?

Scenario	Best Choice	Why
Temperature sensor reporting hourly	MCU (ESP32)	Simple task, needs 10-year battery life
Security camera with AI	MPU (Raspberry Pi)	Complex processing, runs Linux
Smart light switch	MCU (Arduino)	Simple on/off, ultra-low cost
Voice assistant	MPU	Needs to run speech recognition
Soil moisture sensor in field	MCU	Solar-powered, sends tiny data

32.3.4 Real-World Example: Smart Thermostat

A Nest thermostat uses BOTH:

Figure 32.4: Hybrid MCU-MPU Design: Nest Thermostat Power-Efficient Architecture

Nest Thermostat Architecture: Combines a low-cost MCU for continuous sensor monitoring with an MPU for complex tasks like machine learning and Wi-Fi connectivity.

• MCU handles: Reading temperature every second
• MPU handles: Learning your schedule, pretty display, Wi-Fi

32.3.5 The Key Numbers to Know

Spec	MCU (ESP32)	MPU (Raspberry Pi 4)	Your Laptop
Clock Speed	240 MHz	1.5 GHz	3+ GHz
RAM	520 KB	4 GB	16 GB
Storage	4 MB	32 GB SD	512 GB SSD
Power	0.05 W	3-5 W	45 W
Cost	$4	$55	$1000+
Battery Life	Years	Hours	Hours

Putting Numbers to It

Power efficiency comparison using performance-per-watt:

\[ \text{Efficiency} = \frac{\text{MIPS}}{\text{Power (W)}} \]

ESP32: \(\frac{600 \text{ MIPS}}{0.05 \text{ W}} = 12{,}000\) MIPS/W

Raspberry Pi 4: \(\frac{3{,}000 \text{ MIPS}}{4 \text{ W}} = 750\) MIPS/W

MCUs are 16× more power-efficient for compute tasks. For battery life on 3000 mAh @ 3.7V (11.1 Wh):

ESP32 (active): \(11.1 / 0.05 = 222\) hours = 9.25 days

Pi 4 (active): \(11.1 / 4 = 2.8\) hours

With 99% sleep (10 µA): ESP32 → \(11.1 / (0.00001 \times 3.7) = 30{,}000\) hours \(\approx\) 3.4 years!

32.3.6 Interactive: MCU vs MPU Cost-at-Scale Calculator

Use the sliders to see how processor choice impacts total hardware cost across a deployment:

viewof fleet_size = Inputs.range([10, 10000], {value: 1000, step: 10, label: "Fleet size (devices)"})

viewof mcu_cost = Inputs.range([1, 20], {value: 5, step: 0.5, label: "MCU unit cost ($)"})

viewof mpu_cost = Inputs.range([15, 100], {value: 55, step: 1, label: "MPU unit cost ($)"})

{
  const mcu_total = fleet_size * mcu_cost;
  const mpu_total = fleet_size * mpu_cost;
  const savings = mpu_total - mcu_total;
  const pct = ((savings / mpu_total) * 100).toFixed(1);

  return html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #E67E22; margin-top: 0.5rem;">
    <p style="margin:0 0 0.5rem 0"><strong>MCU fleet cost:</strong> ${mcu_total.toLocaleString()}</p>
    <p style="margin:0 0 0.5rem 0"><strong>MPU fleet cost:</strong> ${mpu_total.toLocaleString()}</p>
    <p style="margin:0;font-size:1.1em"><strong>Savings with MCU:</strong> ${savings.toLocaleString()} (${pct}% less)</p>
  </div>`
}

32.3.7 Self-Check Questions

Before continuing, make sure you understand:

1. What makes an MCU different from an MPU? (Answer: MCU has everything on one chip; MPU needs external RAM/storage)
2. Why use an MCU for a battery-powered sensor? (Answer: Much lower power consumption—years vs hours of battery life)
3. When would you choose an MPU over an MCU? (Answer: When you need to run an OS, do complex processing, or display video)

Ready for the technical details? Continue below!

Key Takeaway

In one sentence: Choose microcontrollers (MCUs) for battery-powered sensors that need years of life on a coin cell; choose microprocessors (MPUs) only when you need an operating system, video processing, or machine learning.

Remember this: If your device runs on batteries and does one simple job, use an MCU - if it needs to run Linux or Docker, use an MPU. Getting this wrong wastes money (10x cost) or kills batteries (1000x power difference).

32.4 Microcontrollers and Microprocessors

Figure 32.5: Microcontrollers vs Microprocessors architecture comparison - integrated peripherals vs external components

Figure 32.6: Arduino microcontroller and ARM processor examples showing physical boards and pin configurations

Almost all electronics equipment contains either a microcontroller or microprocessor. Understanding the differences between these two types of processors is crucial for IoT system design.

32.4.1 What are Microcontrollers?

A microcontroller (MCU) is a compact integrated circuit designed to govern a specific operation in an embedded system. A typical microcontroller includes a processor, memory, and input/output (I/O) peripherals on a single chip.

Examples: Digital watches contain microcontrollers that continually loop and count time. Washing machines use microcontrollers to control operations from on/off switches to different wash phases.

If the engine is the heart of a car, the microcontroller is the heart of an electronic device.

32.4.2 Advantages of Microcontrollers in IoT

Most IoT systems utilize microcontroller units (MCUs) to collect data and transfer it to processing units through the Internet:

• Simplicity: MCUs do not require an operating system to function and are easy to interface with external components such as sensors
• Cost-effectiveness: An MCU is usually sufficient to provide processing power and functionality in most IoT systems
• Security: Due to their simplicity, MCUs are less vulnerable to security attacks

32.4.3 What are Microprocessors?

A microprocessor is a micro version of our computers. Generally, if an application requires a form of Operating System, a microprocessor is normally used. Examples include ARM microprocessors used in smartphones.

Pitfall: Insufficient Flash/RAM Margin for Firmware Updates

The Mistake: Selecting a microcontroller with “just enough” flash memory for initial firmware, then being unable to add features, fix security vulnerabilities, or implement OTA updates because memory is exhausted.

Why It Happens: Developers optimize for unit cost, choosing the smallest (cheapest) MCU that fits the initial code. They do not account for OTA requiring space for both current and new firmware images, or for inevitable feature growth and bug fixes over the product lifetime.

The Fix: Budget at least 2x flash for OTA-capable devices (current image + new image + bootloader). Reserve 30-50% RAM headroom for stack growth, future features, and security patches. Consider that SSL/TLS libraries alone consume 30-80KB flash. The $0.50 savings per unit from a smaller MCU evaporates when you cannot push a critical security update to 10,000 deployed devices, requiring expensive field recalls instead.

Understanding Fleet Management

Core Concept: Fleet management is the operational discipline of monitoring, updating, and maintaining large numbers of IoT devices as a unified system rather than individual units, enabling visibility into aggregate health, coordinated firmware updates, and efficient troubleshooting at scale. Why It Matters: Managing 10,000 devices individually is impossible. Fleet management provides the abstraction layer that transforms thousands of independent devices into a controllable system. Without it, you cannot answer basic questions like “How many devices are running outdated firmware?” or “Which devices have battery levels below 20%?” or “What percentage of devices successfully completed the latest update?” Fleet management enables proactive maintenance (replace batteries before failure), efficient support (identify affected devices when customers report issues), and data-driven decisions (retire underperforming hardware revisions). Key Takeaway: Implement fleet management from your first 100 devices, not your first 10,000. Choose platforms that support device grouping (by region, hardware version, customer), fleet-wide queries (device twins/shadows), bulk operations (OTA updates to device cohorts), and aggregate dashboards showing fleet health distribution rather than individual device status.

Pitfall: Health Monitoring Relies Only on “Last Seen” Timestamp

The Mistake: Device health monitoring checks only whether the device has reported to the cloud within the last N minutes. A device sending corrupted data, stuck in a reboot loop, or operating with failed sensors appears “healthy” as long as any message arrives, masking critical failures until customers complain.

Why It Happens: “Last seen” is the easiest health metric to implement - just compare current time to last message timestamp. Teams assume that if a device is communicating, it must be working. This conflates “device is alive” with “device is functioning correctly,” ignoring degraded states between fully operational and completely dead.

The Fix: Implement multi-dimensional health scoring with specific thresholds. Each heartbeat must include: (1) Uptime counter - detect reboot loops (>3 reboots in 1 hour = degraded); (2) Sensor validity flags - each sensor reports OK/ERROR/STALE status; (3) Battery voltage - alert at 20% remaining, critical at 10%; (4) Free memory - detect memory leaks trending toward crash; (5) Error counters - track I2C failures, network retries, watchdog triggers. Define health states: HEALTHY (all metrics nominal), DEGRADED (any metric outside warning threshold), CRITICAL (any metric outside error threshold), OFFLINE (no message in 2x expected interval). Use device shadow/twin to store last known health state. Dashboard should show fleet breakdown: “4,982 healthy, 15 degraded (low battery), 2 critical (sensor failure), 1 offline” rather than just “4,999 online, 1 offline.”

Pitfall: No Baseline Telemetry for “Normal” Device Behavior

The Mistake: Teams deploy 10,000 devices without capturing baseline telemetry, then cannot distinguish abnormal behavior from expected variation. When devices report 85% CPU usage, 2.3V battery, or 15-second response latency, engineers have no reference to determine if these values indicate a problem or are perfectly normal for that device model and deployment environment.

Why It Happens: During development, focus is on making devices work at all, not on characterizing normal operating ranges. Lab conditions differ from field conditions (temperature, network quality, usage patterns). Teams assume published specifications (e.g., “3.0-4.2V battery range”) define healthy operation without measuring actual device behavior in deployment.

The Fix: Establish quantitative baselines during pilot deployment (first 100-500 devices for 30 days). Capture: (1) Statistical distributions - mean, median, P95, P99 for each metric (e.g., battery drain rate: mean 0.5%/day, P95 0.8%/day); (2) Environmental correlations - CPU usage vs ambient temperature, battery drain vs transmission frequency; (3) Temporal patterns - normal daily/weekly cycles (higher activity during business hours). Define alerting thresholds as deviations from baseline: alert if battery drain >2x P95 baseline for that device’s cohort. Store per-device baselines for anomaly detection (device 00042 typically sleeps 23.5 hours/day; sudden 20-hour sleep indicates behavior change). Update baselines quarterly as firmware evolves. For new device models, require 30-day burn-in period collecting baselines before enabling production alerting. Use baseline data to set SLOs: “P95 response latency < 500ms” is meaningless without knowing P95 is normally 120ms.

Match Processing Power to Task Complexity

A common mistake is over-engineering edge nodes with powerful microprocessors when simpler microcontrollers suffice, or under-engineering with MCUs when processing demands require more. Use this decision framework: choose MCUs for simple sensor reading, threshold detection, and periodic reporting (temperature monitors, door sensors); choose microprocessors for local AI inference, video processing, protocol gateways, or applications requiring full OS features. Example: A smart thermostat reading temperature every 30 seconds needs only a $2 MCU consuming 10mW, while a security camera performing local face recognition requires a $35 processor consuming 2-5W. Overspec costs multiply across hundreds of devices; underspec leads to field failures requiring expensive replacements.

The Two Costs That Dominate Embedded Design

Two fundamental cost considerations push IoT designs toward minimal MCUs with optimized code:

1. Energy Cost

• Embedded systems have an expected workload—the goal is to minimize energy required to handle that workload (longer battery life, more efficient operation)
• Counterintuitive insight: More powerful MCUs can be more power efficient (completing tasks faster with less energy per operation), but they often consume more total energy for a given workload due to higher baseline power draw

MCU Class	Active Current	Sleep Current	Example	Trade-off
8-bit	5 mA @ 8 MHz	0.5 µA	ATtiny85	Slow but sips power
32-bit ARM	15 mA @ 48 MHz	2 µA	STM32L0	Fast but higher baseline
32-bit + Wi-Fi	80 mA @ 240 MHz	10 µA	ESP32	Very fast, much higher energy

2. Money Cost

• Many embedded markets operate with tight margins (cars, appliances, consumer electronics)
• More powerful MCUs cost more—not just the chip itself, but also supporting components (larger flash, more RAM, better power supply)
• At scale, even $0.50 savings per unit translates to $50,000 savings on 100,000 devices

Design Conclusion: Both costs push designs toward picking the minimal MCU capable of the task and optimizing code for it, rather than over-provisioning hardware and writing inefficient code.

Tradeoff: RTOS vs Bare-Metal Firmware for IoT Devices

Option A (RTOS - Real-Time Operating System): FreeRTOS, Zephyr, or ThreadX provide task scheduling, memory management, and driver abstractions. Development time: 30-50% faster due to reusable components. RAM overhead: 4-32KB. Latency: deterministic but with scheduler overhead (10-100us context switch). Power: slightly higher due to tick interrupts.

Option B (Bare-Metal / Super-Loop): Direct hardware access without OS abstraction. Minimal RAM (512B-2KB for stack), lowest power consumption (no scheduler overhead), fastest interrupt response (<1us). Development time: 50-100% longer for complex applications. Debugging: requires logic analyzers and hardware skills.

Decision Factors:

• Choose RTOS when: Application requires multiple concurrent tasks (sensor sampling + Wi-Fi + display), code portability across MCU families is valued, team lacks embedded expertise (RTOS abstracts hardware), or project timeline is tight (reuse existing drivers and middleware). FreeRTOS adds ~8KB flash, 4KB RAM to ESP32 projects.

• Choose Bare-Metal when: Extreme power optimization is required (sub-microamp sleep currents), hard real-time response under 10us is mandatory, RAM is severely constrained (8-bit MCUs with <1KB RAM), or simple single-task applications (read sensor, transmit, sleep). Bare-metal achieves 10-20% lower power consumption for simple duty-cycled applications.

• Cost-power tradeoff: For battery-powered sensors waking every 10 minutes, bare-metal saves ~15% energy per wake cycle. Over 5-year device lifetime with 2000mAh battery, this translates to 3-6 additional months of operation. For mains-powered devices, RTOS development speed advantage (weeks saved) outweighs negligible power difference.

32.5 Knowledge Check

Quiz: MCU vs MPU Selection

32.6 Worked Example: Fleet-Scale Processor Selection for Smart Agriculture

Worked Example: MCU vs MPU Cost-at-Scale for 5,000 Soil Monitoring Stations

Scenario: An agribusiness deploys 5,000 solar-powered soil monitoring stations across 50 farms. Each station reads soil moisture, pH, and temperature every 30 minutes and transmits a 64-byte payload via LoRa. The system must operate for 10 years with minimal maintenance. The engineering team debates between an ESP32 MCU and a Raspberry Pi Zero MPU.

Step 1: Hardware Cost per Station

Component	MCU Option (ESP32)	MPU Option (Pi Zero W)
Processor board	$5	$15
LoRa radio module	$8	$8
Sensor breakout (3x)	$12	$12
Solar panel + charge controller	$15	$35 (larger panel needed)
Battery (LiPo)	$6 (2000 mAh)	$18 (10,000 mAh)
Enclosure + cabling	$10	$12
Total per station	$56	$100
Total for 5,000 stations	$280,000	$500,000

Step 2: Power Budget (Why Battery Size Differs)

Parameter	ESP32	Pi Zero W
Active current (sensing + transmit)	180 mA for 2 seconds	300 mA for 8 seconds (OS boot + transmit)
Sleep current	10 uA	1.5 mA (Linux idle, no true deep sleep)
Energy per 30-min cycle	0.1 mAh (active) + 5 mAh (sleep) = 5.1 mAh	0.67 mAh (active) + 750 mAh (idle) = 750.7 mAh
Daily consumption	244 mAh	36,034 mAh
Solar harvest needed (6h sun)	41 mA panel	6,006 mA panel (impractical without large panel)

Step 3: 10-Year Operational Cost per Station

Cost Category	MCU (ESP32)	MPU (Pi Zero W)
SD card replacements (wear)	$0 (no SD card)	$10 (replace every 3 years)
Battery replacements	$0 (solar sufficient)	$36 (replace every 2 years)
Field visits for maintenance	$0-50	$150 (more frequent)
Firmware update failures	~0.1% brick rate (OTA)	~2% requiring field visit (corrupted SD)
10-year operational cost	~$50	~$196

Step 4: Total Cost of Ownership (10 Years, 5,000 Stations)

	MCU Fleet	MPU Fleet
Hardware	$280,000	$500,000
Operations (10 yr)	$250,000	$980,000
Development (one-time)	$80,000 (bare-metal C, longer dev)	$40,000 (Python, faster dev)
Total	$610,000	$1,520,000

Result: The MCU option costs 60% less over 10 years. The MPU’s faster development ($40K saved) is dwarfed by $910K higher hardware and operational costs. The Pi Zero’s inability to achieve true deep sleep makes it fundamentally unsuitable for solar-powered field deployment at scale. The lesson: development convenience savings multiply once, but hardware and power costs multiply by 5,000 stations times 10 years.

When the MPU wins instead: If each station also needed to run a local crop disease detection model on leaf images (requiring 512 MB RAM and GPU), the MPU becomes necessary despite the higher cost – the MCU simply cannot perform image classification.

Try It Yourself: Build a Processor Selection Matrix

Practice applying MCU vs MPU decision criteria to multiple scenarios.

Your task: For each scenario below, fill in a decision matrix with these columns: - Needs OS? (Yes/No – if yes, likely MPU) - Battery-powered? (Yes/No – if yes, heavily favors MCU) - Processing complexity (Simple/Moderate/Complex) - Recommended processor type (MCU/MPU/Hybrid) - Example platform (ESP32, Pi 4, STM32, etc.)

Scenarios:

1. Smart doorbell with HD video, two-way audio, motion detection, and cloud recording
2. Industrial vibration sensor that monitors machine health and sends FFT results every hour
3. Smart refrigerator with touchscreen UI, camera inside, expiration date tracking, and recipe suggestions
4. Soil moisture sensor that reports moisture level via LoRa every 4 hours, needs 5-year battery life
5. Autonomous robot vacuum with SLAM navigation, object recognition, and mobile app control
6. Wearable fitness tracker with heart rate, step count, sleep tracking, and Bluetooth sync
7. Security camera with local AI face recognition, 1080p streaming, and edge video analytics

Starter answers (fill in the rest): - Scenario 1 (Smart doorbell): Needs OS? Yes (video streaming server). Battery? Yes (but rechargeable). Complexity: Complex (video encode, cloud sync, ML). Recommended: Hybrid (MCU for always-on motion detect, MPU for video when triggered). Example: STM32 + i.MX8 or ESP32 + Rockchip RV1126 - Scenario 4 (Soil sensor): Needs OS? No (simple read-transmit-sleep). Battery? Yes (5-year target). Complexity: Simple. Recommended: MCU. Example: nRF52840 or STM32L0 (ultra-low-power)

Expected outcome: You should see patterns emerge – battery-powered + simple = MCU, wall-powered + complex = MPU, battery-powered + complex = hybrid or specialized low-power MPU.

Concept	Relationship	Connected Concept
MCU All-in-One Design	Reduces cost and pins via	SoC Integration – CPU, RAM, flash, timers, ADC, GPIO on single die eliminates external components
MPU External Bus	Enables expandability through	DDR Memory Interface – external DRAM allows gigabytes of RAM vs. MCU kilobytes on-chip
Deep Sleep Current	Determines battery viability via	Power Gating – ESP32 10 µA sleep vs. Pi Zero 120 mA idle = 12,000x difference in average power
RTOS vs Bare-Metal	Trades development speed for	Power Efficiency – FreeRTOS saves 30-50% dev time but adds 10-20% power overhead from scheduler
Platform Lock-In	Vendor SDKs reduce portability via	Abstraction Layer Cost – cloud-specific code (AWS IoT SDK) requires rewrite to switch providers
Cost at Scale	Multiplies BOM savings across	Production Volume – $51 MCU/MPU difference × 1,000 units = $51,000 total hardware cost variance

32.7 See Also

• Power Management and Interfaces – Deep dive into sleep modes, GPIO, PWM, and ADC that differentiate MCU platforms
• SoC Architecture – Internal block diagrams showing how MCU integration (CPU+radio+sensors) reduces external components
• Prototyping Hardware – 62+ platform comparison with cost, power, and capability tables
• Edge Computing Patterns – When edge processing (MCU) vs. cloud processing (MPU as gateway) is appropriate
• Energy-Aware Considerations – Duty cycling, sleep optimization, and power budget calculation techniques

Match the Platform to Its Ideal Use Case

Order the MCU vs MPU Decision Process

Key Concepts

• MCU vs MPU: Microcontrollers (MCU) integrate CPU, RAM, flash, and peripherals on a single chip for low-power deterministic control; Microprocessors (MPU) are CPU-only chips requiring external memory for running full operating systems
• Harvard Architecture: A processor design with separate instruction and data memory buses enabling simultaneous fetch and data access, used in many MCUs (AVR, PIC) for deterministic instruction timing
• Flash Memory: Non-volatile program storage on MCUs holding firmware through power cycles; typically 64 KB to 4 MB on IoT MCUs, constraining firmware size and OTA update design
• SRAM: Static RAM for program variables, stack, and heap on MCUs; volatile and power-hungry relative to flash — typical IoT MCUs have 2 KB to 512 KB, constraining data structures and network buffers
• Bare-Metal Programming: Firmware written without an OS, directly manipulating hardware registers for maximum determinism and minimum overhead — suitable for simple IoT applications with strict timing requirements
• Boot Time: Time from power-on to application readiness: MCUs boot in milliseconds from internal flash; MPUs running Linux require 10–60 seconds to load OS and kernel modules — critical for battery-powered wake-sense-sleep IoT nodes
• Peripheral Integration: The set of hardware peripherals integrated on-chip in an MCU (UART, SPI, I2C, ADC, PWM, timers) eliminating the need for external chips, reducing BOM cost and PCB area for IoT designs

Common Pitfalls

1. Using an MPU Where an MCU Suffices

Deploying a Raspberry Pi for temperature monitoring that reports every 10 minutes. The Pi consumes 2–5 W continuously, draining a 2000 mAh battery in hours. An ESP32 performing the same task at 80 µA average consumes 10,000× less power, lasting years on the same battery.

2. Assuming More RAM is Always Better

Selecting the MCU with the most RAM without analyzing actual peak usage. Larger RAM costs more, consumes more power, and may not be available in required packages. Profile actual stack and heap usage on representative firmware before finalizing hardware.

3. Ignoring Boot Time for Wake-from-Sleep Patterns

Designing a wake-sense-sleep IoT node on Linux/MPU where the OS takes 60 seconds to boot. The 60-second boot dominates active period energy consumption, making the device 60× less efficient than an MCU that starts sensing in milliseconds.

4. Conflating Development Ease with Production Suitability

Choosing Raspberry Pi because Python makes sensor integration easy in development. Production requirements of 5-year battery life, -40°C operation, and SD card wear leveling make MCU-based designs mandatory for many IoT deployments.

Label the Diagram

💻 Code Challenge

32.8 Summary

This chapter covered the fundamental distinction between microcontrollers and microprocessors for IoT applications:

• MCU vs MPU Selection: Microcontrollers (MCUs) integrate processor, memory, and I/O on a single chip for simple, low-power applications; microprocessors (MPUs) use external components for expandability and full OS support
• Processing Trade-offs: Choose MCUs ($1-10, 10mW) for sensor reading and basic logic; choose MPUs ($10-100+, 2-5W) for local AI inference, video processing, and complex applications requiring operating systems
• Platform Comparison: ESP32 ($5) provides Wi-Fi+BLE with 240MHz/520KB RAM; nRF52840 ($6) optimizes ultra-low power BLE with 0.4µA sleep; Arduino Uno ($3) offers simplicity for basic GPIO applications
• Cost at Scale: Choosing MCUs over MPUs for simple sensor tasks saves $50,000 hardware + $12,000/year battery costs + 98% power consumption for 1,000-device deployments
• Decision Framework: Ask “Do I need an OS?” first—if yes, use MPU; if battery-powered, use ultra-low-power MCU; if wall-powered and simple, use standard MCU

32.9 What’s Next

Direction	Chapter	Focus
Next	Power Management and Device Interfaces	Sleep mode hierarchy, GPIO configurations, PWM control, and ADC resolution
Next	SoC Architecture	Internal block diagrams, hardware accelerators, die area analysis
Back	Hardware and Device Characteristics	Series overview with worked example and quick reference