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 started to become murky.
Thomas Fletcher, Co-Founder and VP of R&D, explores the changing landscape in MCU versus MPU capabilities and what you need to consider when evaluating your next embedded project’s hardware options, in this live edition of Embedded UI Talks with Crank.
Hello! Welcome to Crank Software's Embedded UI Live Series. We're good. I am Thomas Fletcher, Vice President of Crank Software, and I'm looking at a live camera in a new configuration. (We made some adjustments for our UI live stream.) Today, I'm going to be talking to you about MPUs and MCUs in the context of embedded UI development and so hopefully this new configuration works out so we can see everything. We'll be working through a few scenarios today where we talk about the roles of MPUs and roles of MCUs in embedded UI development and how that's 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 today and put in the context of embedded UI development.
Examples of microprocessors (MPUs).
Considerations when building an embedded UI on an MPU
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. They are chips that require peripherals that require support from other systems. Just to kind of put it into context, right? 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 where you 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. And this is an important consideration when we think about embedded UI development and what it takes to actually drive the UI. Now Crank Software has been doing embedded UI development for over 10+ years. When we first started, a lot of our products were in this space. Automotive products, IVIs, dashboards, those types of configurations were sitting in the space. Medical devices is another area. Anybody that wanted the rich sophisticated UI was typically using an MPU configuration.
Examples of microcontrollers (MCUs).
Considerations for building embedded UIs on MCUs
On the other side of the coin, we've also seen different types of processor configurations called MCUs. What's an MCU as compared to an MPU? The difference here is the C. It's a controller. It's a microcontroller. It tends to be a much simpler system, a system that tends to be much more integrated. Where an MPU relied on a lot of peripheral support, memory controllers, I/O controllers, potentially 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.
So if we're thinking about the types of boards and configurations especially in the context of embedded UI development in today's world, we're looking at platforms and configurations from ST Micros, things like the STM 37 at F4, F7, H7 class processors; from NXP, the RT series, the 1060s, the 1050s and Microchip; Microchip has a lot of different controllers such as a PIC32 family in particular, something where they're playing a role in embedded UI families. So these types of configurations are much simpler and much more single-purpose. What type of applications are using these? Well, they're used for control system configurations. Things where you're doing I/O data collection, a little bit of management. Think HVAC systems, thermostats, oven controllers. Those type 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 because they were fully integrated they frequently didn't have a lot of memory capacity, a lot of resource capacity. You were really looking at 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.
However, if we think about the type of applications that we’re running. If we think about HVAC, or when we think about air conditioning, when we think about control systems, there's been a shift. And so here are two types of products that we might be seeing in the market today that could be using an MCU controller. What's different about these systems? Well, 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 this air filtration system that’s very sophisticated, but also single-purpose - not a general purpose type of application. What's interesting here is this aspect of these products, right?
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, what does that mean? Well, as soon as you start putting a display on it, one of your big requirements is the requirement for memory. And so if we were to take this tiny little display here, it might be a little difficult to see through the Web interaction here, but 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, right? That needs to be available to the system. And 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. So this is why it's typically being the realm of MPUs.
Memory optimization in embedded systems on MCUs
However, what's interesting is that the recent MCU families have started integrating more memory capabilities, and what that's really done is that has opened up the door and brought them a little bit closer to the typical MPU configurations. Now you're seeing MCUs where they're 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 this configuration, as the size of your graphic display grows, the memory requirements grow quite significantly and pretty fast, right? 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. Chop it in half. Bring it 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.
Using MPUs for powerful graphics processing
Now, it's not just about your memory configuration. One of things about an MPU is that they typically are much more powerful processors, running a gigahertz or higher speeds, where MCUs are still powerful in their own right but you'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, what you're looking at is a challenge of how can you fulfill the original objective of what the MCU was supposed to do and at the same time render rich graphics, render a display, render a UI. 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 Micro situation, we frequently see a DMA 2D engine, and that integration is key to allowing an MCU platform to support the graphics, to support that 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-purposed, it’s still very much a focused product device but a simpler configuration overall and with the integration of more memory and advanced graphics rendering capabilities. This makes the MCU really come over and start digging into some of the spaces where we would have typically seen an MPU processor being used. That's the hardware story, right? That's the 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.
Understanding operating system requirements between MCUs and MPUs for embedded systems
On the MCU side, we’re typically seeing a much more real-time executive style operating system, while on the MPU side, we see a much richer operating environment in terms of its model. And 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 will rely on a process model with processes executing independently from one another in a memory-separated space, so that the system can be a little bit 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, right? Being able to support your product in a variety of different flexible considerations, which 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 when you're working in the 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, your graphics component. So, when in a piece where you're likely to be changing it, you're likely to be iterating through changes on a very frequent basis, being able to do that rapidly and being able to iterate over that very quickly with simply a software reset effectively, 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, right? And we all know that UIs change on a very regular basis, right? They are very, very fluid. 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.
What's the difference between a real-time executive (RTOS) and standard operating systems (OS)?
If I compare that working model to what you see with an MCU, where typically you're using a real-time executive type of configuration. What's the difference between a real-time executive and our standard operating systems? 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. What you're doing is that you're assembling the entire system to work together in one system image, one system load. There are techniques that you can use to segment this up or break it up so that your development cycle doesn't have to always involve rebuilding and re-flashing an entire system image. But because of the integrated nature of the MCU configuration, that is typically what you're doing.
How to choose between an MCU or MPU platform for your embedded system
Now, 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 the memory and the flash storage, how much resources do you have available to partition and give to the operating system as overhead, compared to the rest of your application execution. So this is a slower development model, right? Now again, in the context of embedded UI development where a lot of changes happen, because this is a slower development model, you’re maybe having to rebuild the system, flash it down, see it, have to go make changes if it’s not quite right - this tends to be 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 actually always deal with the hardware. This can speed up the development time, but 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 be able to 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.
We talked a little bit about the difference in configurations between MPUs and MCUs. And we talked a little bit about how MCUs have been growing their feature set, remaining an integrated platform but growing their features in particular 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. MPUs are not going away. They are here certainly for a long, long time. Lots of specialized applications require the type of power those MPU processors have. But when you get into singular applications, an MCU can be a great choice of development especially in some of these new integrated platforms, where you've got all the capabilities you need to put forward a rich user interface.
There are a breed of processors that don't necessarily fit in the MPU category or in the MCU category, right? 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. And a lot of interesting opportunities for embedded user interfaces.
Hopefully, you found this session interesting and engaging, and you learn a little bit about MPUs and MCUs and how they have been changing over time to further support embedded user interface development.
How easy is it to move from one type of platform to the other when building a UI, say if your embedded product needs changes?
Answer: Absolutely doable. It really is going to depend a little bit on the technology that you use. Different technologies offer different support. Some technologies find themselves very, very tightly to the graphics capabilities that are being offered, whether it's on the MPU side or on the MCU side.
A technology or software, like Storyboard, tends to be a little bit more agnostic so that you can develop at arm's length from both the processor, the graphics, and the operating system. So if you have a product, for example, 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 UI presentation, that rich presentation, you might use FreeRTOS, and you might use an RT1050 or 1060 to provide that low cost platform. But maybe on a higher-end system where there's more functionality, 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. And you might be using something like an iMX6 or an iMX8. The same UI design flows back and forth if you choose the right technology.
Will there be any functionality lost if I scale up to an MPU or down to an MCU?
Answer: Absolutely. We're not talking about parity of MCUs to MPUs in all areas. Certainly if you look at a graphic design that tends to be flat, relatively rich; rich in color, rich in 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.
What about SOMs?
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 a bit more of an integrated solution. So when I talk about crossover type solutions, well a SOM is not 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 and what not, so that you could get some of the simpler integrated componentry into your product design.Looks like there's no more questions! Again, I'm Thomas Fletcher. Thank you very much for attending our Embedded UI Live Session today. Hopefully you learned a little bit about graphics, MPUs, MCUs and the integration that happens for embedded UIs in those spaces. I look forward to seeing you in another couple of weeks for our next session and until then be safe!