Qt-ის პორტირება STM32-ზე

Საღამო მშვიდობისა პროექტში ვართ Embox გაუშვა Qt STM32F7-Discovery-ზე და მსურს ამაზე საუბარი. ადრე ჩვენ უკვე ვუთხარით, თუ როგორ მოვახერხეთ გაშვება OpenCV.

Qt არის კროს-პლატფორმული ჩარჩო, რომელიც მოიცავს არა მხოლოდ გრაფიკულ კომპონენტებს, არამედ ისეთ ნივთებს, როგორიცაა QtNetwork, მონაცემთა ბაზებთან მუშაობის კლასების ნაკრები, Qt ავტომატიზაციისთვის (მათ შორის, IoT განხორციელებისთვის) და მრავალი სხვა. Qt გუნდი პროაქტიული იყო Qt-ის გამოყენებასთან დაკავშირებით ჩაშენებულ სისტემებში, ამიტომ ბიბლიოთეკები საკმაოდ კონფიგურირებადია. თუმცა, ბოლო დრომდე ცოტას თუ ფიქრობდა Qt მიკროკონტროლერებზე პორტირებაზე, ალბათ იმიტომ, რომ ასეთი დავალება რთული ჩანს - Qt დიდია, MCU - პატარა.

მეორეს მხრივ, ამ მომენტში არის მიკროკონტროლერები, რომლებიც შექმნილია მულტიმედიასთან მუშაობისთვის და პირველ პენტიუმებთან შედარებით. დაახლოებით ერთი წლის წინ გამოჩნდა Qt ბლოგი პოსტი. დეველოპერებმა შექმნეს Qt პორტი RTEMS OS-ისთვის და გამოუშვეს მაგალითები ვიჯეტებით რამდენიმე დაფაზე, რომელიც მუშაობს stm32f7. ეს გვაინტერესებდა. შესამჩნევი იყო და თავად დეველოპერები წერენ ამის შესახებ, რომ Qt ნელია STM32F7-Discovery-ზე. ჩვენ გვაინტერესებდა, შეგვეძლო თუ არა Qt-ის გაშვება Embox-ში და არა მხოლოდ ვიჯეტის დახატვა, არამედ ანიმაციის გაშვება.

Qt 4.8 უკვე დიდი ხანია პორტირებულია Embox-ში, ამიტომ გადავწყვიტეთ მისი გამოსაცდელად. ჩვენ ავირჩიეთ moveblocks აპლიკაცია - გაზაფხულზე ანიმაციის მაგალითი.

Qt ბლოკავს QEMU-ზე

დასაწყისისთვის, ჩვენ ვაკონფიგურირებთ Qt-ს, თუ ეს შესაძლებელია, ანიმაციის მხარდასაჭერად საჭირო კომპონენტების მინიმალური ნაკრებით. ამისათვის არის ვარიანტი "-qconfig მინიმალური, პატარა, საშუალო...". ის აკავშირებს კონფიგურაციის ფაილს Qt-დან ბევრ მაკროსთან - რა უნდა ჩართოთ / რა გამორთოთ. ამ პარამეტრის შემდეგ, ჩვენ ვამატებთ სხვა დროშებს კონფიგურაციაში, თუ გვსურს სხვა რამის გამორთვა. აი ჩვენი მაგალითი კონფიგურაცია.

იმისათვის, რომ Qt-მ იმუშაოს, თქვენ უნდა დაამატოთ OS თავსებადობის ფენა. ერთ-ერთი გზაა QPA (Qt Platform Abstraction) დანერგვა. ჩვენ საფუძვლად ავიღეთ Qt-ში ჩართული მზა fb_base მოდული, რომლის საფუძველზეც მუშაობს 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 მბ, რაც, რა თქმა უნდა, არ ჯდება STM32F746-ის მთავარ მეხსიერებაში. როგორც უკვე დავწერეთ ჩვენს სხვა სტატიაში OpenCV-ის შესახებ, ამ დაფას აქვს:

• 1 მბ ROM
• 320 KB ოპერატიული მეხსიერება
• 8 MB SDRAM
• 16 MB QSPI

