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.

Subjects covered in this topic:


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.

old_mpu_block_diagram.png

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, 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) was 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 processing capabilities of embedded designs grew, adding sophisticated graphics and networking capabilities, MPUs entered into 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, there remains a few significant hardware architectural differences between them. In this section, we’ll explore the hardware architecture of MCUs and MPUs in more detail.

Microcontroller Units (MCU)

MCU’s 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, Flash memory for mass storage (also known as program memory).

MCU’s 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 into 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.

MCU’s 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:

sam9x60_programmers_model.png

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 below). 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:

  • Static RAM (SRAM) – A 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+)
atsama5d2_programmers_model.png

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, MPU’s 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 – are available in high capacities (tens of megabytes to tens of gigabytes). They are less expensive than NOR Flash.
  • Managed Flash – are NAND Flash memory with a controller to provide a standard interface that is compatible with contemporary file systems and shield the developer from the 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 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 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 below.

For more information see:

Memory Management Unit (MMU)

MPU’s 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.

For more information on Microchip Technology’s PMICs, see:

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.png

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.

For more information see: MPU Debug Probes

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.

For more information see:

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, reset 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.

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, there are two RTOS’s that 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.

More can be learned at:


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 System on Modules (SoM). In addition, reference designs are available from Microchip Technology Inc.

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.


What’s Next?

Learn more about the MPLAB ecosystem:

MPLAB® Harmony 3 Software Framework

Embedded Linux®

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.