Differences Between MCU and MPU Development
Introduction
This training is for the embedded systems software developer who wishes to use the MPLAB® Harmony 3 Software Framework or Embedded Linux® with Microchip Technology’s 32-bit Microprocessor Units (MPUs) (SAM9x60, SAMA5D2).
In this training, we compare and contrast the differences between MCUs and MPUs. It aims to assist you in selecting the right processor for your application and get you started quickly with MPU development.
The difference between MCU and MPU development is primarily due to their hardware architecture and software development methodologies. Not long ago the distinction was easy to see. However, as silicon chip processes improved, the differences have grown closer in recent years making it difficult to distinguish them.
Differences Between MCU and MPU Development
In the beginning, there were MPUs. They required a host of support chips (memory, Input/Output (I/O), and peripherals) to create a complete computing system. They were, and still are, the main processing unit(s) in personal computers and servers. Back in the day, you rarely saw MPUs in an embedded application as they took up a great deal of space and were expensive.
Along came MCUs. A major difference is that MCUs are generally all-in-one devices containing CPU, ALU, programmable Non-Volatile Memory (NVM) (Flash), volatile Static Memory (SRAM), and a host of peripherals (UART, ADC, etc.) in a single package. Support chips were no longer required. MCUs were primarily developed for embedded applications, both for specific (for example, motor control) and general purposes.
The majority of embedded applications require minimal resources and processing power. Thus, MCUs tend to be much smaller, and consequently, lower in cost, and limited in processing power (as compared to MPUs), memory, and peripherals. However, as silicon chip processes improved, allowing for more transistors per die, MCU capabilities increased, and today their processing capabilities have grown closer to MPUs. MCU software development also became more sophisticated. Real-Time Operating Systems (RTOS) were introduced to satisfy applications that require strict timing requirements and ease of programming. RTOS allows for software libraries and network stacks that can be reused. With all of these improvements, MCUs are now seen in computational demanding applications that once were the realm of MPUs.
In contrast, MPU hardware became more integrated requiring fewer support chips, making them look more like their all-in-one MCU cousins. As the processing capabilities of embedded designs grew, adding sophisticated graphics and networking capabilities, MPUs entered the embedded world. A major benefit of MPU software development is the ability to run operating systems; the popular open-source Linux operating system and sophisticated RTOS. Thus today, MPU and MCU hardware architecture and software development have grown toward each other and their differences are now closer to each other.
In the next two sections, we’ll explore in more detail the hardware architecture and software development mythologies of MCUs and MPUs.
Hardware Architecture
As process technologies advanced, MCUs and MPUs have grown closer to each other in capabilities; however, a few significant hardware architectural differences remain. In this section, we’ll explore MCU and MPU hardware architecture in more detail.
Microcontroller Units (MCU)
MCUs are primarily single-package devices. Everything that is needed to create a complete computing system is available – CPU, ALU, peripherals (ADC, UART, etc.), SRAM for registers and main memory, and Flash memory for mass storage (also known as program memory).
MCUs contain all of the support circuitry such as oscillators for the master clock, timers/counters, watchdog timers, and reset circuitry. Onboard voltage regulators take a single input voltage (often 3.3 or 5.0 volts) and create the ancillary voltages required for each of the circuit blocks of the MCU. Upon power-on-reset, an MCU will begin running the program code that is stored in its internal Flash memory. Depending on the relative size of the MCU, especially for the smaller devices with limited I/O pins, debug and test circuitry may be limited or omitted entirely.
MCUs come in many different package types, sizes, and combinations of features allowing the developer to select the one that has the best mix of features for a given application.
Microprocessor Units (MPU)
In contrast, MPUs differ in hardware architecture in the following areas:
External Volatile Memory
External volatile memory refers to the main memory that is directly addressable by the MPU and used for the execution of program code (instructions). MPUs contain only a small amount of internal SRAM for registers and main memory. There’s just enough internal SRAM that the MPU can load the second-stage bootloader (bootloaders are covered in the "Software Development Methodologies" section). Therefore, MPUs rely on external volatile memory for main memory.
It is up to the developer to select the type and the amount of external volatile memory for the application. There are two popular technologies:
- SRAM – An MPU will include a small amount of internal SRAM and more can be added externally. However, SRAM is expensive.
- Dynamic RAM (DRAM) – DRAM is a popular choice for external volatile memory due to its higher densities and lower cost. Since there are several dynamic RAM technologies to choose from, MPUs include memory controllers that can be configured for the dynamic RAM technology selected for the design.
Applications that require large amounts of external volatile memory are:
- Wired and wireless networking stacks
- Graphics (for example, frame buffer for 24-bit VGA requires 921 kB)
- Operating Systems (for example Embedded Linux recommends 64 MB+)
External Non-Volatile Memory (NVM)
External NVM refers to the main memory that is accessed by the MPU and used for mass storage. MPUs do not contain memory for mass storage to hold bootloader(s), program code, and data. Therefore, MPUs rely on external NVM for mass storage.
Flash memory technology is a popular choice as it can be electrically erased and reprogrammed. There are three categories of Flash memory:
- NOR Flash – can be mapped into the CPU address space which allows for direct execution of program code. They are low-capacity (a few megabytes to a gigabyte). They also tend to be a more expensive memory solution compared to NAND Flash.
- NAND Flash – available in high capacities (tens of megabytes to tens of gigabytes). They are less expensive than NOR Flash.
- Managed Flash – NAND Flash memory with a controller to provide a standard interface that is compatible with contemporary file systems and shield the developer from internal complexities. Popular technologies are Secure Digital (SD) card, MultiMediaCard (MMC), Embedded MMC (eMMC), and USB Flash drives.
The amount of external NVM is determined by the amount of mass storage that is required by the application.
Bootloader
MPUs contain an internal Read-Only Memory (ROM) that contains a first-stage bootloader. It is the program that first runs when the MPU is powered on and reset. The first-stage bootloader is configured by a Boot Configuration register setting according to the project’s hardware and software configuration.
The purpose of the first-stage bootloader is to:
- Initialize the Master Clock (MCK)
- Read the Boot Configuration from the internal One-Time Programmable (OTP) fuse memory
- Configure external memory controllers and initialize external NVM
- Configure a serial port (Debug or UART) to be used for the target console
- Configure the JTAG port for debugging
- Load the second-stage bootloader at91bootstrap from external NVM into internal SRAM; Remap internal SRAM to address 0x0; Reset the PC to 0x0 and jump
- Else if external memory is not available, start the SAM-BA® Monitor program
More information about the first and second-stage bootloaders is explained in the "Software Development Methodologies" section.
Memory Management Unit (MMU)
MPUs contain a Memory Management Unit (MMU) that performs the translation of virtual memory addresses to physical addresses and controls access to and from external memory. The MMU allows the MPU to address a greater address space that is physically limited on MCUs.
Power Management
MPUs require multiple power supply input voltages and contain multiple power supply pins. In addition, the power supply pins require specific power-up and power-down sequences. To aid in these requirements a Power Management Integrated Circuit (PMIC) is added to the list of support chips required to create a complete MPU system.
Debug Environment
MPUs contain dedicated Debug and Test circuity used for standard debugging functions such as downloading code and single-stepping through programs. An external host computer with an external interface device called a Debug Probe communicates with the target device. Joint Test Action Group (JTAG), Serial Wire Debug (SWD), and two-wire UART are common communication interfaces to Debug and Test circuity on the MPU.
Debug Probes
Microchip Technology offers the popular Segger J-Link brand debug probes. They are fully supported by Microchip’s MPLAB X Integrated Development Environment (IDE) and Segger’s free software tools.
- The Segger J-Link On-Board (OB) Debug Probe is included on Microchip’s MPU evaluation kits. The J-Link OB provides debugging/programming and a virtual COM port from a single USB port.
- The Microchip J-32 Debug Probe is an external debugger/programmer for Microchip’s 32-bit MCU and MPU devices.
Packages
MPUs have a high pin count and therefore come in larger and more complex packages. MPUs typically come in Ball Grid Array (BGA) packages. BGAs require a higher-density Printed Circuit Board (PCB) for the routing of signals. In addition, the signal lines for memory require specific timing and impedance requirements.
To aid the developer, and reduce the hardware complexity, MPUs are available in:
- System-in-Package (SiP) – MPU integrated with DDR2 SDRAM in a BGA package
- System-on-Module (SoM) – MPU integrated with DDR2 SDRAM, Power management, NOR Flash, Ethernet PHY on a castellated PCB module
In addition, reference designs are available for developers to use in their hardware development.
Software Development Methodologies
Microcontroller Units (MCU)
Development Process
MCU software development is generally performed on a host computer using an IDE and cross-compiler.
The capabilities of MCUs depend on the size and combination of features for a given MCU. Once an MCU is selected for an application, those features are fixed.
Small, resource-limited MCUs are often programmed at the hardware level (often called bare metal programming) using a round-robin or state machine to control subroutines in the application. Larger MCUs with more resources can run an RTOS to satisfy applications that require strict timing requirements and ease of programming.
Software libraries are available from vendors to initialize a device and its peripherals. Software stacks for networking and for specific purpose applications (for example, motor control, switch mode power supplies, etc.) are generally available from the manufacturer and third-party vendors.
Boot Process
Upon power-on-reset, an MCU will begin executing the program code that has been uploaded to its program memory (also called Flash memory). Thus, the developer is responsible for how the MCU will initialize itself and start the program.
Microprocessor Units (MPU)
If the embedded application requires sophisticated graphics (video, 3D, touch) and/or networking capabilities (Ethernet, Wi-Fi® Bluetooth®), MPUs are a good choice as they generally have greater processing capabilities than MCUs and are capable of running operating systems such as the popular open-source Embedded Linux and sophisticated RTOS.
Development Process
MPU software development is generally performed on a host computer using an IDE and cross-compiler.
The capabilities and resources of MPUs are greater than MCUs. Internally they host an advanced architecture CPU, Floating Point Units (FPU), sophisticated instruction and data cache, high-speed bus interfaces to on-chip peripherals for graphics, communications, interface, analog (ADC and DAC), and multiple memory interface peripherals for a large selection of external memory types. Externally the MPU system includes the developer’s choice of volatile and NVM that fits the application.
Boot Process
Upon power-on-reset, an MPU will begin executing the first-stage bootloader located in the MPU’s internal ROM (also known as the ROM Boot code). The first-stage bootloader begins the process of initializing the processor and loading the second-stage bootloader into Internal SRAM.
First-Stage Bootloader
MPUs contain an internal ROM that contains a first-stage bootloader. It is a program that first runs when the MPU is powered on and reset. The first-stage bootloader is configured by a Boot Configuration register setting according to the project’s hardware and software configuration.
The purpose of the first-stage bootloader is to:
- Initialize the Master Clock (MCK)
- Read the Boot Configuration from internal OTP fuse memory
- Configure external memory controllers and initialize external NVM
- Configure a serial port (Debug or UART) to be used for the target console
- Configure JTAG port for debugging
- Load the second-stage bootloader at91bootstrap from external NVM into internal SRAM; Remap internal SRAM to address 0x0; Reset the PC to 0x0 and jump
- Else if external memory is not available, start the SAM-BA Monitor program
Second-Stage Bootloader
The second-stage bootloader, at91bootstrap, is an external program, available in source code format. It is written and maintained by Microchip Technology and hosted on GitHub. The developer downloads, configures, and builds it according to the project’s hardware and software requirements. Or the developer can use a pre-compiled version, provided it has the correct configurations for the application.
at91bootstrap is stored in external NVM memory. The first-stage bootloader initializes external NVM and loads at91bootstrap into internal Static RAM. Once it is loaded, the first-stage bootloader remaps internal SRAM to address 0x0, resets the PC to 0x0, and jumps.
The purpose of the second-stage bootloader, at91bootstrap, is to:
- Initialize the Main Oscillator
- Initialize external volatile and NVM controllers and interfaces
- Configure peripherals
- Load one of the following into external volatile memory (DRAM) and jump to:
- Third-stage bootloader (for example, Das U-Boot or BusyBox)
- Linux kernel directly (does not require a third-stage bootloader)
- MPLAB Harmony 3 application
- RTOS
- Debugger (JTAG)
Embedded Linux
Embedded Linux is a popular choice for MPU development. It is much more than just an operating system. It is a large collection of software libraries, device drivers, networking stacks, software applications, and tools to choose from. There are thousands of developers contributing to its open-source model, and there is a large online community providing tutorials and answering questions in forums to aid the developer.
- "ATSAMA5D27-SOM1-EK1 - Booting a Linux® Image"
- "SAM9X60-EK Evaluation Kit - Booting Demo Linux® Image"
- "SAMA5G54-EK Evaluation Kit - Booting Demo Linux Image"
Real-Time Operating System (RTOS)
RTOS provides multitasking, real-time scheduling, multi-thread capabilities, inter-task communications, and many more features. They also greatly simplify the development of complex applications. RTOS offers much more than just an operating system, they also include software libraries, device drivers, networking stacks, and a large selection of software applications.
Presently, two RTOSs are supported for Microchip's MPUs:
MPLAB Harmony 3 Software Framework
The MPLAB Harmony 3 Software Framework is a comprehensive collection of software libraries and tools for the software developer to manage, configure, and generate source code for Microchip Technology branded MPUs. The developer can choose the level of development that best suits their application. The framework includes many example applications to enable the developer to get started quickly.
For more information, see the "Developing Applications with MPLAB® Harmony v3 Software Framework for MPUs" page.
Summary
From a hardware architecture perspective, MPUs require external support chips to create a complete embedded system whereas MCUs are all-in-one package solutions. For a complete MPU system, the developer has to select power management circuitry, external volatile, and NVM. This flexibility allows the circuit designer to select the size and type of memory technologies required for the application. To simplify integration, MPUs are available in System in Package (SiP) and SoM. In addition, reference designs are available from Microchip Technology.
From a software development methodology perspective, an MPU “boots” binary files stored in external NVM and begins execution. The developer must be knowledgeable of the bootloader process and its stages. Binary files created on the host are uploaded to the target system’s external NVM using a Debug Probe or the SAM-BA In-System Programmer utility program.
MPUs offer the ability to run larger and feature-rich operating systems such as Embedded Linux and sophisticated RTOS. Both offer a large collection of software libraries, device drivers, networking stacks, software applications, and tools to choose from.
Learn More
- 32-bit Microprocessor Programming and Debugging Tools
- ATSAMA5D27-SOM1-EK1 Evaluation Kit
- SAM9X60-EK Evaluation Kit
- SAMA7G54-EK Evaluation Kit
- Developing Applications with MPLAB® Harmony v3 Software Framework for MPUs
- Developing with Embedded Linux