ვინაიდან QSPI-დან კოდის შესრულების მხარდაჭერა უკვე დაემატა OpenCV-ს, ჩვენ გადავწყვიტეთ დავიწყოთ მთელი Embox c Qt სურათის QSPI-ში ჩატვირთვით. და რა, ყველაფერი თითქმის მაშინვე დაიწყო QSPI-დან! მაგრამ როგორც OpenCV-ის შემთხვევაში, აღმოჩნდა, რომ ის ძალიან ნელა მუშაობს.

ამიტომ, გადავწყვიტეთ ასე გაგვეკეთებინა - ჯერ სურათს ვაკოპირებთ QSPI-ში, შემდეგ ვტვირთავთ SDRAM-ში და ვასრულებთ იქიდან. SDRAM-დან ცოტა უფრო სწრაფი გახდა, მაგრამ QEMU-სგან მაინც შორს.

შემდეგ გაჩნდა იდეა მცურავი წერტილის ჩართვის - ბოლოს და ბოლოს, Qt აკეთებს ანიმაციაში კვადრატების კოორდინატების გარკვეულ გამოთვლებს. ჩვენ ვცადეთ, მაგრამ აქ ვერ მივიღეთ რაიმე ხილული აჩქარება, თუმცა შიგნით მუხლი Qt-ის დეველოპერებმა განაცხადეს, რომ FPU მნიშვნელოვნად ზრდის სიჩქარეს სენსორულ ეკრანზე "ანიმაციის გადასატანად". შეიძლება იყოს მნიშვნელოვნად ნაკლები მცურავი წერტილის გამოთვლები მოძრავ ბლოკებში და ეს დამოკიდებულია კონკრეტულ მაგალითზე.

ყველაზე ეფექტური იდეა იყო ფრეიმბუფერის გადატანა 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))

ROM-დან Embox კოდის შესრულებით, ჩვენ ასევე მივიღეთ შესამჩნევი აჩქარება. შედეგად, ანიმაცია საკმაოდ გლუვი აღმოჩნდა:

ბოლოს, სტატიის მომზადებისა და სხვადასხვა Embox კონფიგურაციების ცდისას, აღმოჩნდა, რომ Qt moveblocks მუშაობს QSPI-დან, SDRAM-ის ფრეიმბუფერით, და ბოთლი ზუსტად იყო ფრეიმბუფერის ზომა! როგორც ჩანს, საწყისი „სლაიდშოუს“ დასაძლევად საკმარისი იყო 2-ჯერადი აჩქარება ფრეიმბუფერის ზომის ბანალური შემცირების გამო. მაგრამ ასეთი შედეგის მიღწევა შეუძლებელი იყო მხოლოდ Embox კოდის სხვადასხვა სწრაფ მეხსიერებაზე გადატანით (აჩქარება იყო არა 2, არამედ დაახლოებით 1.5-ჯერ).

როგორ სცადოთ იგი საკუთარ თავს

თუ თქვენ გაქვთ STM32F7-Discovery, შეგიძლიათ თავად გაუშვათ Qt Embox-ის ქვეშ. თქვენ შეგიძლიათ წაიკითხოთ როგორ კეთდება ეს ჩვენს საიტზე wiki.

დასკვნა

შედეგად, ჩვენ მოვახერხეთ Qt! დავალების სირთულე, ჩვენი აზრით, გარკვეულწილად გადაჭარბებულია. ბუნებრივია, თქვენ უნდა გაითვალისწინოთ მიკროკონტროლერების სპეციფიკა და ზოგადად გაიგოთ კომპიუტერული სისტემების არქიტექტურა. ოპტიმიზაციის შედეგები მიუთითებს ცნობილ ფაქტზე, რომ გამოთვლით სისტემაში ბარიერი არ არის პროცესორი, არამედ მეხსიერება.

წელს ჩვენ მივიღებთ მონაწილეობას ფესტივალში TechTrain. იქ უფრო დეტალურად გეტყვით და ვაჩვენებთ Qt, OpenCV მიკროკონტროლერებზე და ჩვენს სხვა მიღწევებს.

წყარო: www.habr.com