This topic provides you the necessary information about STM's STM32F769I discovery kit.

Board features

• STM32F769NIH6 MCU (ARM Cortex-M7)
• 4” capacitive touch LCD display (800x480)
• 512+16+4 Kbytes of RAM
• 128-Mbit SDRAM
• 2 MB Flash memory
• 512-Mbit Quad-SPI NOR Flash memory

More information fromSTM32F769I Discovery Website

Supported color depths

The reference port for this board supports 32bpp color depth. The board also supports 16bpp and 24bpp, but they are not implemented in the reference port. See QUL_COLOR_DEPTH and Color depth for more information.

Partial framebuffer support

This board supports the partial framebuffer strategy. To enable it, set QUL_PLATFORM_PARTIAL_FRAMEBUFFER and rebuild the Platform library.

Using the partial framebuffer can significantly lower the memory requirements of an application, but can lead to reduced performance and potential visual tearing artifacts for complex applications.

Tearing

A finished frame is sent to the display by hardware that reads it out of SDRAM. If the application is still drawing while that read runs, the two compete for the bus and part of the screen can end up showing the previous frame. That happens only when an application takes longer to draw a frame than the display takes to refresh; a faster application is made to wait for the read to finish, so nothing competes with it.

What decides it is how much traffic the application puts on SDRAM while a frame is going out, not the overlap itself. The renderer reads the font engine's glyph cache and the glyph layout cache for every glyph it draws, so moving those two out of SDRAM is usually enough on its own:

• Place the glyph caches in internal memory. The two the renderer reads for every glyph are the SparkCache and GlyphLayoutCache allocation types. A port can serve those from internal memory rather than SDRAM; see Memory allocation in Qt Quick Ultralite platform abstraction. This removes the contention and costs no frame rate, so try it first.
• Wait for the transfer instead. If the board has no internal memory to spare, or the traffic is not the glyph caches, Stm32F7::Configuration::setDelayDrawingDuringDsiFlush(true) withholds the back buffer until the previous frame has been sent. A frame then costs the drawing plus the transfer rather than whichever of the two is longer.

The second is a board specific API. To use it, link Qul::PlatformStm32F7Extras to your project:

#include <stm32f7extras/stm32f7configuration.h>

Stm32F7::Configuration::setDelayDrawingDuringDsiFlush(true);

It can be called at any time, so an application that only needs it on certain screens can set it as the screen changes.

Measured on this board with a full screen of scrolling Tamil: with the glyph caches in SDRAM it draws at 47 fps and tears; with them in internal memory, 50 fps and clean. Waiting for the transfer instead takes the same case to 32 fps. An application that already repaints within the refresh period needs neither - it is made to wait anyway and cannot tear.

Reading debug messages

By default, the output of qul_printf and Qul::PlatformInterface::log calls are redirected to STLink virtual COM Port, which is exposed on the host machine via USB. The serial configuration is the following:

   Baud rate: 115200
   Data bits: 8
   Stop bits: 1
      Parity: None
Flow control: None

Hardware acceleration

The reference port utilizes the STMicroelectronics Chrom-Art Accelerator (DMA2D) for hardware accelerated graphics.

DMA2D is a specialized direct memory access (DMA) accelerator dedicated to image manipulation. It can perform the following operations:

• Fill an image with a specific color.
• Copy a source image into a destination image.
• Copy a source image into a destination image with a pixel format conversion.
• Blend two complete source images with a different pixel formats and copy the result into a destination image with pixel format conversion.

All of the listed operations can be done for a part or whole image.

For more information, refer to STMicroelectronics' documentation:

• STM32F7 - Chrom-ART
• RM0410 Reference manual section Chrom-Art Accelerator controller (DMA2D).

Monotype data tables in QSPI

The reference linker scripts place the Monotype data tables in external Quad Serial Peripheral Interface (QSPI) flash, as explained in Placing Monotype data tables in external flash.

In the Qt Quick Ultralite Thermostat Demo, Qul::validateMonotypeDataTableChecksums() is called to validate the data tables. It is up to the application to decide whether to keep these data tables in internal or external flash, and whether to perform data validation.

Hardware configuration

STM32CubeMX

The hardware configuration for the STM32f769I-DISCOVERY board is comprised of STM32CubeMX generated code and peripheral BSP drivers from the STM32Cube MCU Package for STM32F7 series repository.

