Портироване на Qt на STM32

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

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

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

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

Qt moveblocks на QEMU

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

За да работи Qt, е необходимо да добавим слой на съвместимост с ОС. Един от начините е да реализираме QPA (Qt Platform Abstraction). Взехме за основа вече готов плъгин fb_base от Qt, на базата на който работи QPA за Linux. В крайна сметка получихме малък плъгин emboxfb, който предоставя на Qt framebuffer на 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 (fbFd setPhysicalSize(QSize(fbWidth, fbHeight));
    mScreens.append(mPrimaryScreen);

    this->printFbInfo();
}

А ето как ще изглежда преизображението

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;
}

В крайна сметка, с включена оптимизация на компилатора за размер на паметта -Os, образа на библиотеката стана 3.5 Мб, което, разбира се, не се вписва в основната памет на STM32F746. Както споменахме в друга статия за OpenCV, на тази платка има:

• 1 Мб ROM
• 320 Кб RAM
• 8 Мб SDRAM
• 16 Мб QSPI

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

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

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

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

Последното оптимизиране беше изпълнението на кода Embox от RAM, а на Qt от SDRAM. За това първо линковахме статично Embox заедно с Qt, но сегментите text, rodata, data и 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 пъти, постигнато чрез простото намаляване на размера на framebuffer. А постигането на подобен резултат само с прехвърлянето на кода Embox в различни бързи памети не успя (ускорението беше не 2, а около 1.5 пъти).

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

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

Заключение

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

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

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