Skip to main content

Display

The Display group contains configurations related to display, such as interface, dimensions and buffering strategies.

TouchGFX Generator Display settings

Interface and dimensions​

Multiple display interfaces are usable today with STM32 microcontrollers, e.g.:

  • Parallel RGB (LTDC)
  • MIPI DSI
  • FMC
  • SPI

In the case of MCUs with a display connected to an LTDC or FMC TouchGFX Generator can generate code to transfer the framebuffer to the connected display. For DSI and SPI interfaces drivers must be implemented by developers themselves.

Further reading
See section Scenarios for concrete examples of code for different display interfaces.

Framebuffer Pixel Format​

The following framebuffer pixel formats are currently supported by TouchGFX Generator. All options are available when using "Custom" display interface, otherwise options are restricted to display controller settings (e.g. configuring the LTDC Framebuffer format to "RGB565" will limit the options to "RGB565" in TouchGFX Generator).

  1. BW (1bpp)
  2. Grey2 (2bpp)
  3. Grey4 (4bpp)
  4. ABRG2222 (8bpp)
  5. ARGB2222 (8bpp)
  6. BGRA2222 (8bpp)
  7. RGBA2222 (8bpp)
  8. RGB565 (16bpp)
  9. RGB888 (24bpp)
  10. ARGB8888 (32bpp)
  11. XRGB8888 (32bpp)
Note
Some pixel formats have no- or only partial ChromART (DMA2D) support.

Buffering Strategies & Location​

The following frame buffer strategies can be configured through TouchGFX generator:

  • Single Buffer - Use only one application frame buffer. Possibly limits performance but uses less memory. Can be used with the "Buffer Location" configuration to place it in internal RAM. For further optimization the user can define a function that returns the current line being processed by the display controller. This method is used by the framework to allow updates to memory that has already been transferred to the display during this frame.
  • Double Buffer - Use two frame buffers. Usually allows for better performance at the cost of memory.
  • Partial Buffer - Use one or more user defined chunks of memory as the frame buffer. This strategy is targeted at low cost solutions that do not rely on external RAM, but have displays for which a full frame buffer would exceed available memory.

In the case of Single Buffer and Double Buffer users are allowed to configure their location through the "Buffer Location" configuration which offers the following options:

  • By Allocation - Lets the linker place frame buffer memory according to linker script. Default is in internal RAM.
  • By Address - Allows the user to define one (Single) or two (Double) frame buffer addresses.

The Partial Buffer strategy allows the user to define the following parameters:

  • Number of blocks (always placed in internal RAM)
  • Block size (bytes)

To understand some core concepts regarding the Partial Buffer strategy please read the dedicated article on Lowering Memory requirements using partial Frame Buffers. The article shows, conceptually, how to achieve partial frame buffers and the code shown in this article will differ slightly from what is generated by TouchGFX Generator. Please see Frame Buffer Strategies for concrete examples of the generated code for these strategies.

Caution
For STM32F7/H7: If the framebuffer is placed in Write Through cached memory (e.g. SRAM) then the DCache is flushed by the generated code prior to DMA2D (if configured in the Generator) accessing it. Remember to enable CPU Cache in the System Core settings for Cortex M7 in STM32CubeMX in order for this caching mechanic to work.
Further reading
See the Cache on F7 and H7 subsection for more information about CPU caching.