Microcontrollers and peripherals
Treat the MCU as an integrated platform—not simply a processor—and select its core, memory and peripherals against the complete system need.
After this module, you should be able to:
- Explain how the core, memory and peripherals cooperate
- Select an MCU using system-level criteria
- Reason about interrupts, timers and DMA
- Identify configuration and lifecycle evidence to retain
Study guide · Updated · About 9 minutes reading + 20–30 minutes practice
Before you start: Read TEA-101. You should recognise GPIO, timers, ADCs and memory.
A microcontroller is a coordinated collection of resources.
An MCU combines a processor core, programme and data memory, clock and reset control, interrupt handling, input / output and specialised peripherals on one device. Much of the system’s real-time behaviour comes from how these resources are configured and connected—not from instruction speed alone.
Peripherals can often perform work autonomously. A timer can trigger an ADC; DMA can transfer samples into memory; a comparator can shut down a PWM output without waiting for software. Used deliberately, these paths reduce latency and processor loading. Used casually, they create hidden behaviour that is difficult to analyse and test.
Select for the worst credible operating condition.
| Dimension | Questions to ask | Common trap |
|---|---|---|
| Compute | Worst-case execution time, interrupt loading, control rate, start-up time and future margin? | Using average CPU load as proof |
| Memory | Code, stacks, heaps, buffers, diagnostics, update image and growth allowance? | Counting only the current application binary |
| Peripherals | Channels, simultaneous use, resolution, trigger routes, pin conflicts and electrical limits? | Assuming every advertised function can operate together |
| Timing | Clock accuracy, timer width, capture resolution, interrupt latency and jitter? | Equating clock frequency with determinism |
| Safety and security | Watchdogs, memory protection, ECC, self-test, secure boot, key storage and debug control? | Adding protection after hardware selection |
| Power and environment | Modes, wake sources, voltage, temperature, EMC sensitivity and thermal dissipation? | Using headline low-power figures |
| Lifecycle | Availability, second source, errata, toolchain support and migration route? | Ignoring obsolescence and silicon revisions |
Check pin multiplexing and shared resources early
Two required peripherals may need the same pin, DMA channel, interrupt vector, clock source or bus bandwidth. Build a resource-allocation table while the schematic and architecture can still change.
Understand the paths that create timing behaviour.
Interrupts
An interrupt turns an asynchronous event into processor execution. Define priority, maximum service time, permitted nesting, shared-data protection and the consequence of an event arriving faster than it can be handled. Keep interrupt service routines bounded and move non-urgent work to a controlled execution context.
Timers and capture / compare
Timers create precise periods, timestamps, pulse measurements and PWM signals. Their resolution depends on source clock, prescaling and counter width. Rollover, synchronisation and clock changes must be designed rather than discovered during test.
Direct memory access
DMA moves data without an instruction for every transfer, but it introduces concurrent access to memory and peripherals. Specify buffer ownership, completion signalling, coherency, overrun behaviour and recovery from transfer errors.
Worked example: sampled motor control
A strong design identifies which path is normal and which path provides rapid protection. The control task may update PWM at 1 kHz, while a hardware fault input disables the output within microseconds. The slower software path must not be credited with the faster hardware response.
Configuration is part of the product design.
Clock trees, option bytes, pin modes, interrupt priorities, watchdog windows and peripheral registers materially affect behaviour. Generated configuration files are useful, but the design still needs human-readable intent and verification.
System requirements, margins, alternatives, safety / security features and lifecycle considerations.
Pins, timers, buses, interrupts, DMA channels, memory and clock domains.
Tool version, generated files, option settings, device revision and controlled changes.
Interrupt load, worst-case paths, deadlines, latency and jitter measurements.
Applicable silicon issues, impact, workarounds and verification.
Clock, reset, memory, watchdog, communications and peripheral boundary tests.
Common failure patterns
“Has ADC” says nothing about accuracy, speed, reference, trigger, channel interaction or usable pins.
A configuration tool silently changes clocks, priorities or initialisation order.
Timing is assessed in isolation rather than with simultaneous worst-case sources.
The chosen silicon revision has a limitation that invalidates a credited behaviour.
Create a resource allocation before selecting a part
Map every function to physical resources: timer channels, ADC inputs, DMA requests, interrupt lines, pins and memory regions. Two peripherals listed in a data sheet may compete for a pin or DMA channel. A package change may expose fewer signals even when the processor name remains similar.
Separate required capability from margin. Account for interrupt nesting, communications bursts, bootloader space, diagnostic buffers and update staging. Flash and RAM consumption need a release baseline and a growth allowance. A processor selected at almost full utilisation makes a later security fix an architectural problem.
Treat vendor errata as design inputs for the exact silicon revision. Record which issues apply, their triggers, workarounds and tests. Replacing a device with a newer revision can remove one issue while changing another assumption; a common part number alone is not enough to establish equivalence.
Control the path from power-on to valid operation
The product starts before the first C statement. During power ramp, reset assertion, boot selection and pin initialisation, an actuator-enable signal may be floating or held by a weak pull resistor. Agree safe electrical defaults with the hardware engineer, then verify the transition into application control.
Define the clock source, start-up stabilisation, frequency transitions and failure response. Peripheral timing may depend on a different clock domain from the CPU. A low-power mode can stop a timer that was assumed to supervise a deadline. Confirm which memories and registers survive each reset or sleep state.
Retain reset cause before initialisation clears it. Repeated brownouts should produce a diagnosable, bounded recovery sequence rather than repeatedly starting a physical operation. Confirm that the watchdog’s reset affects the outputs and peripherals needed by the system fault response.
| Resource | Conflict to examine | Verification |
|---|---|---|
| Timer | PWM and periodic acquisition share a time base. | Change PWM duty and confirm acquisition spacing. |
| DMA | Concurrent channels compete for bus access. | Measure transfer completion under simultaneous traffic. |
| Pins | Boot straps overlap normal interfaces. | Observe reset and normal operation on the real board. |
| Non-volatile memory | Erase blocks overlap settings or recovery data. | Interrupt each update phase and inspect retained state. |
Treat memory and DMA as an ownership problem
An interrupt, a task and a DMA engine can access the same buffer without agreeing when its contents are valid. Specify who may write, who may read and what event transfers ownership. On a cached processor, also establish the platform’s cache maintenance and ordering requirements. A task mutex cannot stop a DMA engine.
Measure stack usage under stressful call paths and interrupt combinations, and supplement observations with analysis of unexercised paths. Record linker layout, memory protection configuration and compiler options with the release. Resource settings are part of the product definition, even when generated by a configuration tool.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Resolve a timer and DMA conflict
A board needs 20 kHz PWM, a 1 kHz ADC sample trigger and continuous UART reception. The preferred MCU can route two of these functions through the same DMA request channel.
- Draw the resource allocation and identify which functions can use alternate routing or bounded interrupt handling.
- Explain what changing the PWM time base could do to ADC timing.
- Define a stress test and the configuration evidence needed for release.
Show the worked answer
Choose a supported allocation from the actual device reference manual. Possibilities include another timer or DMA route, a different pin assignment, or an interrupt-driven transfer whose timing has been budgeted. Do not assume all combinations advertised separately are simultaneously available. If no feasible allocation retains sufficient margin, change the part or architecture.
Separate PWM frequency from sample cadence unless synchronisation is intentional and specified. Test maximum UART traffic while varying PWM duty and exercising ADC transfers; observe missing samples, overruns and output timing. Include reset and low-power transitions. Retain the pin map, clock tree, DMA assignments, relevant errata and measured limits with the exact hardware and firmware versions.
Review criteria
- All shared resources are resolved using the selected device configuration.
- The test observes actual timing and data loss.
- Release records include silicon and configuration identity.
Check your understanding
Can an MCU data sheet alone prove the design fits?
No. It lists capabilities; package routing, shared resources, errata and actual workloads determine whether the complete configuration fits.
Why can DMA corrupt data despite a mutex?
DMA is not a task participating in that mutex. Buffer ownership and platform-specific coherency must include the DMA engine.
Further learning
- Arm CMSIS-Core — processor interface documentationPublisher source supporting this module’s framework discussion.
- Microchip microcontroller overviewExamples of MCU cores, integrated peripherals and application-oriented selection.
- Arm CMSIS documentationStandardised access to processor cores, peripherals, drivers, RTOS interfaces and debug.
Select and control the whole MCU platform.
Dependable behaviour comes from the combined design of core, memory, clocks, interrupts and peripherals—including their shared resources, configuration and failure responses.