The Architectural Divide

The embedded world splits into two fundamentally different classes of device: microcontrollers (MCUs) that run your code directly on bare metal, and single-board computers (SBCs) that run a full operating system (usually Linux). This distinction determines the programming model, the performance characteristics, the power budget, and the kinds of applications that are natural on each.

An MCU — an STM32H743, an ESP32-S3, an ATmega328P — has a CPU core, SRAM (kilobytes to low megabytes), flash (for program storage), and peripheral controllers all on a single die. When you power it on, it begins executing your firmware from a fixed address in flash. There is no bootloader menu, no kernel, no filesystem, no scheduler (unless you put one there, e.g. FreeRTOS or Embassy’s async executor). Your code is the only code running.

An SBC — a Raspberry Pi 5, a BeagleBone, an Orange Pi — is built around an SoC (see below) and external DRAM chips (gigabytes), boots an operating system from an SD card or eMMC, and is, in every meaningful sense, a small general-purpose computer. You write applications in Python, C, Rust, Go, JavaScript — anything that runs on Linux.

SoC: The Chip Inside an SBC

An SoC (System on Chip) is a single chip that integrates a powerful application processor (Arm Cortex-A series, with an MMU capable of running Linux), a GPU, a memory controller, USB controllers, display controllers, and peripheral blocks (SPI, I²C, UART) — all on one die. What used to require many separate chips on a board (CPU, northbridge, southbridge, GPU) is now a single piece of silicon.

The Raspberry Pi 5 does not have “a processor” soldered to it — it has a Broadcom BCM2712 SoC, which contains a quad-core Arm Cortex-A76 CPU, a VideoCore VII GPU, PCIe/USB/Ethernet controllers, a memory controller, and SPI/I²C/UART peripherals. The DRAM (4 or 8 GB of LPDDR4X) is a separate chip soldered alongside the SoC on the PCB (printed circuit board), connected to the SoC’s memory controller by high-speed traces. The same pattern applies to phones: a Qualcomm Snapdragon is an SoC containing CPU, GPU, modem, and neural engine; the phone’s motherboard places it alongside separate DRAM and flash storage.

The relationship is hierarchical: an SBC (product) contains an SoC (chip), the way a Nucleo dev board (product) contains an MCU (chip). The boundary between SoC and MCU is blurry — the ESP32-S3 integrates RAM on-package and could be called an SoC — but the practical dividing line is: if it’s designed to run Linux with an MMU and external DRAM, people call it an SoC; if it’s designed for bare-metal or RTOS with integrated SRAM and flash, people call it an MCU.

The Same Protocols, Different Surfaces

Both MCUs and SBCs have SPI, I²C, and UART peripherals on their chips. A Raspberry Pi’s BCM2712 SoC has SPI, I²C, and UART hardware blocks just like an STM32 MCU. You can wire the same Waveshare e-paper display to either one with identical wiring — same SPI signals, same voltage levels (both are 3.3V logic).

The difference is in who manages the hardware:

On an MCU, your firmware directly configures peripheral registers (or uses a HAL that wraps them). You control clock speed, DMA channels, interrupt priorities. The SPI peripheral does exactly what you told it, when you told it.

On a Raspberry Pi running Linux, the kernel owns all hardware. Peripherals appear as device files: SPI as /dev/spidev0.0, I²C as /dev/i2c-1, UART as /dev/ttyAMA0, GPIO through the libgpiod library. Your application opens these files and uses ioctl() and read()/write() system calls — or, more commonly in Python, libraries like spidev, smbus2, or gpiozero that wrap those syscalls.

DMA exists inside the Pi’s SoC, and the kernel uses it internally for SPI transfers, but you never configure DMA channels yourself. The kernel driver handles it transparently. This is the tradeoff of running an OS: hardware management is abstracted away, and you gain convenience at the cost of fine-grained control.

Real-Time Guarantees

On an STM32, if you configure a timer interrupt to fire every 50µs, it fires every 50µs — nothing preempts your interrupt handler (unless a higher-priority interrupt exists, which you control). This makes MCUs suitable for hard real-time applications: motor control, audio sampling, safety-critical systems.

