Exploring Porting Qt for MCUs onto STM32H747I-DISCO

Visit Our Proficiency with QT for MCU’s platform porting Click here.

Qt, a highly embraced C++ framework, is employed extensively for crafting applications that run seamlessly across various platforms. The Qt for MCUs (Microcontroller Unit) extension broadens the framework’s functionality to cater to microcontroller-driven systems. This platform furnishes developers with powerful instruments to construct graphical user interfaces (GUIs) and applications within the limitations of resource-constrained microcontroller environments.

Through the integration of Qt onto the STM32 board, developers can exploit the vast libraries and functionalities of the Qt framework, facilitating the development of contemporary, visually captivating, and user-friendly applications tailored for their embedded systems.

Although there isn’t a standard port for the ST board (STM32H747I) in Qt for MCUs. Thanks to Crossware, they recognized this gap and took the initiative to port the Qt for MCUs graphics stack onto it. Our blog delve into the process of porting Qt for MCUs onto the STM32H747I-DISCO board, exploring the challenges, solutions, and insights gained along the way.

Porting Procedure

To kickstart the porting process, we opted for Ubuntu (Ubuntu 22.04.3 LTS) as our host environment, which, following the guidelines outlined in the Qt documentation, turned out to be a seamless endeavor.

Within the platform/boards/st/ directory, we established stm32h747i-discovery-baremetal to house board-specific configurations and files. To configure the platform, we prepared a cmake folder under the platform directory, from which the pivotal files were generated:

• BoardArchitectureConfig.cmake: Specifies the architecture of the board including details such as the CPU type, clock configuration, memory layout, and other relevant settings.
• BSPConfig.cmake: This file delineates the configuration for the Board Support Package (BSP), encompassing drivers, libraries, middleware, and other essential components required for the board’s functionality.
• LinkerScriptConfig.cmake: This file dictates the linker script, which orchestrates the placement of code and data within the memory of the microcontroller, ensuring efficient utilization of resources and proper functioning of the application.
• platform.cmake: This file is responsible for configuring additional settings crucial for the compilation process, including compiler flags, directories for including header files, and other necessary parameters to tailor the build environment according to the requirements of the platform.

In the cmake subdirectory, a vital component was the linker script file, like stm32h747i-cm7.ld provided by ST. To initialize Qt for MCU on the designated platform, platform-specific code was developed within the platform directory. Essential files comprised:

• platform_init.cpp: This file is responsible for configuring the hardware of the platform, encompassing tasks such as setting up clocks, caches, and peripherals, ensuring the proper initialization of the underlying hardware components required for the operation of the system.
• platform_clock.cpp: This file is dedicated to supplying the system clock and tick timer functionalities tailored specifically for Qt for MCU, ensuring accurate timing operations and synchronization within the system.
• platform_cache.cpp: Within this file, cache operations are managed specifically for Qt for MCU, ensuring efficient memory management and optimization for enhanced performance in microcontroller-based environments.
• platform_display.cpp: This file is responsible for setting up and controlling the display interface specifically designed for Qt for MCU, ensuring seamless integration and proper functionality of graphical user interfaces (GUIs) on microcontroller-based systems.
• platform_drawing.cpp: Within this file, low-level drawing functions tailored for Qt for MCU are implemented, encompassing tasks such as filling, drawing, and blitting, essential for rendering graphical elements efficiently on microcontroller-based systems.
• platform_irq.cpp: This file manages interrupts specifically for Qt for MCU, handling tasks such as touch and display interrupts, ensuring seamless interaction and responsiveness within the graphical user interface on microcontroller-based systems.
• platform_touch.cpp: This file is dedicated to configuring and reading touch input specifically tailored for Qt for MCU, ensuring accurate detection and handling of touch events within the graphical user interface on microcontroller-based systems.

Challenges in Porting

Throughout the porting procedure, we faced challenges concerning the configuration of the Linker Script. Specifically, the linker script demanded the allocation of distinct memory regions for Qt-associated resources, requiring the allocation of some to QSPI-based flash memory and others to External SDRAM. To overcome this hurdle, we meticulously mapped Qt resources and managed heap allocation, facilitating the integration of all Qt-related resources into the linker script as needed.

Key factors addressed within the linker script encompassed:

• QulFontResourceData: Allocated in QSPI.
• QulModuleResourceData: Allocated in SDRAM with an offset to QSPI.
• QulResourceData: Allocated in QSPI.
• heap (COPY): Located in SDRAM_HEAP.

One of the primary hurdles we faced was related to the LCD:

• Initialization of the LCD and adjustment of its configurations
• Oversight of the LCD data buffer to maintain its integrity
• Execution of error-free read and write operations via DSI
• Seamless integration of LCD functionality into the QT for MCU framework

Qt Quick Ultralite facilitates the development of code tailored for embedded devices. Comprising two essential libraries – the core and the platform – it offers distinct functionalities. The core library encompasses platform-independent features such as QML items, animations, text layout, property systems, and the scene graph. Meanwhile, the platform library is responsible for managing hardware-specific tasks like rendering, input, timers, and more. Facilitating seamless interaction between the core and platform libraries is the Platform Abstraction layer.