Jó napot! Mi a projektben elindítottuk a Qt-t az STM32F7-Discovery-n, és szeretnénk beszélni róla. Korábban már írtunk arról, hogyan sikerült elindítani az .
A Qt egy keresztplatformos keretrendszer, amely nemcsak grafikus komponenseket tartalmaz, hanem olyan dolgokat is, mint a QtNetwork, adatbázis-kezelő osztályok, a Qt for Automation (beleértve az IoT megvalósítást) és sok más egyéb. A Qt csapat fejlesztői előre látták a Qt használatát beágyazott rendszerekben, így a könyvtárak jól konfigurálhatóak. Azonban egészen nemrégig kevesen gondoltak a Qt mikrokontrollerre történő portolására, valószínűleg azért, mert ez a feladat bonyolultnak tűnik — a Qt nagy, a MCU pedig kicsi.
Másrészről, jelenleg léteznek multimédia-megvalósításra tervezett mikrokontrollerek, amelyek felülmúlják az első Pentiumokat. Körülbelül egy évvel ezelőtt a Qt blogján megjelent egy . A fejlesztők létrehozták a Qt portját az RTEMS operációs rendszerhez, és példákat futtattak widgetekkel több STM32F7-alapú deszkán. Ez felkeltette az érdeklődésünket. Észrevettük, és a fejlesztők is említik, hogy a Qt lassan működik az STM32F7-Discovery-n. Kíváncsiak voltunk, hogy sikerül-e elindítani a Qt-t az Embox alatt, nemcsak egy widgetet rajzolni, hanem animációt is futtatni.
Az Embox-ban már régen portolták a Qt 4.8-at, ezért úgy döntöttünk, hogy megpróbáljuk. Az alkalmazás a moveblocks példáját választottuk — rugós animáció példája.
Qt moveblocks a QEMU-n
Először a Qt-t a lehető legkisebb szükséges komponenskészlettel konfiguráljuk az animáció támogatásához. Ehhez van egy opció, a “-qconfig minimal,small,medium …”. Ez csatlakoztat egy konfigurációs fájlt a Qt-ból, amely számos makrót tartalmaz — mit kapcsoljunk be / mit kapcsoljunk ki. Ezen opció után hozzáadunk további zászlókat a konfigurációhoz, ha további dolgokat szeretnénk kikapcsolni. Íme, egy példa a mi .
A Qt működéséhez szükséges egy operációs rendszerrel való kompatibilitási réteg hozzáadása. Az egyik megoldás a QPA (Qt Platform Abstraction) megvalósítása. Alapként a Qt-ban található fb_base plugint használtuk, amelyre a QPA Linux alatt épül. Ennek eredményeként egy kis emboxfb plugint hoztunk létre, amely a Qt számára az Embox framebufferét biztosítja, majd azon már külső segítség nélkül rajzol.
Így néz ki a plugin készítése
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();
}
Ez így fog kinézni a rajzolás újrarajzolása
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;
}
A memória méret-optimalizáló fordító bekapcsolásával -Os a könyvtár képe 3,5 MB lett, ami természetesen nem fér bele az STM32F746 főmemóriájába. Ahogy már említettük egy másik cikkünkben az OpenCV-vel kapcsolatosan, ezen az áramkörön található:
- 1 MB ROM
- 320 KB RAM
- 8 MB SDRAM
- 16 MB QSPI
Mivel az OpenCV már támogatja a kód végrehajtását a QSPI-ből, úgy döntöttünk, hogy először teljes mértékben betöltjük az Embox képet Qt-val a QSPI-be. És örömünkre, szinte azonnal elindult a QSPI-ből! De ahogy az OpenCV esetében is kiderült, túl lassan működött.
Ezért úgy döntöttünk, hogy először a képet a QSPI-be másoljuk, majd betöltjük az SDRAM-ba, és onnan hajtjuk végre. Az SDRAM-ból kicsit gyorsabb lett, de még mindig messze volt a QEMU-tól.
Később az volt az ötlet, hogy engedjük meg a lebegőpontos számítást - hiszen a Qt néhány téglalap koordinátáját számolja az animációban. Kipróbáltuk, de itt nem észleltünk látható gyorsulást, bár a Qt fejlesztői állították, hogy az FPU jelentős sebességnövekedést nyújt a "húzós animációk" során érintőképernyőn. Lehetséges, hogy a moveblocks esetében lényegesen kevesebb lebegőpontos számítást végeznek, és ez a konkrét példától függ.
A legjobbnak a framebuffer SDRAM-ból a belső memóriába történő átköltöztetése bizonyult. Ehhez a képernyő méretét 480×272 helyett 272×272-esre állítottuk. Ezen kívül a színmélységet is csökkentettük A8R8G8B8-ról R5G6B5-re, így a pixel mérete 4 bájról 2 bájra csökkent. A framebuffer mérete 272 * 272 * 2 = 147968 byte lett. Ez jelentős gyorsulást eredményezett, talán a legszembetűnőbbet, a animáció szinte simává vált.
Az utolsó optimalizálás az Embox kódjának RAM-ból, a Qt-nak pedig SDRAM-ból való végrehajtása volt. Ehhez először, mint általában, statikusan linkeltük az Emboxot a Qt-val, de a text, rodata, data és bss szegmenseket a QSPI-be helyeztük, hogy később átkonvertálhassuk SDRAM-ba.
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))
Az Embox ROM-ból való végrehajtásával szintén észlelhető gyorsulást értünk el. Végül az animáció eléggé sima lett:
A cikk előkészítésekor és különböző Embox konfigurációk kipróbálásakor kiderült, hogy a Qt moveblocks remekül működik QSPI-ből az SDRAM framebufferrel, és a szűk keresztmetszet éppen a framebuffer mérete volt! Úgy tűnik, hogy a kezdeti "diavetítés" leküzdéséhez elegendő volt a framebuffer méretének banális csökkentése által elért 2-szeres gyorsulás. Ezt azonban a kód Embox különböző gyors memóriákba való áthelyezésével nem sikerült elérni (a gyorsulás nem 2, hanem körülbelül 1,5-szörös volt).
Hogyan próbálhatod ki magad
Ha rendelkezel STM32F7-Discovery-val, saját magad is elindíthatod a Qt-t az Embox alatt. Hogy ez hogyan lehetséges, azt a .
Zárás
Végül sikerült elindítanunk a Qt-t! Úgy véljük, hogy a feladat nehézsége kissé túl van értékelve. Természetesen figyelembe kell venni a mikrokontrollerek sajátosságait és általában megérteni a számítástechnikai rendszerek architektúráját. Az optimalizációs eredmények arra utalnak, hogy a számítástechnikai rendszerek legszűkebb helye nem a processzor, hanem a memória.
Idén részt veszünk a fesztiválon . Ott részletesebben bemutatjuk a Qt-t, az OpenCV-t mikrokontrollereken, és egyéb eredményeinket.
Forrás: habr.com