On a Raspberry Pi running Linux, the kernel might be handling a network interrupt, running garbage collection, or flushing a filesystem journal when your code expects to toggle a GPIO. Latency jitter of milliseconds is normal. For an e-paper display refreshing every few hours, this is irrelevant. For a 20 kHz motor control loop, it’s fatal.

Important

Real-time Linux variants (PREEMPT_RT patches) reduce worst-case latency to ~50–100µs on a Pi, but this is still 1000× worse than a dedicated MCU timer interrupt, and requires careful kernel configuration.

Power Consumption

A Raspberry Pi 5 draws 3–5W idle, even with the screen off and no user applications running, because the Linux kernel, systemd, and background services are always active. An ESP32-S3 in deep sleep draws ~10µA (roughly 33 microwatts at 3.3V). An STM32H743 in Standby with RTC draws ~2.4µA.

For a battery-powered desk display refreshing a few times per day, an MCU can run for months on a coin cell or small LiPo. A Raspberry Pi would drain the same battery in hours.

When to Choose Each

An SBC is the right tool when you need a full software stack — a web server, a database, a camera with OpenCV processing, Docker containers, a GUI framework, or simply the ability to pip install a library and get to work. The programming environment is familiar to any software engineer.

An MCU is the right tool when you need low power, real-time behavior, instant boot (no 30-second Linux startup), minimal attack surface, or per-unit cost below $5. The programming model requires learning embedded concepts (see Microcontroller Architecture), but the resulting system is deterministic and efficient.

Raspberry Pi in Commercial Products

The Pi most people know — the Model B with HDMI, USB, and a 40-pin header — is designed for education and prototyping. For commercial products, the relevant form factor is the Compute Module (CM).

The CM4 (and the newer CM5) is a small module-style board containing only the SoC, RAM, eMMC, and wireless radio — no ports, no connectors. The form factor borrows the concept from SODIMM (Small Outline Dual In-line Memory Module — the small PCB used for laptop RAM sticks, with a row of gold contact pads along one edge that plugs into a socket). The CM4 doesn’t use an actual SODIMM socket — it uses two 100-pin Hirose board-to-board connectors — but the idea is the same: a compact, removable module that gets all of its external connections from whatever board it’s plugged into.

A company designs a carrier board (a custom PCB) with a matching socket, and exposes only the interfaces their product needs. Real-world examples:

  • Digital signage — Screenly and Yodeck sell managed retail/restaurant display solutions running on CM4s
  • Industrial controllers — Revolution Pi (Kunbus) makes factory controllers built on the CM, packaged in cases that clip onto a DIN rail — a standardized 35mm metal rail (EN 50022) mounted inside industrial electrical cabinets, onto which circuit breakers, PLCs, power supplies, and similar equipment snap via a spring-loaded latch
  • Home automation — the Home Assistant Yellow hub is a CM4 on a custom carrier board with Zigbee/Thread radio
  • 3D printer controllers — Klipper-based printers often run on Pi hardware; BTT (BigTreeTech, a Shenzhen-based manufacturer of 3D printer electronics) ships boards with a socket for the CM4 so the printer controller and Linux host live on one integrated board
  • Network appliances — some small routers, NAS devices, and thin clients embed CM4s

Companies choose the Pi CM because the BCM2712 SoC is not sold separately — Broadcom only sells it to the Pi Foundation. The CM provides access to that silicon plus a fully maintained Linux BSP (kernel, drivers, device trees) at no software cost. The alternative — selecting a standalone SoC from NXP, Rockchip, or Allwinner — requires maintaining your own Linux BSP or paying for vendor support.

Warning

The tradeoff is dependency: you inherit the Pi Foundation’s supply chain constraints (the 2021–2023 chip shortage caused 12+ month lead times) and have no control over silicon end-of-life decisions. Companies with volumes above ~50k units/year typically invest in a standalone SoC with a direct vendor relationship.