Our free graphical user interface, TouchGFX, is now getting an important update to its engine and designer tool. TouchGFX 4.12 brings to the public, among other things, cacheable containers, partial framebuffers, and our L8 graphical compression format, all of which will improve performances on more STM32 microcontrollers. As embedded systems continue to penetrate mainstream markets, the presence of a display and ipso facto a graphical user interface can drastically improve consumers’ experience. It explains why reports show that more and more embedded systems engineers now work on GUIs and why the industry tries to fit them on MCUs with tighter computational throughput. TouchGFX Designer is our Desktop tool that facilitates the development of GUIs for MCUs by helping developers take advantage of the TouchGFX Engine faster, reducing the need to write C++ code.
TouchGFX 4.12 is also highly symbolic because it’s the first major upgrade since we acquired the solution in 2018, and it became an integral part of our STM32 ecosystem. One of the driving philosophies behind our MCUs is that they offer the best performance and the most extensive feature-set, regardless of the tools or solutions engineers want to use. It’s why we are glad to also work other GUI solutions like Qt and recently participated in a seminar that assisted developers who wanted to use the famous toolkit on our microcontrollers. However, we are thrilled to bring meaningful updates to TouchGFX and we will continue to work on our solution because it gives any professional or enthusiasts a free and powerful tool that is currently adopted by smartwatch manufacturers and home appliance makers, to only name two, thus bringing an industry powerhouse to all STM32 developers.
CacheableContainers: Rethinking How to Render a Frame
CacheableContainer is a technology that our TouchGFX team started developing for various customers before making it available to the public. As the name implies, it uses a bitmap cache to significantly accelerate graphical performance and enable a higher frame rate for smoother transitions by massively optimizing performances. The video below shows a demo running on an STM32F429I Discovery kit. Without the CacheableContainer technology, the simple full-screen (240×320) slide animation runs at nine frames per second. With the new TouchGFX technology active, the system reaches 60 frames per second for a much smoother transition. Some smartwatches currently use this feature to ensure a more seamless user experience despite the significant hardware limitations inherent to their form factor and the need for more battery life. It maximizes performance when trying to animate complex widgets, such as texture mappers, or small dynamic elements displayed in front of a static background.
In a traditional system, an animation demands that the system redraw every frame, which can get computationally expensive. In the animation between screen 1 and screen 2, which requires about 20 frames, redrawing each frame takes about 100 milliseconds. CacheableContainer bypasses this problem by storing the first and last frames in a separate container in the form of a bitmap that the system keeps in the RAM. Instead of computing the animation, the system retrieves the two images from memory using DMA and shows them at different places thanks to a simple DynamicBitmap method. The MCU no longer has to render every frame, thus significantly optimizing performance. Developers only need to tick the
Cacheable box in TouchGFX Designer, select the location in memory of the containers they want to cache and call them when needed. With this technique, the render time drops from 100 ms to 5 ms.
Partial Framebuffer: Optimizing How to Store a Frame
Partial Framebuffer is another technology that we developed for customers and is now bringing to the public after witnessing its tremendous results. A framebuffer is a contiguous memory space that stores a representation of each of the pixels that will appear on display. For example, a standard 24-bit 390 x 390 image for a smartwatch display demands a framebuffer of 3,650,400 bits or 440 KB (), which is almost 70% of the SRAM available on the STM32L4+ that excels on smartwatches and wearables. And this number can explode if an application requires two or three frame buffers, thus doubling or tripling the memory requirement. Beyond the capacity limitations, a large framebuffer takes longer to fetch as more data must travel from the memory to the display, which slows down performances.
As the name indicates, a Partial Framebuffer only stores a portion of the framebuffer, which reduces its size in memory by an average of 10. Developers can configure its size according to the section of the screen that will actually change and then store multiple partial framebuffers. The TouchGFX Engine will then choose the appropriate one and send it to the display. Hence, instead of having to fetch an entire buffer, the system uses much smaller files, which increases the overall performance. The technology works best with short animations, like clocks or a graph that builds itself over time. It also demands that the screen use an embedded controller as it will directly receive the partial framebuffer from the MCU’s RAM, thus bypassing the Flash to increase performance further. The technology works on both Parallel / 8080, DSI and SPI displays.
L8 Compression Format and TouchGFX Designer: Optimizing Assets and Workflow
Graphical assets take a lot of space in memory, and until now, the only thing developers could do was reduce the level of detail to shrink their file size. Unfortunately, it also meant delivering a less compelling graphical user interface. L8 is unique because it can significantly compress an image file by taking advantage of the ChromART accelerator present in STM32 microcontrollers. As long as an asset uses a maximum of 256 colors, which is very often the case for backgrounds, icons, or buttons on small embedded devices, developers can choose to compress an asset using the L8 format by merely ticking a box in TouchGFX Designer. The system generates an image that is up to 75% smaller, and the decompression phase is computationally efficient as it uses the ChromART engine to lookup various colors in a table and decompresses the asset without loss of quality.
TouchGFX Designer also got some exciting updates. On top of making these new features more accessible, the new tool offers new widgets, such as an analog and digital clock, or a texture mapper, which means that developers can start creating their mapping program with a simple drag and drop. They will still need to enter their C++ code, but it will make the whole process a lot smoother. Similarly, the tool also supports the addition of custom triggers and actions to enable engineers to experiment and test them even if they don’t have the programming skills necessary to dive into the source code. Finally, TouchGFX Designer is now able to generate and load the system twice as fast and to only do it upon request, rather than automatically, which could slow a developer’s workflow.