A microcontroller (MCU) is a single integrated circuit that combines a CPU core, on-chip flash or ROM for program storage, RAM, and a collection of peripheral interfaces (GPIO, timers, UART, SPI, I2C, ADC, and others) into one package. Unlike a general-purpose microprocessor, an MCU is designed to run a dedicated application directly from internal memory with minimal external components.
In practice
MCUs appear across an enormous range of embedded applications: 8-bit PIC or AVR parts in simple sensor nodes and appliances, 32-bit ARM Cortex-M devices in motor controllers and IoT gateways, and automotive-grade parts (Renesas RH850, Infineon AURIX, NXP S32K) in safety-critical vehicle systems. Clock speeds range from a few MHz on low-power 8/16-bit devices to several hundred MHz on high-end Cortex-M7 parts such as the STM32H7 or NXP i.MX RT. Flash sizes range from a few kilobytes to several megabytes. The EmbeddedRelated post "Choosing a Microcontroller for Your Vehicle" illustrates how selection criteria shift substantially depending on the application domain.
Selecting an MCU involves balancing CPU performance, peripheral mix, memory size, power consumption, package constraints, supply-chain availability, and toolchain maturity. A part with the right peripheral set can eliminate external ICs; a mismatch forces extra components or bit-banged protocols. The post "Make Your Own MCU Boards (2023 Teardown Conference)" covers practical board-level integration considerations once a part is chosen.
On-chip peripherals are a defining characteristic. Many MCUs include at least one hardware UART, SPI, and I2C peripheral, plus GPIO and a multi-channel ADC, though specific peripherals vary by family and variant -- some parts omit one or more of these or offer them only on certain package options. Higher-end parts add USB, CAN, Ethernet MACs, DMA controllers, hardware crypto accelerators, and DSP instructions. Peripheral capability varies widely even within a single vendor's product line, so consulting the datasheet and reference manual -- not just the marketing summary -- is essential before committing to a part. TI's resource center (referenced in "New TI MCU Resource Center") is an example of vendor-provided tooling that helps navigate a large portfolio.
A common early mistake is underestimating RAM and flash requirements. Embedded code written in C with a real-time OS, USB stack, or TLS library can consume hundreds of kilobytes quickly. Leaving headroom for debug instrumentation and future firmware updates is good practice. Button debouncing, interrupt latency, and other low-level behaviors covered in "Introduction to Microcontrollers - Buttons and Bouncing" are representative of the practical details that determine whether a design works reliably.
Frequently asked
What is the difference between an MCU and an MPU (microprocessor unit)?
An MCU integrates CPU,
flash,
RAM, and peripherals on one die, allowing it to run standalone with few or no external chips. An MPU typically provides a more powerful CPU core but relies more heavily on external memory and support ICs, though some MPU-class devices integrate flash or other functions and the exact boundary varies by product. The line is blurring -- some devices marketed as MCUs (e.g., NXP i.MX RT 'crossover' parts) run at 600-1000 MHz with no internal flash and require external QSPI flash -- but the general distinction holds for most product families.
How do I choose between an 8/16-bit MCU and a 32-bit MCU?
For very simple, cost-sensitive, or ultra-low-power applications, 8-bit parts (PIC, AVR, MSP430) remain viable. For most new designs, 32-bit ARM Cortex-M parts (STM32, SAM, nRF52, Kinetis) offer more memory, faster execution, richer peripherals, and broad toolchain support at competitive prices. 8-bit devices can be cheaper in high volumes, but development cost, code maintainability, and peripheral limitations often tip the balance toward 32-bit even at the low end.
What is meant by an MCU's 'core' versus the MCU itself?
The 'core' refers to the CPU logic -- instruction execution,
registers, and pipeline -- often licensed from a third party (ARM, RISC-V IP vendors, etc.). The MCU is the full chip built around that core, adding a specific peripheral set, memory configuration, clocking, and packaging. Two MCUs sharing the same core (e.g., both Cortex-M4) can differ substantially in peripherals, memory, and behavior. Core-level code is often portable; peripheral driver code is not.
Can an MCU run an operating system?
Yes, with caveats. Small RTOSes such as
FreeRTOS, Zephyr, and ThreadX run on MCUs with as little as 4-8 KB of
RAM, though more is recommended for comfort. Standard Linux requires an
MMU, which most MCUs lack; specialized no-MMU Linux kernels exist but are uncommon and limited in capability. Linux typically targets application processors (Cortex-A, MIPS, RISC-V application cores). Some higher-end MCU families (Cortex-M23/M33 with TrustZone) support lightweight security frameworks but not a full Linux kernel.
What is a 'bare-metal' MCU application?
A bare-metal application runs directly on the MCU hardware with no OS layer -- typically a startup file that initializes the
stack and data sections, followed by a main() loop and
interrupt service routines. It gives maximum control and minimal overhead, which matters on parts with very little
RAM and
flash. The tradeoff is that the developer manages scheduling, concurrency, and hardware access manually, without OS abstractions.
Differentiators vs similar concepts
MCU is often contrasted with MPU (microprocessor unit): an MCU integrates memory and peripherals on-chip, while an MPU is a standalone CPU core requiring external memory and support chips. MCU is also sometimes contrasted with SoC (system-on-chip); the terms overlap because many MCUs can reasonably be called SoCs, but SoC is the wider category -- not every SoC is an MCU. SoC more often implies higher integration -- including application-class CPU cores, graphics, and large on-chip
RAM -- targeting richer software stacks such as Linux, whereas MCU implies a self-contained device intended for firmware-based embedded control.
