Differences Between MCU and MPU Development

Last modified by Microchip on 2024/06/20 12:44

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.

Back to Top

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.

MPU System Block Diagram

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.

Back to Top

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.

Back to Top

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.

Back to Top

Microprocessor Units (MPU)

In contrast, MPUs differ in hardware architecture in the following areas:

SAM9X60 Block Diagram

Back to Top

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+)

SAMA5D2 Block Diagram

Back to Top

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.

Back to Top

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.

Back to Top

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.

Back to Top

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.

Note:

For more information on Microchip Technology’s PMICs, see the "Power Management Integrated Circuits (PMICs)" page.

Back to Top

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.

SAM9X60 Debug Environment

Back to Top

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.

Note:

For more information see the "32-bit Microprocessor Programming and Debugging Tools" page.

Back to Top

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.

Back to Top

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.

Back to Top

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.

Back to Top

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.

Back to Top

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.

Back to Top

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.

Back to Top

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

Back to Top

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.

Note:

For more information see the "at91bootstrap: A Second Stage Bootloader for Microchip MPUs" page.

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)

Back to Top

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.

Back to Top

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:

Back to Top

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.

Back to Top

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.

Back to Top

Learn More

Back to Top