Portering av Qt till STM32

God dag! Vi arbetar på projektet Embox och har lanserat Qt på STM32F7-Discovery och vill gärna berätta om det. Tidigare har vi redan berättat hur vi lyckades få igång OpenCV.

Qt är ett plattformsoberoende ramverk som inkluderar inte bara grafiska komponenter utan också saker som QtNetwork, en uppsättning klasser för databashantering, Qt for Automation (inklusive för implementering av IoT) och mycket mer. Utvecklarna i Qt-teamet har på förhand förberett användning av Qt i inbyggda system, så biblioteken är ganska väl konfigurerbara. Men fram till nyligen har få tänkt på portering av Qt till mikrokontroller, sannolikt för att uppgiften verkar komplicerad — Qt är stort, MCU är små.

Å andra sidan finns det nu mikrokontroller som är avsedda för multimedia och överträffar de första Pentium-datorerna. För ungefär ett år sedan dök det upp ett inläggi Qt-bloggen. Utvecklarna har portat Qt för RTEMS-operativsystemet och kört exempel med widgets på flera kort som drivs av stm32f7. Det intresserade oss. Det var uppenbart, och utvecklarna själva skriver om det, att Qt är segt på STM32F7-Discovery. Vi blev nyfikna på om vi kunde köra Qt på Embox, och inte bara rita widgets, utan också köra animation.

Qt 4.8 har länge varit portat till Embox, så vi beslutade att försöka med det. Vi valde applikationen moveblocks — ett exempel på fjädrande animation.

Qt moveblocks på QEMU

Först konfigurerar vi Qt med så minimalt sett av komponenter som möjligt, vilket behövs för att stödja animation. Det finns en option “-qconfig minimal, small, medium …”. Den kopplar ett konfigurationsfil från Qt med många makron — vad som ska inkluderas / vad som ska uteslutas. Efter denna option lägger vi till andra flaggor i konfigurationen om vi vill stänga av något mer. Här är ett exempel på vår konfiguration.

För att Qt ska fungera måste vi lägga till ett kompatibilitetslager för OS. Ett sätt är att implementera QPA (Qt Platform Abstraction). Vi använde den redan befintliga fb_base-pluginen i Qt som bas för QPA för Linux. Resultatet blev en liten plugin emboxfb som tillhandahåller Qt framebuffer för Embox, och därefter ritar den dit utan extern hjälp.

Så här ser skapandet av en plugin ut

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å här kommer omritningen att se ut

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 ett resultat av att kompilatorns minnesoptimering -Os var aktiverad, blev storleken på bibliotekets bild 3,5 MB, vilket självklart inte får plats i huvudminnet STM32F746. Som vi redan nämnt i vår andra artikel om OpenCV, denna plat innehåller:

• 1 MB ROM
• 320 KB RAM
• 8 MB SDRAM
• 16 MB QSPI

Eftersom OpenCV redan hade stöd för att köra kod från QSPI, beslutade vi att först ladda bilden av Embox med Qt i QSPI helt. Och hurra, nästan allt startade direkt från QSPI! Men precis som med OpenCV visade det sig att det fungerade för långsamt.

Därför bestämde vi oss för att göra så här – först kopiera bilden till QSPI, sedan ladda den i SDRAM och köra därifrån. Från SDRAM blev det lite snabbare, men det var fortfarande långt ifrån QEMU.

Vidare fanns tanken att aktivera flyttal – eftersom Qt gör vissa beräkningar av kvadraternas koordinater i animationen. Vi provade, men fick ingen märkbar accelerering, även om artikeln Qt-utvecklarna hävdade att FPU ger en betydande hastighetsökning för "dragging animation" på pekskärmen. Kanske handlar det om att moveblocks innehåller betydligt färre flyttalsberäkningar, och det beror på det specifika exemplet.

Den mest effektiva idén var att flytta framebuffer från SDRAM till internminnet. För detta gjorde vi skärmstorleken till 272×272 istället för 480×272. Vi sänkte även färgdjupet från A8R8G8B8 till R5G6B5, vilket minskade storleken på en pixel från 4 till 2 byte. Vi fick en framebuffer-storlek på 272 * 272 * 2 = 147968 byte. Detta gav en betydande ökning av hastigheten, kanske den mest märkbara, och animationen blev nästan helt jämn.

Den sista optimeringen var att köra koden från Embox från RAM och Qt från SDRAM. För detta länkade vi först Embox tillsammans med Qt statiskt som vanligt, men segmenten text, rodata, data och bss från biblioteket placerades i QSPI, så att vi sedan kunde kopiera dem till 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))

Genom att köra koden från Embox från ROM fick vi också en märkbar ökning av hastigheten. Resultatet blev att animationen blev tillräckligt jämn:

I slutet, när vi förberedde artikeln och testade olika konfigurationer av Embox, upptäckte vi att Qt moveblocks fungerar utmärkt från QSPI med framebuffer i SDRAM, och det trånga området var faktiskt storleken på framebuffer! Det verkar som att för att övervinna det initiala "slideshowet" räckte det med en 2 gånger ökning genom att helt enkelt minska storleken på framebuffer. Att uppnå ett sådant resultat genom att bara flytta koden från Embox till olika snabba minnen var inte möjligt (ökningen var inte 2 utan cirka 1,5 gånger).

Hur du kan testa själv

Om du har en STM32F7-Discovery kan du köra Qt under Embox själv. Läs hur det görs på vår wiki.

Slutsats

Som ett resultat lyckades vi köra Qt! Svårighetsgraden av uppgiften, enligt vår åsikt, var något överdriven. Naturligtvis måste man ta hänsyn till mikrokontrollens specifik och förstå arkitekturen av datorsystem. Optimeringsresultaten visar det välkända faktumet att den mest begränsande faktorn i ett datorsystem inte är processorn, utan minnet.

I år kommer vi att delta i festivalen TechTrain. Där kommer vi att berätta mer och visa Qt, OpenCV på mikrokontroller och våra andra framgångar.

Källa: habr.com