Пренесување на Qt на STM32

Добар ден Ние сме во проектот Ембокс го лансираше 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 го блокира движењето на QEMU

За почеток, ние го конфигурираме Qt, ако е можно, со минималниот сет на компоненти потребни за поддршка на анимацијата. За ова постои опција „-qconfig минимално, мало, средно...“. Поврзува конфигурациска датотека од 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 c Qt во QSPI. И ура, се почна скоро веднаш од QSPI! Но, како и во случајот со OpenCV, се покажа дека работи премногу бавно.

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

Следно, имаше идеја да се вклучи подвижна запирка - на крајот на краиштата, Qt прави некои пресметки на координатите на квадратите во анимацијата. Се обидовме, но тука не добивме видливо забрзување, иако во Член Програмерите на Qt тврдеа дека FPU дава значително зголемување на брзината за „влечење анимација“ на екран на допир. Може да има значително помалку пресметки со подвижна запирка во подвижните блокови, и тоа зависи од конкретниот пример.

Најефективната идеја беше да се премести framebuffer од SDRAM во внатрешна меморија. За да го направите ова, ги направивме димензиите на екранот не 480x272, туку 272x272. Ја намаливме и длабочината на бојата од A8R8G8B8 на R5G6B5, со што ја намаливме големината на еден пиксел од 4 на 2 бајти. Резултирачката големина на баферот на рамката е 272 * 272 * 2 = 147968 бајти. Ова даде значително забрзување, можеби најзабележливо, анимацијата стана речиси мазна.

Најновата оптимизација беше да се изврши Embox код од RAM и Qt код од SDRAM. За да го направите ова, ние прво, како и обично, статички го поврзуваме Embox заедно со Qt, но ги ставаме текстот, податоците, податоците и 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 со рамка во SDRAM, а тесното грло беше точно со големина на рамката! Очигледно, за да се надмине првичното „слајдшоу“, доволно беше 2-кратно забрзување поради баналното намалување на големината на баферот на рамката. Но, не беше можно да се постигне таков резултат со пренесување само на кодот Embox на разни брзи мемории (забрзувањето не беше 2, туку околу 1.5 пати).

Како да го пробате сами

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

Заклучок

Како резултат на тоа, успеавме да го лансираме Qt! Комплексноста на задачата, според наше мислење, е донекаде претерана. Секако, треба да ги земете предвид спецификите на микроконтролерите и генерално да ја разберете архитектурата на компјутерските системи. Резултатите од оптимизацијата укажуваат на добро познатиот факт дека тесно грло во компјутерскиот систем не е процесорот, туку меморијата.

Оваа година ќе учествуваме на фестивалот TechTrain. Таму ќе ви кажеме подетално и ќе ги прикажеме Qt, OpenCV на микроконтролери и други наши достигнувања.

Извор: www.habr.com