All the STM32CubeMX generated code (except the system clock configuration) is located in the stm32f769i-discovery-common/3rdparty/Core folder. The folder includes configurations for:

• GPIO - gpio.c
• UART - uart.c
• System timer - stm32f7xx_hal_timebase_tim.c
• Interrupt routines - stm32f7xx_it.c

System clock configuration

The system clock configuration is located in Qt Quick Ultralite platform source file stm32f769i-discovery-common/platform_clock.cpp. The SystemClock_Config() function is declared weak, so that it can be overridden by a custom clock configuration.

System tick timer

The TIM6 timer instance is used as the systick timer. The initialization function is located in the STM32CubeMX generated source file stm32f769i-discovery-common/3rdparty/Core/Src/stm32f7xx_hal_timebase_tim.c.

Interrupt handlers

The interrupt handlers are located in Qt Quick Ultralite platform source file stm32f769i-discovery-common/3rdparty/Core/Src/stm32f7xx_it.c. Also, the display related DSI interrupt callbacks and touch interrupt pin callback are present in Qt Quick Ultralite platform source file stm32f769i-discovery-common/platform_irq.cpp.

Quad serial peripheral interface (QSPI)

For the QSPI configuration, check BSP_QSPI_Init() for peripheral settings and BSP_QSPI_MspInit() for pinout/clock configuration from the Drivers/BSP/STM32F769I-Discovery/stm32f769i_discovery_qspi.c file of STM32Cube MCU package repository.

SDRAM

The SDRAM configuration is located in the STM32Cube MCU package repository file Drivers/BSP/STM32F769I-Discovery/stm32f769i_discovery_sdram.c.

Touch panel

The I2C1 hardware instance is used as a communication interface for the touch controller IC. The I2C configuration for the touch panel IC is located in the STM32Cube MCU package repository path (Drivers/BSP/STM32F769I-Discovery/stm32f769i_discovery.c). The I2Cx_Init() function contains the required configurations for I2C.

Display

You can find the display configurations (LTDC and DSI interface configuration) in Qt Quick Ultralite platform source file stm32f769i-discovery-common/platform_display.cpp. For more information on the display configurations, see the initializeLcdPeripherals() function.

The clock settings for LTDC are given by the setLcdClockConfiguration() function, while the DSI clock configurations are given by the setDsiPllConfiguration() function. The BSP_LCD_MspInit() function, located in the STM32Cube MCU package repository file Drivers/BSP/STM32F769I-Discovery/stm32f769i_discovery_lcd.c, contains the general purpose input/output (GPIO) as well as the interrupts and exceptions (NVIC) settings for the LTDC, DMA2D and DSI interfaces.

Random number generator (RNG)

You can find the RNG peripheral initialization in Qt Quick Ultralite platform source file platform/boards/st/common/platform_rng.cpp.

USART

The USART1 hardware instance is used for logs over the virtual COM port. You can find the peripheral configuration in Qt Quick Ultralite platform source file stm32f769i-discovery-common/3rdparty/Core/Src/uart.c. The clock settings are defined in the SystemClock_Config() function of the Qt Quick Ultralite platform source file stm32f769i-discovery-common/platform_clock.cpp.

Platform specific APIs

Some configuration is specific to this board and is not part of the portable API. To use it, link Qul::PlatformStm32F7Extras to your project.

The following APIs are available through the extras module:

Known issues or limitations

Due to limited SDRAM bandwidth, accessing SDRAM with the CPU may cause visual artifacts while the framebuffer is being scanned by the display controller, due to LTDC FIFO Underrun. LTDC FIFO Underrun error may occur in applications that have a lot of UI elements and heavy animations, causing visual glitches. Apart from simplifying the UI, consider using a different build type for the Qt Quick Ultralite core library. For example, Debug or Release instead of MinSizeRel.

RLE decompression

The CPU on this board cannot blend compressed images directly onto the framebuffer in SDRAM. Such images are decompressed into intermediate buffers of a limited size, before blending them using DMA2D onto the framebuffer in SDRAM. This approach has a significant performance overhead to blend RLE-compressed images compared to the uncompressed images.

Performance can be improved to some degree by increasing the size of qul_scratch_buffer in platform_stm32.cpp, at the cost of more RAM usage.