🥇Portering af Qt til STM32

Goddag! Vi i projektet Embox har startet Qt på STM32F7-Discovery og vil gerne fortælle om det. Tidligere har vi allerede beskrevet, hvordan vi lykkedes med at starte OpenCV.

Qt — en tværplatformsramme, der omfatter ikke kun grafiske komponenter, men også ting som QtNetwork, et sæt klasser til databearbejdning, Qt for Automation (herunder til implementering af IoT) og meget mere. Udviklerne af Qt-teamet har på forhånd taget højde for brugen af Qt i indlejrede systemer, hvilket gør, at bibliotekerne er ret godt konfigurerbare. Dog har der hidtil været få, der har overvejet portering af Qt til mikrokontrollere, sandsynligvis fordi opgaven virker kompleks — Qt er stort, MCU'er er små.

På den anden side findes der i øjeblikket mikrokontrollere, der er designet til at arbejde med multimedier og overgår de første Pentium'er. For omkring et år siden dukkede der op i Qt-bloggen post. Udviklerne har lavet en port af Qt til RTEMS, og har kørt eksempler med widgets på flere boards med stm32f7. Dette fangede vores interesse. Det blev klart, og udviklerne nævner det selv, at Qt hakker på STM32F7-Discovery. Vi blev nysgerrige efter, om vi kunne køre Qt på Embox, ikke blot tegne en widget, men også køre en animation.

Qt 4.8 er allerede blevet porteret til Embox i lang tid, så vi besluttede at prøve på det. Vi valgte applikationen moveblocks — et eksempel på fjederanimation.

Qt moveblocks på QEMU

Først konfigurerer vi Qt med den mest minimale komponentpakke, der kræves for at understøtte animation. Der findes en mulighed “-qconfig minimal,small,medium …”. Den tilslutter en konfigurationsfil fra Qt-sættet med mange makroer — hvad der skal inkluderes / hvad der skal udelukkes. Efter denne mulighed tilføjer vi andre flag til konfigurationen, hvis vi vil udelukke noget mere. Her er et eksempel på vores configuration.

For at Qt kan fungere, skal der tilføjes et kompatibilitetslag til OS. En måde at gøre det på er at implementere QPA (Qt Platform Abstraction). Vi tog udgangspunkt i den eksisterende fb_base plugin i Qt, som QPA for Linux fungerer ud fra. Resultatet blev en lille plugin emboxfb, der giver Qt Embox' framebuffer, hvorefter det tegner der uden yderligere hjælp.

Sådan ser oprettelsen af et plugin ud

