TouchGFX has framebuffer w 16 bit depth but uses 18 pins for RGB on STM32F429-DISCO?

[CNach]

I could use some clarification about how TouchGFX sets up the the RGB interface/color depth for this board.

In BoardConfiguration.cpp, the frame buffer is set up for 16 bit color depth by default and is forced when using the single frame buffer (I am using the SINGLE_FRAME_BUFFER_INTERNAL option and have removed the external SDRAM chip).

In LCD_LayerDefaultInit(), Layercfg.PixelFormat is set to LTDC_PIXEL_FORMAT_RGB565 if using 16bpp and LTDC_PIXEL_FORMAT_RGB888 if using 24bpp.

However, the RGB interface is wired such that R2-7,G2-7, and B2-7 are used for a total of 18 bits (RGB666). I want to use the Displaytech DT018ATFT display (datasheet: https://www.mouser.com/datasheet/2/116/DT018ATFT-v10-221368.pdf) , which supports both the 16 and 18 bit RGB interface. How are the RGB channels handled in 16 bit color mode and are there any special changes that should be considered for initializing the new display?

[Martin KJELDSEN]

Hi @CNach​,

It's true that TouchGFX only supports 16- and not 18-bit framebuffers. When you say you're forced to use RGB565 in SINGLE_FARME_BUFFER_INTERNAL mode you're talking about CubeMX?

There are no special changes required other than making sure your image formats, framebuffer depth and screen configuration match.

[CNach]

Hi Martin,

Perhaps "forced" isn't the right word. I am using a project generated by TouchGFX and not CubeMX (using the template for the STM32F429I-DISCO board). The BoardConfiguration.cpp file generated by TouchGFX is configurable with some macros that changes several things.

• There is a #define for SINGLE_FRAME_BUFFER_INTERNAL, which by default is commented out and changes several things to allow TouchGFX to run without the external SDRAM chip (like how frameBuf0 is defined to use either the start of SDRAM or gets the address of a global variable).
• There are macro logic statements in touchgfx_init() that will raise an error saying "Single frame buffer in internal is only possible in 16bpp due to memory constraints." if SINGLE_FRAME_BUFFER_INTERNAL is defined and the macro USE_BPP==24, so it needs to be set to 16.
• In LCD_LayerDefaultInit(), Layercfg.PixelFormat is set to LTDC_PIXEL_FORMAT_RGB565 if USE_BPP==16

This all makes sense to me so far. The part that I'm not following is this:

• In LCD_MspInit(), the GPIO pins for R2-7, G2-7, and B2-7 are all configured to be used by the LTDC, which is a total of 18 bits (RGB666)

I've confirmed with an oscilloscope that R2 is indeed being driven by the LTDC (not always zero). How is the data mapped from a 16 bit color depth in the framebuffer to an 18 bit output on the TFT-LCD controller?

[Martin KJELDSEN]

Hi @CNach​,

LTDC controller pins are configured by the user application, as you mention. TouchGFX does nothing actively to address this outside of rendering screens to the framebuffer according to the LCD class selected (e.g. LCD16).

It doesn't surprise me that all the pins are used. The LTDC is probably just reusing bits or throwing them away. It also offers dithering, i think.

When outputting 24-bit framebuffer data to an 18-bit screen TouchGFX can dither images (RGB666) for you.

Does that make sense?

Best regards,

Martin