A microcontroller unit (MCU) combines a processor, working memory and control peripherals in one integrated circuit. Many devices also contain nonvolatile program memory. Firmware uses those resources to read inputs, make decisions and control outputs in an embedded product. Selecting an MCU therefore starts with the required control task, electrical interfaces and software, rather than the highest clock frequency.
This guide explains the main building blocks, the practical difference between an MCU and a microprocessor, and the details to check before specifying a complete orderable part number.
What is inside a microcontroller?
The processor executes instructions. Memory holds the program and its working data, while peripherals connect that program to the surrounding circuit. The exact combination varies by device; an ADC, USB controller or wireless radio is a feature to verify, rather than something every MCU includes.
- Program memory: Flash commonly stores firmware and retains it without power. Some devices use other memory technologies or external program storage.
- SRAM: working space for variables, stacks and communication buffers. It normally loses its contents when its supply is removed.
- Data storage: dedicated EEPROM is available on some MCUs; on others, persistent settings may use Flash or an external memory. Check write endurance and erase granularity before choosing a storage method.
- GPIO and peripherals: digital inputs and outputs, timers, serial interfaces and analog blocks provide the connection to sensors and other electronics.
Microchip's memory overview distinguishes program Flash, SRAM and optional data EEPROM, including the availability of self-programming on supported devices. Firmware is therefore not necessarily a permanently fixed ROM program.
How does an MCU control a system?
Consider an illustrative temperature controller. The MCU reads a sensor, compares the result with a target, updates an output command and reports status. A digital sensor might use an I2C or SPI interface; an analog sensor requires a suitable analog input and signal conditioning. These alternatives change the peripheral and pin requirements.
A timer can schedule repeated work or generate pulse-width modulation. An interrupt can request software attention when an event occurs. Some devices also support DMA or autonomous peripherals that reduce CPU involvement in data movement or timing. Microchip describes this approach in its core independent peripheral overview.
Plan the whole signal path. A control output may require a driver or power stage, and a communications controller may require a separate physical-layer transceiver. For equipment with safety requirements, define fault detection and safe output behavior at system level; the presence of an MCU or watchdog does not establish that the finished product meets those requirements.
How are MCU types classified?
Common selection categories include 8-bit, 16-bit and 32-bit cores; available memory; peripheral mix; operating voltage; and package. Microchip's core architecture guide, for example, includes 8-bit PIC and AVR devices, 16-bit PIC24 devices and Arm-based MCUs. Arm Cortex-M names describe processor cores, while names such as STM32 identify a manufacturer's device families.
Bit width alone does not establish power consumption, price or suitability. Compare candidates against the same workload and operating conditions. A smaller processor with a useful timer or analog block may meet a task efficiently; a more capable device may be needed for larger buffers, numerical processing or additional software. Toolchain support and existing firmware also affect the engineering effort.
Microcontroller versus microprocessor
An MCU commonly combines on-chip program storage and SRAM with control peripherals. A microprocessor (MPU) commonly forms part of a system with external working memory and program storage. These are useful selection patterns, rather than absolute definitions: inspect the memory architecture and interfaces of the actual devices.
Microchip's MCU versus MPU selection article discusses memory, software and interface requirements as decision factors. Its older numerical examples should not be treated as limits for present devices. For a new design, establish whether the application needs a small firmware image, an RTOS, or an operating system and memory subsystem that point toward a different processor class.
Do not decide from statements that an MCU can never approach an MPU's performance, or that only an MCU can handle interrupts. Define response deadlines, memory needs and software requirements, then assess the proposed implementation.
Read an exact MCU part number: STM32F103C8T6
STMicroelectronics' STM32F103x8/xB datasheet, DS5319 Rev 20 provides a concrete example. STM32F103C8T6 is a Cortex-M3 MCU with a maximum CPU frequency of 72 MHz, 64 KB Flash and 20 KB SRAM. Its order code specifies a 48-pin LQFP package and an industrial temperature code.
| Order-code element | Meaning for this example |
|---|---|
| C | 48 pins |
| 8 | 64 KB Flash |
| T | LQFP package |
| 6 | Industrial ambient range: −40 to +85 °C, subject to operating and thermal conditions |
The standard operating supply range is 2.0–3.6 V; operation using the ADC has a 2.4–3.6 V analog supply requirement. Check the electrical tables and pin functions for the intended configuration. A family's list of peripherals does not prove that every function is available together in every package.
A practical MCU selection checklist
- Define the signals. List supply rails, input levels, analog channels, serial ports, timer channels and required update rates. Make a pin allocation before choosing a package.
- Budget memory. Include program code, libraries, stacks, communication buffers and any planned update mechanism. Check the compiled image and measured stack use during development rather than relying on a generic memory allowance.
- Define timing. Identify response deadlines and the work performed between events. Clock frequency is an input to that analysis, not a measured application throughput figure.
- Budget energy. Consider active time, sleep time, wake-up overhead, enabled peripherals and external loads. Compare datasheet current values only with their voltage, temperature, clock and peripheral conditions attached.
- Check the hardware support. Review power and ground connections, decoupling, reset, clock sources, boot configuration and programming access. For the STM32F10xxx example, ST's AN2586 hardware development guide covers these subjects.
- Review limitations. Read the current device errata alongside the datasheet and reference manual. Identify any limitation affecting the selected peripheral or operating mode before committing the design.
What should engineering give purchasing?
Specify the complete manufacturer order code, package, temperature range and any required packing suffix. Keep the approved datasheet revision, schematic and firmware configuration with the design record. A development-board name or a shortened family name is insufficient to define the production component.
For a proposed replacement, compare pin assignments, supply and I/O limits, memory, peripheral behavior, boot configuration, programming method and applicable errata. Shared architecture or a similar part number does not establish interchangeability. Record engineering approval before accepting a substitution.
Request current commercial terms, availability and any required lot documentation for the actual offered part. These purchasing details are separate from a device's electrical specifications. An industrial temperature designation also does not establish automotive qualification or approval of the finished equipment.
Common microcontroller questions
Does an MCU need external components?
Yes, plan its supply, connections and supporting circuitry. Integration can reduce the component count, but the device's hardware requirements and the surrounding loads still determine the circuit.
Is a 32-bit MCU always the better choice?
Choose against the requirements. Memory, peripherals, software support, timing and total implementation cost can matter more than bit width.
Can two MCUs with the same core use the same firmware?
The core is only one part of the device. Check startup code, memory layout, peripheral registers, drivers and board configuration before planning a firmware port.