Peripherals as Hardware Blocks
In the MCU context, a peripheral is not an external device you plug in. It is a dedicated hardware block on the same silicon die as the CPU core, designed to perform a specific I/O or timing function autonomously.
The CPU core (e.g., Arm Cortex-M7 in the STM32H743, Xtensa LX7 in the ESP32-S3) is just one block on the chip. Surrounding it are dozens of other blocks connected to the CPU through internal buses. These include communication interfaces (SPI, I²C, and UART — protocols for exchanging data with external devices like displays, sensors, and computers), timers, ADCs (analog-to-digital converters, for reading voltages), DACs (digital-to-analog converters, for outputting voltages), DMA engines (see below), USB controllers, and the RTC (see below). Each peripheral is controlled through memory-mapped registers: specific addresses in the MCU’s address space that, when written to or read from, configure and operate that hardware.
For example, on the STM32H743, the SPI1 peripheral’s registers start at address 0x40013000. Writing to offset 0x08 (the CR1 register) configures the clock polarity, phase, and baud rate. Writing to offset 0x20 (the TXDR register) places a byte into the transmit FIFO. The SPI hardware block then autonomously clocks that byte out on the physical MOSI pin — the CPU doesn’t bit-bang individual clock edges.
// Raw register access (what the HAL wraps)
*(volatile uint32_t*)(0x40013008) = 0x00000307; // CR1: enable, master, baud/8
*(volatile uint32_t*)(0x40013020) = 0x42; // TXDR: send byte 0x42In practice, you use a HAL (Hardware Abstraction Layer) that provides named functions and structs for this — HAL_SPI_Transmit() in ST’s C HAL, or Spi::new() in Embassy’s Rust HAL. The HAL is a convenience layer; the underlying mechanism is always register writes.
The Bus Matrix
Peripherals, CPU, SRAM banks, and DMA controllers are interconnected through a bus matrix — a crossbar switch that allows multiple masters (CPU, DMA1, DMA2, Ethernet MAC, USB, etc.) to access multiple slaves (SRAM banks, peripheral registers, flash) concurrently, with arbitration when two masters want the same slave.
This has a practical consequence that catches even experienced firmware engineers: not all memory is reachable by all bus masters. On the STM32H743, the DTCM RAM (128KB, tightly coupled to the CPU with zero wait states) is only accessible by the CPU — DMA controllers cannot read from or write to it. If you place a DMA buffer in DTCM, the DMA will silently access the wrong address and produce corrupt data. The memory map section of the datasheet documents which bus masters can reach which memory regions.
DMA (Direct Memory Access)
A DMA controller copies data between memory and a peripheral without CPU involvement. Without DMA, sending a 48,000-byte framebuffer over SPI requires the CPU to execute a tight loop: load byte → write to SPI data register → wait for transmit-complete flag → repeat. The CPU is blocked for the entire transfer.
With DMA, you configure a DMA channel with three parameters — source address (framebuffer in SRAM), destination address (SPI transmit register), and transfer count (48,000) — then start it. The DMA controller autonomously moves bytes one at a time, paced by the SPI peripheral’s ready flag. The CPU is free to do other work or enter a low-power state. An interrupt fires when the transfer completes.
For an e-paper display refreshing a few times per day, DMA is a nicety, not a necessity. For audio streaming or high-speed data acquisition, it’s essential.
RTC (Real-Time Clock)
The RTC is a peripheral that maintains a calendar/wall-clock time (year, month, day, hour, minute, second) and can trigger an alarm interrupt at a configured future time. It runs from a dedicated low-frequency oscillator, typically 32.768 kHz — the same frequency used in quartz wristwatches, chosen because it is exactly 2¹⁵ Hz, which divides down to 1 Hz with a simple 15-stage binary counter.
The critical property of the RTC is that it keeps running in the deepest sleep modes. On the STM32H743, the RTC lives in the “VBAT domain,” a separate power domain that can be sustained by a small coin cell battery even when main power is removed entirely (the same reason a desktop PC’s BIOS clock survives being unplugged). In Standby mode, the main CPU, SRAM, and all other peripherals are powered off, but the RTC continues counting and can wake the MCU when its alarm fires.
This is what makes “wake up every 4 hours and show a new sentence” possible without an external timer or computer: you configure an RTC alarm for 4 hours from now, enter Standby (drawing ~2µA), and the alarm wakes the MCU back to life.
Low-Power Modes
MCUs provide a hierarchy of sleep states that trade wake-up time for power savings. On the STM32H7 family:
- Sleep — CPU halted, all peripherals and clocks running, wakes on any interrupt. Modest power reduction.
- Stop — most clocks stopped, all SRAM retained, select peripherals can operate. Current drops to tens of µA. Wakes on configured events (RTC alarm, external pin interrupt). Wake-up takes ~5µs.
- Standby — nearly everything off. Only backup SRAM (4KB) and the RTC are retained. Current drops to ~2.4µA. Wakes on RTC alarm or wakeup pin; the MCU effectively reboots from reset (main SRAM contents are lost). Wake-up takes ~35µs.
For an e-paper display that refreshes every few hours, Standby with RTC wakeup is ideal: boot, render sentence, push framebuffer to display over SPI, enter Standby. The e-paper retains the image with zero power. The MCU consumes ~2µA until the next alarm.
ESP32 variants have analogous modes: Light Sleep (comparable to Stop) and Deep Sleep (comparable to Standby, ~10µA, wakes via RTC or GPIO).
The Datasheet Document Hierarchy
MCU manufacturers do not put all information in one document. The documentation is split by audience and scope:
- Datasheet — what the chip is: pinout, electrical characteristics, package dimensions, absolute maximum ratings. The contract — every number is tested and guaranteed. Consumed primarily by hardware/PCB engineers.
- Reference Manual — how every peripheral works: register-level descriptions, bit fields, state machines, timing diagrams, DMA integration. This is where firmware engineers live. For the STM32H743, this is RM0433 at ~3,400 pages.
- Programming Manual — the CPU core itself: instruction set, exception model, MPU, caches. For Cortex-M7, this is PM0253 (~260 pages). The core is Arm’s IP, documented separately from ST’s peripherals.
- Errata Sheet — known silicon bugs and workarounds. Read this early; it can save days of debugging.
- Application Notes — focused guides on specific topics: power supply design, peripheral usage patterns, migration between chip families.
Why the Datasheet Alone Is 357 Pages
The STM32H743 datasheet (DS12110) is not a tutorial — it’s a legally binding specification. The bulk comes from:
Pin alternate function tables (~80–100 pages): The chip comes in multiple packages (LQFP100, LQFP144, LQFP176, TFBGA240). Each pin can serve 8–16 functions (GPIO, SPI clock, timer output, ADC input, etc.) selected by an internal multiplexer. The datasheet must enumerate every function on every pin for every package variant. These tables are what you consult when deciding which pins to use for SPI, I²C, or any other peripheral — see STM32 and Nucleo Development for how this works on the Nucleo board specifically.
Electrical characteristics (~100–120 pages): DC specs (voltage thresholds, drive current, pull-up resistance), power consumption curves across every operating mode and temperature, ADC accuracy (SNR, THD, ENOB), oscillator accuracy, flash endurance (10,000 write/erase cycles guaranteed), data retention (20 years at 55°C). Every number is characterized on physical silicon.
Package mechanical drawings (~20–30 pages): Physical dimensions to 0.05mm precision for each package variant. A PCB engineer imports these to create the chip’s footprint — the copper pattern it gets soldered to.
The remaining pages cover the memory map, clock tree summary, ordering codes (part number decoding), and peripheral feature overview tables.
Who Reads What
Different projects consult different sections. The general pattern: you arrive with a specific question from a specific design decision, find the relevant table or graph, extract the number, and leave. Nobody reads 357 pages sequentially. For a firmware project like an e-paper display, you’d touch perhaps 15 pages — the pinout diagram, the alternate function table for your SPI pins, and the I/O voltage characteristics. For an extended treatment of which projects use which sections, see STM32 and Nucleo Development.