As of version 4.5.0, TouchGFX supports 24bpp mode (RGB888, RGB666) for both software (framebuffer and visual elements) and hardware (DMA transfers). This improves the visual quality of applications, but consumes more memory and applies more strain on the processor.
For a general discussion of 16 vs 24 bpp frame buffers, please refer to this article.
Concretely, you will need to make a few adjustments in order to switch to 24bpp mode, depending on whether or not you're using board packages supplied by TouchGFX or if you're using your own hardware configuration:
- Configure TouchGFX to generate 24bpp output in the image conversion
- Configure your TouchGFX application to run in 24bpp mode
- Configure your hardware (TFT controller) to run in 24bpp mode
Please check the supported section below to figure out if the MCU you're using supports 24bpp.
At the moment, TouchGFX does not allow you to switch between 16bpp and 24bpp formats at runtime.
Supported MCUs and Boards
TouchGFX offers 24bpp support for the following MCUs:
- ST STM32F4 (STM32F429 / STM32F469)
- ST STM32F7 (STM32F746 / STM32F756)
This means that you can see 24-bit in action for all ST boards available in the TouchGFX distribution by following the simple configuration guide in the sections below:
- STM32F746G-DISCO / STM32756G-EVAL
- STM32469I-DISCO / STM32469I-EVAL
- STM32F429I-DISCO / STM324x9I-EVAL
In TouchGFX, the high byte of a 32-bit aligned word in the framebuffers memory region contains the first color channel of the next pixel ("packed" format). Since the TFT controller (ARM Primecell PL111) on the NXP LPCxx series does not support a 24-bit packed framebuffer format, TouchGFX does not currently offer 24-bit support (RGB888) for NXP MCU's.
Image Converter output
As mentioned earlier, the TouchGFX image converter must be configured to output data in 24bpp format. This is done by changing the options of the configuration file for your application (placed under the "config") of your application. This step is described in detail in this article
In order to configure your TouchGFX application for running in 24bpp mode, you need to declare an object of type LCD24bpp instead of LCD16bpp in your BoardConfiguration (and in simulator/main.cpp for simulator).
In our standard examples, and standard BoardConfigurations, this code is already there, toggle by a #define flag. Therefore you do not actually need to change the code, but merely make sure that you compile with a compiler definition of
If you added this to your configuration file when changing image converter output, then this setting is already in effect when compiling with MSVS or gcc (both simulator and target). If, however, you use IAR, Keil or a different toolchain to compile, you must manually add a USE_BPP=24 compiler flag in your project.
The last thing to do is have your TFT controller operate in 24BPP mode instead of 16BPP. Again, this is already done for all the standard ports for STM32-based boards, controlled via the same USE_BPP definition from before. So if you are using our standard board, you do not need to do anything here.
If you have your own BoardConfiguration/port then you must manually adjust the TFT initialization code to run in 24BPP mode. Look in the standard ports for inspiration.
- Frame buffers take up more memory in 24BPP configuration. So if your code uses the SDRAM for other things, make sure you account for the increased frame buffer sizes. One frame buffer in 24BPP takes up width*height*3 bytes.
The depth of the framebuffer along with image formats, setup of LCD and DMA controllers, must all be aligned. To catch faulty configurations, the TouchGFX framework asserts as early as possible that the format of images correspond to the bit depth of the framebuffer. Some IDE's, such as IAR, will display an assert poup.
This assert naturally won't catch errors in hardware setup if you've got your own hardware configuration.
Version 4.5.0 of TouchGFX introduced a new class,
touchgfx::colortype, that allows more seamless switching between 16 and 24 bit color depth. Due to the nature of
colortype, it is not possible to assign a value to a
Color::getColorFrom24BitRGB() before bit-depth has been configured through HAL initialization.
I.e. for red:
The following table contains some examples of render time penality, in %, by changing from 16bpp to 24bpp in our 2015 demo for certain screens: "Bird Eat Coin" game (measured with no coins or bullets), the front page selection carousel and the 3-way progress bar in the "custom controls" section and the product info page.
|Bird Eat Coin||Carousel||Product Info||Custom Controls|