Who would have thought high-end UIs on embedded systems would encounter this new challenge? While microcontrollers are resource-constrained, they are no longer the limiting factor they once were, and engineers are no longer obliged to use a more expensive MPU as MCUs embed powerful GPUs. Instead, it’s the memory configuration that developers have to contend with when drawing their designs and developing their interfaces. The problem is that it’s easy to overlook the amount of RAM and flash in the microcontroller, only to realize too late in the development process that there’s not enough or too much memory. The former makes programming vastly more difficult, if not impossible, while the latter is a severe waste of resources.
UIs on embedded systems: A shift in constraints
Looking at the microcontrollers with an embedded GPU that ST has launched during the past couple of years, there’s one clear trend: their graphics capabilities boomed. One reason is the advent of significantly more powerful and efficient IPs like NeoChrom GPU, which makes UIs accessible to more products and markets. The STM32U599 was the first MCU to get the NeoChrom GPU, and the STM32U5F9 and STM32U5G9 inaugurated NeoChromVG GPU, the first IP on STM32 to accelerate vector graphics. Similarly, the 600 MHz STM32H7R/S became the first STM32 with a boot flash while also offering a NeoChrom GPU.
Hence, the question is no longer what is the one MCU that can run a high-end UI since new GPUs have opened up this possibility to many of them, but what memory configuration works best? Developers must account for the code and data storage. They must also determine where to place frame buffers, assets, and more. Indeed, a team may decide to store graphical resources on external memory, only to realize that the interface doesn’t have enough bandwidth to offer a smooth experience. Conversely, integrators may use an MCU with lots of embedded flash only to realize it would never be enough, leading to external memory modules and wasting the available storage on the microcontroller.
Taking a step back, we can see three major memory configurations:
- Lots of embedded flash (4 MB) and lots of embedded RAM (3 MB)
- No embedded flash and lots of embedded RAM (4.2 MB)
- Little of both (64 KB to 128 KB of flash and about 500 KB of RAM)
Let us explore what UIs would benefit from each of these three configurations and which STM32 device would work best.
Lots of embedded flash and lots of embedded RAM
According to a forecast by Transforma Insights, HVAC-connected systems, meaning they access the Internet and potentially feature a display, should reach nearly 750 million units by 2033. As buildings optimize their energy consumption, smart HVAC devices need a control unit with a display to more easily monitor energy consumption and program temperature profiles. Often, these screens use a resolution between 480 x 480 to 800 x 480, which is enough unless makers target very high-end markets. Assets also tend to use a 16-bit color depth, and while animations must be smooth, they are not overly complicated. Most want a very fast UI to bring all the information and product features to their users’ fingertips.
In this particular use case, the frame buffer fits in 3 MB of SRAM or less, and an MCU with a large enough embedded flash means engineers can do away with external modules since the MCU can store all the graphical assets. The STM32U5G9 and STM32U5F9 are thus very popular thanks to their 3 MB of RAM and 2 MB to 4 MB of flash storage. A more prominent display resolution will require external flash modules, but the octo SPI interface of the STM32U5 will be more than enough to fetch the assets. However, in many HVAC systems, the latest STM32U5 devices enable a single-chip design while providing ultra-low power modes that are mandatory for battery-powered GUIs.
No embedded flash and lots of embedded RAM
Another application that is gaining tremendous ground on embedded systems is AI at the edge. A GUI is a must because it communicates the decision taken or inference obtained after running the neural network algorithm. For example, in computer vision applications, the user must know what the system recognizes, and the most straightforward way to do it is with a GUI. The problem is that neural networks need a lot of RAM, so accommodating a frame buffer becomes trickier. That’s why the system will use a lot of external NAND or NOR flash to accommodate the machine learning algorithm, the system, the GUI, and other applications. Consequently, engineers always use a large external flash and search for voluminous embedded RAM.
That’s why the STM32N6 offers 4.2 MB of embedded RAM, the largest ever on an STM32, and no flash. Since developers will use external storage modules for the application and data, ST chose to save die space for other functionalities like the NeoChrom GPU as well as H.264 encoding and JPEG encoding and decoding, among other things. The STM32N6 can thus replace MPUs in applications like security panels for cameras. The RAM on the STM32N6 thus enables developers to easily add a frame buffer for a 1280 x 720 display while the MCU’s fast memory interfaces can fetch assets and from Quad / Octo SPI flash or from NAND and with assets caching in external RAM without creating a bottleneck.
As a result, it makes GUIs more accessible on systems dedicated to AI at the edge, but it also creates a new opportunity for those who don’t have AI in mind but still require a lot of embedded RAM. That’s why we are offering a version of the STM32N6 without an NPU. ST is ensuring that even those who don’t need an NPU can enjoy this new type of memory configuration, store their frame buffer in the available memory, and vastly simplify their designs. For integrators, not having to add external RAM modules means a simplification of the PCB layout and a potential reduction in development time.
Little of both
UIs on high-end embedded systems
Many high-end embedded systems rely solely on external RAM and external flash. Gaming accessories and peripherals, for instance, will never have enough embedded RAMs or embedded flash and must, therefore, use external components. Because of the qualitative nature of these applications, the GUI needs more space to store assets. The double frame buffer alone on a 1024 x 600 display with 24 bits per pixel color depth would take about 3.6 MB. Another example is a home automation gateway, which must run the graphical interface, communication protocols, and security features. Instead of an MCU with lots of embedded RAM and flash, engineers prefer a more cost-effective MCU and allocate the BoM to external features like memory.
To better serve these applications, we launched the STM32H7R7/S7, the first STM32 with 64 KB of boot flash and 620 KB of RAM. The STM32H7R7/7S7 come with a NeoChrom GPU to accelerate bilinear interpolation and any angle texture mapping, freeing their Cortex-M7 to perform other tasks. Additionally, they also come with a 200 MHz 16-bit high-speed serial peripheral interface (XSPI), an 8-bit octal serial peripheral interface (OSPI), and Quad SPI Flash interfaces to rapidly fetch assets from the external memory modules and deliver them straight to the system cache, thus avoiding bottlenecks. Developers can also rely on a flexible memory controller interface to connect a fast 16/32-bit SDRAM.
Other physical and software considerations
Many other factors can seriously impact the creation and performance of a UI. For instance, choosing a package size with too few pins may have regrettable consequences, such as being forced to use a slower memory interface. If integrators only focus on the unit price, they may box their engineers in a very tight and compromising corner. Similarly, adding external RAM can help with scalability but may prove slower than embedded RAM. However, today, thanks to new GPUs like NeoChrom, it’s possible to rely on much more cost-effective MCUs as long as a team chooses the right memory configuration, thus enabling GUIs on many more products.
Additionally, another aspect of development that has a tremendous impact on memory utilization is the graphical framework. For instance, [TouchGFX, our free framework that comes with a Designer, a Simulator, and a code generator], offers numerous memory optimization schemes to help reduce the amount of RAM and flash needed. For instance, ST recently introduced new compression algorithms and support for vector fonts and graphics to save storage space. Similarly, rotation, zoom effects, videos, or support for multiple languages are optimized, and the availability of board support packages means that developers can very quickly test each MCU to see how they behave. Put simply, GUI development on MCUs is no longer the dark art it used to be.
