Exploring Porting Qt for MCUs onto STM32H747I-DISCO


Kalarav Parmar
Kalarav Parmar
Senior Embedded Board Support Package Engineer at Silicon Signals Pvt. Ltd. With a track record of contributing to customer success, Kalarav excels in Embedded System Design, from architecture to execution. His expertise lies in Xilinx Zynq, NXP i.MX & Amlogic based chipsets, and he has made significant contributions to the development of Linux-based crypto device drivers & platform porting expertise.

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.


Pic Courtesy – https://doc.qt.io/archives/QtForMCUs-2.2/platform-porting-guide-architecture.html

Selecting hardware is vital for Qt for MCUs.

Choosing the right hardware is crucial when considering Qt for MCUs. It’s essential to opt for an MCU platform capable of driving a display, with display interface options including RGB, MIPI-DSI, or LVDS for achieving high resolution and frame rates, while SPI or Parallel interfaces are suitable for lower resolution and/or frame rates. Here are the primary requirements to consider:

  • MCU RAM (internal/external): Static RAM: 20 Kb minimum for basic applications, while 200 Kb or higher is recommended for typical applications. Stack: 2-12 Kb. Heap: 20 Kb.
  • MCU Flash/ROM: 500 KB or more.

Insight into Our Work

We’ve effectively ported the KDAB boat demo to the device (KDAB for MPUs). This demonstration highlights an advanced UI featuring numerous dynamic and graphical elements, serving as a testament to the capabilities of our platform and the excellence of our efforts.

This demo showcases a range of functionalities and use cases. Explore the various applications and features through the screen snapshots below.


And now with this porting available, other QT provided demos are running smoothly on the platform. Here is one such Ultralite Motorcycle Instrument Cluster Demo


Conclusion: Empowering Developers, Enhancing Embedded Systems

Our exploration has revealed that employing Qt for MCUs on embedded systems is less daunting than anticipated, especially for those with prior experience in embedded systems.

Regarding performance APIs, we haven’t conducted a dedicated analysis yet. However, we intend to delve into performance APIs and optimize the configuration, if feasible, for a subsequent publication. If you’re contemplating utilizing Qt for MCUs in a significant product, it’s crucial to thoroughly benchmark all performance and footprint requirements.

If your team has primarily developed Qt-based applications for mobile or web platforms and is well-versed in Qt, Qt for MCUs could be a viable choice. Furthermore, if your envisioned product spans across mobile, web, and embedded systems, with frequent updates planned across this ecosystem using a single-source code base, Qt for MCUs could be an ideal option.


As an acknowledgment, we extend our sincere thanks to
crossware.io for their invaluable tool support throughout the process, check for more here


Let’s Get In Touch

Interested in collaborating with Silicon Signals on your next big idea? Please contact us and let us know how we can help you.