QEmboxFbIntegration::QEmboxFbIntegration()
    : fontDb(new QGenericUnixFontDatabase())
{
    struct fb_var_screeninfo vinfo;
    struct fb_fix_screeninfo finfo;
    const char *fbPath = "/dev/fb0";

    fbFd = open(fbPath, O_RDWR);
    if (fbFd setPhysicalSize(QSize(fbWidth, fbHeight));
    mScreens.append(mPrimaryScreen);

    this->printFbInfo();
}

Sådan vil omtegningen se ud

QRegion QEmboxFbScreen::doRedraw()
{
    QVector rects;
    QRegion touched = QFbScreen::doRedraw();

    DPRINTF("QEmboxFbScreen::doRedrawn");

    if (!compositePainter) {
        compositePainter = new QPainter(mFbScreenImage);
    }

    rects = touched.rects();
    for (int i = 0; i drawImage(rects[i], *mScreenImage, rects[i]);
    }
    return touched;
}

Som et resultat af at optimere kompilatoren for hukommelsesstørrelse -Os, blev bibliotekets billede 3,5 Mb, hvilket naturligvis ikke kan være i hovedhukommelsen STM32F746. Som vi allerede har nævnt i vores anden artikel om OpenCV, har dette board:

1 Mb ROM
320 Kb RAM
8 Mb SDRAM
16 Mb QSPI

Da OpenCV allerede har fået tilføjet støtte til udførelse af kode fra QSPI, besluttede vi at starte med at indlæse Embox med Qt-billedet i QSPI helt. Og hurra, det hele startede næsten med det samme fra QSPI! Men som i tilfælde med OpenCV viste det sig, at det fungerede alt for langsomt.

Vi besluttede derfor at gøre det på denne måde – først kopiere billedet til QSPI, derefter indlæse det i SDRAM og udføre det derfra. Fra SDRAM blev det lidt hurtigere, men stadig langt fra QEMU.

Der var derefter ideen om at aktivere flydende punkt – da Qt udfører nogle beregninger af koordinaterne for firkanter i animationen. Vi prøvede, men fik ikke nogen synlig acceleration, selvom i artikel Qt-udviklerne hævdede, at FPU giver en betydelig stigning i hastighed for "dragging animation" på en touchscreen. Måske er der betydeligt færre beregninger med flydende punkt i moveblocks, og det afhænger af det specifikke eksempel.

Den mest effektive løsning viste sig at være at flytte framebufferen fra SDRAM til det interne hukommelse. For dette gjorde vi skærmstørrelsen ikke 480×272, men 272×272. Vi sænkede også farvedybden fra A8R8G8B8 til R5G6B5, hvilket reducerede størrelsen af en pixel fra 4 til 2 byte. Vi fik en framebuffer størrelse på 272 * 272 * 2 = 147968 byte. Dette gav en betydelig acceleration, formentlig den mest mærkbare, animationen blev næsten glidende.

Den sidste optimering var at køre Embox-koden fra RAM og Qt fra SDRAM. For dette linker vi først som normalt statisk Embox sammen med Qt, men placerer segmenterne text, rodata, data og bss fra biblioteket i QSPI, så vi senere kan kopiere dem til SDRAM.

section (qt_text, SDRAM, QSPI)
phdr	(qt_text, PT_LOAD, FLAGS(5))

section (qt_rodata, SDRAM, QSPI)
phdr	(qt_rodata, PT_LOAD, FLAGS(5))

section (qt_data, SDRAM, QSPI)
phdr	(qt_data, PT_LOAD, FLAGS(6))

section (qt_bss, SDRAM, QSPI)
phdr	(qt_bss, PT_LOAD, FLAGS(6))

Ved at køre Embox-koden fra ROM opnåede vi også en mærkbar acceleration. Som resultat blev animationen ret glidende:

Allerede i slutningen, mens artiklen blev forberedt og forskellige konfigurationer af Embox blev testet, blev det klart, at Qt moveblocks fungerer fremragende fra QSPI med framebufferen i SDRAM, og det snævre punkt var netop størrelsen på framebufferen! Tilsyneladende var det tilstrækkeligt at reducere størrelsen på framebufferen for at overvinde den indledende 'slideshow' ved at opnå en acceleration på 2 gange. At opnå dette resultat kun ved at flytte Embox-koden til forskellige hurtige hukommelser lykkedes ikke (accelerationen var ikke 2, men cirka 1.5 gange).

Sådan kan du prøve selv

Hvis du har en STM32F7-Discovery, kan du selv køre Qt under Embox. Du kan læse om, hvordan dette gøres på vores wiki.

Konklusion

Som resultat lykkedes det os at køre Qt! Sværhedsgraden af opgaven, efter vores mening, er lidt overdrevet. Det er selvfølgelig nødvendigt at tage højde for mikrocontrolleres specifikationer og generelt forstå arkitekturen af databehandlingssystemer. Optimeringsresultaterne viser den velkendte kendsgerning, at det snævre punkt i et databehandlingssystem ikke er processoren, men hukommelsen.

I år vil vi deltage i festivalen TechTrain. Her vil vi uddybe og vise Qt, OpenCV på mikrocontrollere og andre præstationer.

Kilde: habr.com

Portierung von Qt auf STM32

Sådan kan du prøve selv

Konklusion