Пренасяне на Qt към STM32

Добър ден Ние сме в проекта Embox стартира Qt на STM32F7-Discovery и би искал да говори за това. По-рано вече казахме как успяхме да стартираме OpenCV.

Qt е междуплатформена рамка, която включва не само графични компоненти, но и неща като QtNetwork, набор от класове за работа с бази данни, Qt за автоматизация (включително реализация на IoT) и много други. Разработчиците на екипа на Qt са предвидили използването на Qt във вградени системи, така че библиотеките са доста добре конфигурируеми. Доскоро обаче малко хора мислеха за пренасяне на Qt към микроконтролери, вероятно защото подобна задача изглежда трудна - Qt е голям, MCU са малки.

От друга страна, в момента има микроконтролери, предназначени да работят с мултимедия и да надминават първите Pentium. Появи се в блога на Qt преди около година пост. Разработчиците направиха порт на Qt под RTEMS OS и пуснаха примери с уиджети на няколко платки, изпълняващи stm32f7. Ние се интересуваме от това. Беше забележимо и самите разработчици пишат за това, че Qt се забавя на STM32F7-Discovery. Чудехме се дали можем да стартираме Qt под Embox и не просто да нарисуваме джаджа, но да стартираме анимация.

Qt 4.8 беше пренесен към Embox от дълго време, така че решихме да го изпробваме на него. Избрахме приложението moveblocks - пример за пружинираща анимация.

Qt moveblocks на QEMU

Като начало конфигурираме Qt с минималния набор от компоненти, необходими за поддържане на анимация, ако е възможно. За това има опция „-qconfig minimal,small,medium…“. Включва конфигурационен файл от Qt с много макроси - какво да активирате / какво да деактивирате. След тази опция добавяме други флагове към конфигурацията, ако искаме да деактивираме нещо друго допълнително. Ето един пример от нас конфигурация.

За да работи Qt, трябва да добавите слой за съвместимост с ОС. Един от начините е да се внедри QPA (Qt Platform Abstraction). За основа беше взет готовият плъгин fb_base като част от Qt, на базата на който работи QPA за Linux. Резултатът е малък плъгин emboxfb, който предоставя на Qt фреймбуфера на Embox и след това рисува там без външна помощ.

Ето как изглежда приставката

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 (fbPath < 0) {
        qFatal("QEmboxFbIntegration: Error open framebuffer %s", fbPath);
    }
    if (ioctl(fbFd, FBIOGET_FSCREENINFO, &finfo) == -1) {
        qFatal("QEmboxFbIntegration: Error ioctl framebuffer %s", fbPath);
    }
    if (ioctl(fbFd, FBIOGET_VSCREENINFO, &vinfo) == -1) {
        qFatal("QEmboxFbIntegration: Error ioctl framebuffer %s", fbPath);
    }
    fbWidth        = vinfo.xres;
    fbHeight       = vinfo.yres;
    fbBytesPerLine = finfo.line_length;
    fbSize         = fbBytesPerLine * fbHeight;
    fbFormat       = vinfo.fmt;
    fbData = (uint8_t *)mmap(0, fbSize, PROT_READ | PROT_WRITE,
                             MAP_SHARED, fbFd, 0);
    if (fbData == MAP_FAILED) {
        qFatal("QEmboxFbIntegration: Error mmap framebuffer %s", fbPath);
    }
    if (!fbData || !fbSize) {
        qFatal("QEmboxFbIntegration: Wrong framebuffer: base = %p,"
               "size=%d", fbData, fbSize);
    }

    mPrimaryScreen = new QEmboxFbScreen(fbData, fbWidth,
                                        fbHeight, fbBytesPerLine,
                                        emboxFbFormatToQImageFormat(fbFormat));

    mPrimaryScreen->setPhysicalSize(QSize(fbWidth, fbHeight));
    mScreens.append(mPrimaryScreen);

    this->printFbInfo();
}

Ето как ще изглежда преначертаването

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

    DPRINTF("QEmboxFbScreen::doRedrawn");

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

    rects = touched.rects();
    for (int i = 0; i < rects.size(); i++) {
        compositePainter->drawImage(rects[i], *mScreenImage, rects[i]);
    }
    return touched;
}

В резултат на това с активирана оптимизация на компилатора за размер на паметта -Os, изображението на библиотеката се оказа 3.5 MB, което, разбира се, не се вписва в основната памет на STM32F746. Както писахме в нашата друга статия за OpenCV, тази дъска има:

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

Тъй като поддръжката за изпълнение на код от QSPI вече е добавена за OpenCV, решихме да започнем със зареждане на цялото изображение на Embox с Qt в QSPI. И ура, всичко започна почти веднага от QSPI! Но както и в случая с OpenCV, той се оказа твърде бавен.

Затова решихме да направим това - първо копираме изображението в QSPI, след това го зареждаме в SDRAM и изпълняваме от там. От SDRAM стана малко по-бързо, но все още е далеч от QEMU.

След това имаше идея да се включи плаваща запетая - все пак Qt прави някои изчисления на координатите на квадратите в анимацията. Опитахме, но тук не получихме видимо ускорение, въпреки че в Статия Разработчиците на Qt твърдят, че FPU осигурява значително увеличение на скоростта за „плъзгане на анимации“ на сензорния екран. Може да има значително по-малко изчисления с плаваща запетая в moveblocks и това зависи от конкретния пример.

Идеята за прехвърляне на фреймбуфера от SDRAM към вътрешната памет се оказа най-ефективна. За да направим това, направихме размера на екрана не 480x272, а 272x272. Също така намалихме дълбочината на цвета от A8R8G8B8 на R5G6B5, като по този начин намалихме размера на един пиксел от 4 на 2 байта. Получихме размера на буфера на кадрите 272 * 272 * 2 = 147968 байта. Това даде значително ускорение, може би най-забележимо, анимацията стана почти гладка.

Последната оптимизация беше изпълнението на Embox код от RAM и Qt от SDRAM. За да направим това, първо, както обикновено, свързваме статично Embox заедно с Qt, но поставяме текста, rodata, данните и bss сегментите на библиотеката в QSPI, за да го копираме по-късно в 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))

Чрез изпълнение на Embox кода от ROM, ние също получихме забележимо ускоряване. В резултат на това анимацията се оказа доста гладка:

Още в самия край, подготвяйки статията и опитвайки различни конфигурации на Embox, се оказа, че Qt moveblocks работи чудесно от QSPI с framebuffer в SDRAM, а тясното място беше точно размера на framebuffer! Очевидно, за да се преодолее първоначалното „слайдшоу“, беше достатъчно 2-кратно ускорение поради баналното намаляване на размера на кадровия буфер. Но не беше възможно да се постигне такъв резултат чрез прехвърляне само на кода на Embox към различни бързи памети (ускорението не беше 2, а около 1.5 пъти).

Как да опитате сами

Ако имате STM32F7-Discovery, можете сами да стартирате Qt под Embox. Можете да прочетете как се прави на нашия уики.

Заключение

В резултат на това успяхме да стартираме Qt! Сложността на задачата според нас е донякъде преувеличена. Естествено, трябва да вземете предвид спецификата на микроконтролерите и като цяло да разберете архитектурата на изчислителните системи. Резултатите от оптимизацията сочат добре известния факт, че тясното място в една изчислителна система не е процесорът, а паметта.

Тази година ще участваме във фестивала Технически влак. Там ще разкажем по-подробно и ще покажем Qt, OpenCV на микроконтролери и други наши постижения.

Източник: www.habr.com