What’s the difference between a microcontroller (MCU) and a microprocessor (MPU)? In simplistic terms, both are the brains of an embedded system. A few years ago, the distinction between the two was significantly starker because they offered vastly different capabilities and demanded widely different engineering skills. Today, the two terms remain, but innovations keep blurring the dividing lines. At ST, we see that integrators who previously only used MCUs now find it easier to grab an MPU. In fact, for some, microprocessors have become a secret weapon because they enable them to offer new applications or enter new markets thanks to their inherent capabilities or their ability to run Embedded Linux. Hence, let’s delve into this new trend.
Table of Contents
The origin story
MCUs as an alternative to MPUs
When the industry came up with the first microcontrollers in the 1970s, it was to find an alternative to overly power-hungry and complex MPUs. MCUs had much less computational throughput but incorporated the memory, processor, peripherals, and clock under one roof. Additionally, they could run a real-time operating system. Consequently, engineers could build deterministic systems with just one device, making them tremendously popular in automotive and motor control applications. Today, MCUs are everywhere, from smartphones to medical or household appliances. Conversely, MPUs dedicated their silicon space to computational units at the expense of power consumption or integration. That made them very attractive when trying to run multiple threads or a more complex OS like Embedded Linux.
Choosing between MCUs and MPUs based on application needs
An exhaustive exposition of the decision matrix that leads engineers to choose an MPU or an MCU would be overwhelming. However, there are recurring themes, such as computing needs. If an application requires a powerful neural processing unit or a myriad of computing cores and big GPUs, or if it performs contextual computing with lots of memory requirements, an MPU is an obvious choice. Conversely, a tiny software that wakes up occasionally to check a sensor’s value or that needs a deterministic response time of a few nanoseconds will use a microcontroller. Hence, in many instances, the “end justifies the means”. Put simply, an engineer will choose one device over another based on the application it will run.
Another factor could be the graphical needs of a system. Traditionally, human-machine interfaces (HMIs) with complex 3D animations, high-resolution displays, and extensive applications running alongside the UI will gravitate toward the GPU and memory controller of a microprocessor. Alternatively, HMIs that require much simpler animations and graphics are increasingly relying on MCUs. Frameworks like TouchGFX and hardware IPs like NeoChrom GPU continue to optimize what’s possible on a smaller microcontroller. Similarly, MPU for embedded systems also supports higher resolutions thanks to beefier GPUs. Hence, while each type of device is doing more, the demarkation remains pretty straightforward.
Choosing between MCUs and MPUs based on costs and power consumption
Besides computational throughput, developers look at other key metrics like power consumption, volatile and non-volatile memory needs, peripherals required, and number of pins needed. As engineers wrestle with cost constraints, these criteria become critically important because they impact the overall PCB design and bill of materials (BOM). For instance, a lot of flash and additional components will require multiple PCB layers, which increase lead time and costs. Hence, for the longest time, the equation was relatively straightforward. Integrators that focused primarily on cost or low power consumption chose a microcontroller.
The blurring of the lines between MCUs and MPUs
Since the early 2000s, MPUs have undergone significant changes. One of the most disruptive innovations in the world of MPUs has been the democratization of System-on-Modules (SoM) and System-in-Packages (SiP) for microprocessors. In years past, integrators had to design the entire system around the microprocessor, which meant dealing with more complex power management systems and a fiddly external memory, among other things. Indeed, using large external DDR memory requires a lot of fine-tuning and unique expertise, which could be a significant barrier to using an MPU. However, SoMs and SiPs remove all this complexity by securely and comprehensively incorporating all necessary components under one package or module.
Additionally, some of the latest ST microprocessors have come a lot closer to the power consumption of a microcontroller. Furthermore, microprocessors can now run a real-time operating system, further blurring the line between MPUs and MCUs. Previously, applications that required real-time execution, like motor control applications, had to run on a microcontroller. Today, engineers have started adopting MPUs to benefit from more computing power and access to larger memory capacity without compromising execution time. Put simply, some integrators are leveraging innovations in MPUs to turn them into a new secret weapon while competitors use MCUs.
The new story
An STM32H7 or an STM32MP1?
The last few years have significantly blurred the lines between high-performance MCUs and entry-level MPUs, making devices like the STM32MP13 a new darling for embedded system developers. Just like an STM32H7, the STM32MP13 supports Eclipse ThreadX on its own. Hence, developers who have never touched a microprocessor suddenly get a familiar environment, and applications that call FileX, NetDuoX, or USBX will run on both. Hence, it’s possible to enjoy a lot more performance without retraining teams or tremendously increasing BoM costs.
Furthermore, STM32 engineers have an additional advantage since the STM32Cube ecosystem of tools works with both our MCUs and MPUs, further lowering the barrier to entry. For instance, initializing the pin-out configuration and clock tree happens on STM32CubeMX. Developers looking to implement secure secret provisioning on their STM32 MPU will use STM32CubeProgrammer, the same application responsible for making secure firmware installs (SFI) more accessible. Consequently, users of our ecosystem have an additional incentive to explore MPUs as a secret weapon that can support new applications because they are already familiar with many of the development tools and concepts that drive all our devices.
From STM32MP13 to STM32MP15
The question for many embedded systems developers is no longer whether to venture into the MPU kingdom but how far they will delve into it and where to begin. Since many members of the ST Partner Program have launched SiPs and SoMs with an STM32MP13, the device is a great starting point in the decision-making process of any team looking to make an MPU their secret weapon. The device has one Cortex-A7 running at 1 GHz, which will attract those seeking a simple yet powerful device. The absence of multiple cores also means a low power consumption of 27 µW and the ability to integrate the STM32MP13 into a simple four-layer PCB.
Those wishing for more power will turn to the STM32MP15. The device comes with two Cortex-A7 cores and a Cortex-M4, thus still blurring the lines between MCUs and MPUs while pushing developers further into the land of MPUs. For instance, it’s possible to turn off the Cortex-A7 and use the Cortex-M4 as a traditional MCU to record sensor data while using significantly less power. Moreover, its 3D GPU is OpenGL-compliant, allowing developers to run vastly superior UIs than on a device without a GPU. It also comes with a lot more display interfaces and peripherals. The STM32MP15 can thus help integrator scale their system.
Let’s take the example of a company working on an industrial application, such as a programmable logic controller. Using the STM32MP13 allows them to design a headless yet powerful model. Afterward, developers can take the original design and upgrade the PLC with a display and a human-machine interface (HMI) using a resolution of 1080 x 720, thanks to the STM32MP15. Because the company started with an STM32 MPU, they can use the same Embedded Linux distribution and easily port their application from one MPU to the next. The operating system also runs remarkable UI frameworks, such as Qt or Crank , known for their portability.
Another example is smart thermostats, where the interface is an integral part of the experience. Makers have been differentiating themselves by using various levels UIs and screen sizes to attract a broader range of customers. By moving from an STM32MP15 to an STM32MP13, it becomes possible to run the same underlying application but with different bells and whistles to create a portfolio that covers more needs and price points.
From STM32MP15 to STM32MP25
Developers are increasingly concerned about creating products with a longer lifespan and leveraging machine learning at the edge. The latest advances in MPUs have helped them answer those needs by providing greater memory flexibility, which explains why many often adopt an STM32 MPU to stay ahead of the competition. For instance, the new STM32MP25 is our first MPU to support DDR4 and LPDDR4 on top of DDR3. Its 64-bit architecture also means it can address more memory for applications like audio processing and network appliances or run multiple software simultaneously to save resources, thus improving efficiency.
Because most industrial applications will use the same memory interface for a decade or more, it is critical for a microprocessor to offer a memory controller with more flexibility than what is usually found in consumer markets. That’s why ST MPUs always support multiple interfaces, and we ensure the widest compatibility, as demonstrated with the STM32MP25. It makes supporting a system more efficient while also facilitating the creation of design updates and upgrades.
Similarly, many are looking to benefit from machine learning at the edge. Consequently, the STM32MP25 is the first STM32 device to house support a 64-bit architecture thanks to its two Cortex-A35, which are the most efficient Arm core ever released. As a result, it can run more powerful applications while keeping the power consumption down. It also features a neural processing unit (NPU) capable of 1.35 TOPS, and its Vulkan-compatible GPU provides enough power to run a modern UI comfortably on a full HD display. Our new MPUs thus open the door to some of the most demanding applications, like smart cameras capable of people counting or object detection, and new systems like spatial computing.
What will the future hold?
ST is committing to release more STM32MP2 MPUs to help developers tailor their applications. Indeed, while there are a lot of microcontroller variants of the same series, microprocessors aren’t as varied because they are harder to make. However, as ST optimized its manufacturing capabilities, we plan to release more versions faster and make many of them pin-to-pin compatible. We already announced the STM32MP21 and STM32MP23. The STM32MP21 will provide a Cortex-A35 and a Cortex-M33, two Ethernet controllers, and a camera interface to serve cost-effective computer vision applications at the edge. As for the STM32MP23, it sits between the STM32MP25 and STM32MP21 thanks to its dual Cortex-A35 to enable a rich UI while prioritizing costs.
