There are fundamental differences in developing embedded UI applications for MCUs and MPUs. But as MCU performance and functionality continue to improve, the boundaries between the two have become murky.
By watching a replay of Co-Founder and VP of R&D Thomas Fletcher’s live Youtube video or by following along the transcript below, learn about the changing landscape in MCU versus MPU capabilities and what you need to consider when evaluating your next embedded project’s hardware options, in one of the first (of many) Embedded GUI Expert Talks with Crank.
Or, jump straight ahead to the question and answer session from the live video.
We’re looking at the roles of MPUs and MCUs in the context of embedded UI development and working through a few scenarios of how microcontrollers and microprocessors have changed. This is the start of a series where we're going to be exploring how embedded UIs work in these two different configurations. But we thought we'd start the series with just enough information to establish a baseline. What is an MPU? What is an MCU? How are they different? We're going to start with that and put in the context of embedded UI development.
Examples of microprocessors (MPUs).
MPUs are our typical microprocessor configurations. These are the desktop type systems that we often use scaling down to work on embedded environments. When we talk about MPUs, we're talking about systems that are fairly sophisticated but also general purpose - they aren't fully integrated. Microprocessors are chips that require peripherals that require support from other systems. For example, when we're talking about a system like an iMX6 or an Intelx86 system, if you're looking at evaluation boards like the Raspberry Pi, the BeagleBone, and the BeagleBoard family of prototyping boards, those types of systems have a very capable processor and a lot of peripheral support integrated into it.
One of the things that's particularly interesting about MPU systems is that a lot of them will also contain an MMU for memory management. This is an important consideration when we think about embedded UI development and what it takes to actually drive the UI.
Definition of MMU: A memory management unit (MMU) is the physical hardware that handles its virtual memory and caching operations. The MMU is usually located within the central processing unit (CPU), but sometimes operates in a separate integrated chip. All data inputs are sent to the MMU, which in turn determines whether data needs to be retrieved from storage.
Our team has been together at Crank Software doing embedded UI development for over 10+ years. When we first started, a lot of our embedded products were in this space: automotive products, medical devices, IVIs, dashboards, and other types of similar configurations were sitting in the space. Anybody that wanted a rich sophisticated touchscreen user interface was typically using an MPU configuration.
Examples of microcontrollers (MCUs).
On the other side of the coin, we've also seen different types of processor configurations called MCUs. What's an MCU in comparison to an MPU? The difference here is the C. It's a controller or microcontroller. It tends to be a much simpler system that tends to be much more integrated. Whereas an MPU or microprocessor relied on a lot of peripheral support, memory controllers, I/O controllers, and sometimes even external graphics configurations and boards. An MCU tends to be fully integrated. It brings all that functionality together in a simpler configuration for you to build into your product, but it also tends to be much more single-purposed, right? It doesn't run a variety of different applications all simultaneously, it tends to run just one thing.
Tip: The key differences between an MPU and MCU is that an MCU is more integrated and in a simpler configuration. An MPU relies on different applications and external support.
If we're thinking about the types of boards and configurations in the context of embedded UI development in the world today, we're looking at platforms and configurations from STMicroelectronics, including: the STM 37, STM F4, STM F7, and STM H7 class processors; from NXP, the RT series, the 1060s, the 1050s and Microchip has a lot of different controllers such as a PIC32 family in particular, where they're playing a role in embedded UI families. These types of configurations are much simpler and much more single-purpose. Types of embedded applications using these MCU platforms are control system configurations. Apps where you're doing I/O data collection and a little bit of management. Think HVAC systems, thermostats, and oven controllers. These kinds of systems tend to fall into the MCU category.
Historically, MCUs have not had a lot of embedded UI interaction, and that's simply because they were much simpler systems. They were fully integrated, they frequently didn't have a lot of memory capacity, or a lot of resource capacity. Developers would need to consider building code, deploying it down to a target, and then integrating it fully as a whole system.
Thomas explaining control systems on products that use embedded UI displays.
If we think about the type of applications that we’re running, like an HVAC or air conditioning - with control systems, there's been a shift. Here are two types of products that we see in the market today that could be using an MCU controller. You’ll notice that they are very focused on I/O control. A coffee maker, used to monitor the I/O, do measurements, do data collection or reading, but ultimately it's a very single-purpose type of device. Similarly, is an air filtration system that’s very sophisticated, but also single-purpose.
Coffee maker prototype using an MCU; including an embedded UI display.
These are embedded products that have integrated a LCD display into their configuration and if they're running on an MCU configuration, that means as soon as you start putting a display on it, one of your big requirements is memory. If we were to take this tiny little display, let's assume that it's 128 by 120 pixels, it’s a relatively small display. That display, if it was using a full 32-bit color (full red, green, blue alpha channels) would use roughly 64K of RAM. That memory amount needs to be available to the system. If you were a simple system and you don't have integrated memory, that's a big chunk to pull out of your chip's core. This is why it's typically the realm of MPUs.
What's interesting in the MCU category is that the recent MCU families have started integrating more memory capabilities, and that's really opened up the door to bring them a little closer to the typical MPU configurations. We’re now seeing MCUs shipping with 128K of RAM, 512K, a meg, 2 megs, even 10 megs in some cases, where that's really opening up the ability of these MCUs to start running richer graphic displays.
You can see here (in the live video), as the size of your graphic display grows, the memory requirements grow quite significantly and pretty fast. A 480x by 272x which is a common display size is still relatively small in terms of pixel density and is going to occupy half a meg of RAM for one single display buffer. Typically, you're going to want to double these so you're looking at a meg of memory just for the purposes of the display. Now, we're going to talk about this in future sessions but here I'm talking about 32-bit color display. It's easy for us to decimate that down to 16-bit colors, or there's other techniques that you can use to reduce that memory program. But what is essential is that the MCU needs to have memory on board, and part of the evolution of recent MCU systems is that they have integrated that memory.
It’s not just about memory configuration. An MPU is typically a lot more powerful as a processor, running a gigahertz or higher speeds. MCUs are still powerful in their own right but we’re talking about 100 megahertz, 200, 400, 600 megahertz, in terms of speed. Once you start putting graphics operations, where you need to be shuffling data back and forth into memory, you’ll run into a challenge of fulfilling the original objective of what the MCU was supposed to do - and at the same time rendering rich graphics, a display, a user interface, and so on. This is also being solved not just by the integration of more memory, but by the integration of rendering libraries and rendering technologies, in order to accelerate those graphical operations.
Here and in some cases, we're talking about full GPUs. For example, in the NXP case, we have the PXP graphics accelerator. In the ST Microelectronics case, we frequently see a DMA 2D engine, and that integration is key to allowing an MCU platform to support the graphics, to support the rich interaction and still fulfill its operational role inside the product in terms of the control systems of the I/O that it needs to do. It’s still single-purpose and very much a focused product device - but a simpler configuration overall, with the integration of more memory and advanced graphics rendering capabilities. This makes the MCU dig into some of the spaces where we would have typically seen an MPU processor being used. That's the hardware configuration story around hardware differences between MPUs and MCUs, where we're talking about the level of peripheral support required for configuration, and talking about the simpler integration story. But there's more to the embedded UI aspect of development. There's also the consideration of what your operating environment looks like.
On the MCU side, we’re typically seeing a real-time executive style operating system, while on the MPU side, we see a much richer operating environment in terms of its model. A lot of that has to do with this notion of what kind of memory access is being provided and what the system is looking like in terms of configuration.
Examples of operating systems.
QNX, Linux, Android; these are all systems that typically rely on a process model with processes executing independently from one another in a memory-separated space. This is so the system can be more resilient in terms of component failure - one component failing or writing into a block of memory doesn't actually affect the other components. This is an important consideration for product resilience, being able to support your product in a variety of different flexible considerations. This is why it tends to be tied to the general purpose configurations of an MPU.
However, the other piece that's really interesting is the development style. When you're working with a QNX system or Linux system, you tend to leave the system live and running all the time. You configure the system image, you're running individual processes, and one of those processes is probably your user interface or your graphics component. So, when in an application where you're likely iterating through changes on a very frequent basis, being able to do that rapidly and being able to push changes over very quickly with simply a software reset, is really important here. This is a big boon on the MPU side in terms of your development speed; your ability to iterate very quickly over change in the context of a UI. There's a lot of change and feedback cycles that go into developing a UI. This is one of the things that Crank really focuses on with our Storyboard product.
Thomas explaining the differences between operating systems for embedded devices.
If I compare that working model to what you see with an MCU, where you're typically using a real-time executive type of configuration. The difference between a real-time executive and our standard operating system is that a real-time executive offers many of the operating system functionalities in terms of task management, synchronization, and timers; but it offers it in a way where that isolation that you get with the process model, that's coming partially because it's a MMU factor or the memory protection, that's not there. It's also a different mindset. Typically, when you're working with these systems, you're not looking at soft resets. You’re usually assembling the entire system to work together in one system image or one system load. There are techniques that you can use to segment or break it up so that your development cycle doesn't have to always involve rebuilding and reflashing an entire system image. But because of the integrated nature of the MCU configuration, that is typically what you're doing.
There’s always exceptions to the rules. You can run Linux on some of these configurations and it really depends on the richness of the resources that are available to you in terms of memory and flash storage, and how many resources you have available to partition and give to the operating system as overhead compared to the rest of your application execution. This is a slower development model. Again, in the context of embedded UI development where a lot of changes happen, because this is a slower development model, you may have to rebuild the system, flash it down, look at it and then make further changes if it’s not quite right - this is a slower model. You can end up using a lot more simulation techniques or more scaffolding where I'm building an application but I'm building it in a framework that I can execute in my desktop environment, or maybe even in an MPU environment as a simulation for the product - without having to always deal with the hardware itself. This can speed up the development time, though ultimately when you actually want to see the display running and want to interact with it, it's important to be able to not just have a simulation environment but run on a real hardware platform.
This is where Storyboard excels because regardless of whether you're using an MPU or an MCU, our technology allows you to use a common development model to bridge back and forth between different deployment models. Whether you are deploying to QNX or Linux or Android, or whether you're deploying to a FreeRTOS or a ThreadX type of system, agnostic of the hardware and agnostic of the rendering technology, Storyboard allows you to pick the platform that gives you your development support to quickly iterate change on the embedded UI and then put it into context rapidly.
Answer: Absolutely doable. It’s really going to depend on the technology that you use. Different technologies offer different support. Some technologies find themselves very, very tightly knit to the graphics capabilities that are being offered, whether it's on the MPU side or on the MCU side.
An embedded UI design technology or software, like Storyboard, tends to be more agnostic so that you can develop at arm's length from the processor, the graphics, and the operating system. For example, if you have a product that is an MCU-based product (perhaps it's a low cost variant of your product), less feature rich but you still want to have that rich UI presentation, you might use FreeRTOS and an RT1050 or 1060 to provide that low cost platform. But maybe on a higher-end system where there's more functionality and more integration with other componentry, you might be using a Linux system or QNX system as an operating system base to give you more technology access - alongside an iMX6 or an iMX8. Regardless, the same UI design flows back and forth if you choose the right technology.
Answer: Absolutely. We're not talking about the parity of MCUs to MPUs in all areas. Certainly if you look at a graphic design that tends to be flat, relatively rich in color and graphical assets, that will move across relatively easily. If you're looking at functionality that may be leveraging 3D GPU capabilities that are available on the MPU systems, those functionalities are unlikely to move across to the MCU. So what you're really looking at, is a system where you can design a degradation that matches your MPU and MCU capabilities in a reasonable fashion. Storyboard is one of those softwares where you can degrade gracefully.
Answer: SOMs or System on Modules or Systems on Chips are really an attempt for the MPU configuration to take more of its functionality, and package it up into more of an integrated solution. When I talk about crossover type solutions, a SOM is not an MPU or an MCU but is a packaging story. Companies like Toradex provide readily available modules that package up an MPU, put it together with different flavors of technology in terms of I/O control, etc., so that you can get some of the simpler integrated componentry into your product UI design.
We talked about some of the differences in configurations between MPUs and MCUs. We also discussed how MCUs have been growing their feature set, remaining an integrated platform but increasing their features in areas that embedded user interfaces are really interested in; memory and graphics capabilities to allow us to run rich user interfaces in these configurations.
However, MPUs are not going away - they will be around for a long, long time. Lots of specialized applications require the type of power that MPU processors have. But when you get into singular applications, an MCU can be a great choice of development especially in some of the new integrated platforms where you have all of the capabilities you need to put forward a rich interface experience for your users.
It’s important to note that there are a breed of processors that don't necessarily fit in the MPU category or in the MCU category. MPUs, typically thinking of them as Cortex-A9 class systems, and MCUs, typically thinking about them as Cortex RMM class type systems. But if we're using integration as the differentiation, there's a lot of crossover components that sit in this middle space. These spaces become an interesting opportunity for embedded user interfaces.
For more Embedded GUI Expert Talks like this one, check out our YouTube playlist for on-demand videos and upcoming live dates.