Running QT on STM32. Part 2. Now with pseudo 3d and touchscreen

We are in the project Embox some time ago we launched Qt on the STM32 platform. An example was the moveblocks app, an animation with four blue squares that move across the screen. We wanted more, for example, to add interactivity, because a touchscreen is available on the board. We chose the animatedtiles app simply because it looks cool on a computer too. By pressing virtual buttons, many icons smoothly move around the screen, gathering in various shapes. Moreover, it looks quite like 3d animation, and we even had doubts whether the microcontroller would cope with such a task.


First of all, we start with the assembly. The easiest way to do this is on the QEMU emulator. there everything fits exactly from memory, and therefore it is easy to check whether all the components are enough to build the application. After checking that all the animatedtiles assembled successfully, I easily transferred it to the configuration for the board I needed.

First start on board

The screen size for STM32F746G-Discovery is 480×272, when the application was launched, it was drawn only at the top of the screen. We naturally wanted to find out what was the matter. Of course, you can go into debugging right on the board, but there is an easier solution. run the application on Linux with the same 480×272 dimensions with the QVFB virtual framebuffer.

Launching on Linux

To run on Linux, we need three parts of QVFB, the Qt library, and the application itself.

QVFB is a regular application that will provide us with a virtual screen for Qt to run. We collect it as written in official documentation

Launch with the desired screen size:

./qvfb -width 480 -height 272 -nocursor

Next, we build the Qt library as embedded, i.e. With the -embedded option specified. I also disabled various modules to speed up the build, in the end the configuration looked like this:

./configure -opensource -confirm-license -debug 
    -embedded -qt-gfx-qvfb -qvfb 
    -no-javascript-jit -no-script -no-scripttools 
    -no-qt3support -no-webkit -nomake demos -nomake examples

Next, we build the animatedtiles application (qmake + make). And we launch the compiled application, pointing it to our QVFB:

./examples/animation/animatedtiles/animatedtiles -qws -display QVFb:0

After launching, I saw that on Linux it also draws only to a part of the screen. I modified animatedtiles a bit by adding an option “-fullscreen”, when specified, the application starts in full screen mode.

Launch on Embox

We will use the modified source code of the application in Embox. We rebuild and run. The application did not start and Qt ran out of memory messages. We look at the Embox configuration and find that the heap size is set to 2MB and is clearly not enough. Again, you can try to figure out this point directly on the board, but let’s do it comfortably in Linux.

To do this, launch the application as follows:

$ valgrind --tool=massif --massif-out-file=animatedtiles.massif ./examples/animation/animatedtiles/animatedtiles -qws -fullscreen
$ ms_print animatedtiles.massif > animatedtiles.out

In the animatedtiles.out file, we see the maximum value of the heap occupancy of about 2.7 MB. Great, now you don’t have to guess, but go back to Embox and set the heap size to 3MB.

Animatedtiles launched.

Launch on STM32F769I-Discovery.

Let’s try to complicate the task even more, and run the same example on a similar microcontroller, but only with a higher screen resolution – STM32F769I-Discovery (800×480). That is, now the framebuffer will require 1.7 times more memory (remember that the STM32F746G has a 480×272 screen), but this is compensated by twice the size of SDRAM (16 MB versus 8 MB of available SDRAM for the STM32F746G).

To estimate the size of the heap, as above, first run Qvfb and our Linux application:

$ ./qvfb -width 800 -height 480 -nocursor &
$ valgrind --tool=massif --massif-out-file=animatedtiles.massif ./examples/animation/animatedtiles/animatedtiles -qws -fullscreen
$ ms_print animatedtiles.massif > animatedtiles.out

We look at the memory consumption in the heap – about 6 MB (almost twice as much as on the STM32F746G).

It remains to set the desired heap size in mods.conf and rebuild. The application started immediately and without problems, as demonstrated in this short video

Traditionally, you can reproduce the results yourself. How to do this is described on our website. wiki

This article was first published by us on English on

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *