Olen üks operatsioonisüsteemi arendajatest Embox, ja selles artiklis jutustan, kuidas mul õnnestus OpenCV käivitada STM32746G plaadil.

Kui otsida midagi sarnast nagu «OpenCV on STM32 plaadil», võib leida päris palju inimesi, kes huvituvad selle teegi kasutamisest STM32 või teiste mikrokontrollerite peal.
On mitmeid videoid, mis pealkirja järgi peaksid näitama vajalikku, kuid tavaliselt (kõikides videotest, mida olen näinud) tehti STM32 plaadil ainult kaamerapildi saamine ja tulemuse kuvamine ekraanil, samas kui pilditöötlus tehti kas tavalisel arvutil või võimsamatel plaatidel (nt Raspberry Pi).

Miks see on keeruline?

Otsingupäringute populaarsus selgitab, et OpenCV on kõige populaarsem arvutinägemise teek, seega on rohkem arendajaid sellega tuttavad, ja võimalus käivitada laua jaoks valmis kood mikrokontrolleril lihtsustab arendusprotsessi märkimisväärselt. Aga miks siiani pole populaarseid valmis lahendusi selle probleemi jaoks?

Probleem OpenCV kasutamisega väikestel plaatidel on seotud kahe omadusega:

• Kui isegi minimaalsete moodulitega kogu teek kompileerida, ei mahu see sama STM32F7Discovery välkmällu (isegi ilma operatsioonisüsteemita) liiga suure koodi tõttu (mitu megabaidi käsu).
• Teek ise on kirjutatud C++-s, seega
  • on vajalik C++ käitusaeg (välja arvatud ja muud).
  • Puudub LibC/Posix tugi, mida tavaliselt leidub sisseehitatud süsteemide operatsioonisüsteemides — vajalik on C++ standardteek ja STL standardteek (näiteks vektor ja nii edasi).

Portimine Emboxile

Kuna enne mõne programmi portimist operatsioonisüsteemi on alati hea proovida seda koguda just sellisena, nagu arendajad ette nägid. Meie juhul ei teki selle probleemiga mingeid raskusi — allikaid saab leida GitHubis, teek kogutakse GNU/Linuxi tavapärase cmake abil.

Hea uudis on see, et OpenCV-d saab välja pakkuda staatilise teekina, mis muudab portimise lihtsamaks. Kogume teeki tavalise konfigureerimisega ja vaatame, kui palju ruumi see nõuab. Iga moodul kogutakse eraldi teekina.

> size lib/*so --totals
   text    data     bss     dec     hex filename
1945822   15431     960 1962213  1df0e5 lib/libopencv_calib3d.so
17081885     170312   25640 17277837    107a38d lib/libopencv_core.so
10928229     137640   20192 11086061     a928ed lib/libopencv_dnn.so
 842311   25680    1968  869959   d4647 lib/libopencv_features2d.so
 423660    8552     184  432396   6990c lib/libopencv_flann.so
8034733   54872    1416 8091021  7b758d lib/libopencv_gapi.so
  90741    3452     304   94497   17121 lib/libopencv_highgui.so
6338414   53152     968 6392534  618ad6 lib/libopencv_imgcodecs.so
21323564     155912  652056 22131532    151b34c lib/libopencv_imgproc.so
 724323   12176     376  736875   b3e6b lib/libopencv_ml.so
 429036    6864     464  436364   6a88c lib/libopencv_objdetect.so
6866973   50176    1064 6918213  699045 lib/libopencv_photo.so
 698531   13640     160  712331   ade8b lib/libopencv_stitching.so
 466295    6688     168  473151   7383f lib/libopencv_video.so
 315858    6972   11576  334406   51a46 lib/libopencv_videoio.so
76510375     721519  717496 77949390    4a569ce (TOTALS)

Nagu viimasest reast näha, võtab .bss ja .data mitte palju ruumi, kuid kood on üle 70 MiB. On selge, et kui see linkida staatiliselt konkreetse rakendusega, väheneb koodi maht.

Proovime eemaldada nii palju mooduleid kui võimalik, et koguda minimaalne näide (mis näiteks lihtsalt kuvab OpenCV versiooni), seega vaatame cmake .. -LA ja lülitame valikutes välja kõik, mis välja lülitatav on.

        -DBUILD_opencv_java_bindings_generator=OFF 
        -DBUILD_opencv_stitching=OFF 
        -DWITH_PROTOBUF=OFF 
        -DWITH_PTHREADS_PF=OFF 
        -DWITH_QUIRC=OFF 
        -DWITH_TIFF=OFF 
        -DWITH_V4L=OFF 
        -DWITH_VTK=OFF 
        -DWITH_WEBP=OFF

> size lib/libopencv_core.a --totals
   text    data     bss     dec     hex filename
3317069   36425   17987 3371481  3371d9 (TOTALS)

Ühelt poolt on see ainult üks raamatukogu moodul, teiselt poolt, see on ilma koodi suuruse optimeerimiseta (-Os). ~3 MiB koodi — see on endiselt piisavalt palju, kuid juba annab lootust edule.

Käivitamine emulaatoris

Emulaatoris on palju lihtsam debugida, seega veendume esmalt, et teek töötab qemu-s. Emuleeritavaks platvormiks valisin Integrator/CP, kuna see on ka ARM ja Embox toetab selle platvormi graafikat.

Emboxis on mehhanism väliste raamatukogude kogumiseks, millega lisame OpenCV moodulina (kandes kõik samad valikud „minimaalse“ kogumise jaoks staatiliste raamatukogude kujul), seejärel lisan lihtsa rakenduse, mis näeb välja järgmiselt:

version.cpp:

#include 
#include 

int main() {
    printf("OpenCV: %s", cv::getBuildInformation().c_str());

    return 0;
}

Kogume süsteemi, käivitame — saame oodatud väljundi.

root@embox:/#opencv_version                                                     
OpenCV: 
OpenCV 4.0.1 üldine konfiguratsioon =====================================
  Versioonikontroll:               bd6927bdf-dirty

  Platvorm:
    Ajastamine:                   2019-06-21T10:02:18Z
    Alus:                        Linux 5.1.7-arch1-1-ARCH x86_64
    Siht:                      Üldine arm-unknown-none
    CMake:                       3.14.5
    CMake generaator:             Unix Makefiles
    CMake ehitustööriist:            /usr/bin/make
    Konfiguratsioon:               Debug

  CPU/HW omadused:
    Baas:
      taotletud:                 DETECT
      keelatud:                  VFPV3 NEON

  C/C++:
    Koostatud dünaamiliste teekidena?:      EI

Järgmine samm on käivitada mõni näide, parim on valida mõni standardne, mida pakuvad arendajad ise. oma veebilehelt. Valisin Canny servade detektori.

Näidet tuli veidi ümber kirjutada, et kuvada tulemust otse raami puhveris. See tuli teha, kuna funktsioon imshow() suudab kuvada pilte läbi QT, GTK ja Windowsi liideste, mida STM32 kontekstis kindlasti ei ole. Tegelikult saab QT-d samuti käivitada STM32F7Discovery-l, aga sellest räägitakse juba teises artiklis 🙂

Pärast lühikest uurimist, millises formaadis piiride tuvastamise tulemused salvestatakse, saame pildi.

Originaalpilt

Tulemus

Käivitus STM32F7Discovery-l

32F746GDISCOVERY-l on mitu riistvara mälusegmenti, mida saame kasulikult kasutada.

1. 320KiB töömälu
2. 1MiB välkmälu pildi jaoks
3. 8MiB SDRAM
4. 16MiB QSPI NAND-mälupulk
5. MicroSD-kaardi pesa

SD-kaarti võib kasutada piltide salvestamiseks, kuid minimaalsete näidete käivitamise kontekstis pole see eriti kasulik.
Kuva eraldusvõime on 480×272, seega frame bufferi mälu suurus on 522 240 baiti 32-bitise sügavuse juures, mis tähendab, et see on suurem kui töömälu, seega paigaldame frame bufferi ja hunniku (mis on vajalik ka OpenCV jaoks piltide ja abistruktuuride andmete salvestamiseks) SDRAM-i, kõik muu (mälu rõngaste ja teiste süsteemivajaduste jaoks) saadetakse RAM-i.

Kui võtta minimaalne konfiguratsioon STM32F7Discovery jaoks (eemaldada kogu võrk, kõik käsud, teha virnad võimalikult väikseks jne) ja lisada sinna OpenCV näidetega, siis vajalik mälu oleks järgmine:

   tekst    andmed     bss     dec     hex failinimi
2876890  459208  312736 3648834  37ad42 build/base/bin/embox

Need for those who are not very familiar with where the sections go, I'll explain: in .text ja .rodata lie instructions and constants (roughly speaking, readonly data), in .data lie modifiable data, in .bss lie "zeroed" variables, which still need space (this section will "go" into RAM).

The good news is that .data/.bss must fit, but the trouble is .text there's only 1MiB of memory for the image. You can remove the image from the example and read it, for instance, from an SD card into memory at startup, but fruits.png weighs about 330KiB, so that won't solve the problem: most of the .text näiteks näha ja lugeda pilti SD-kaardilt käivitamisel, kuid fruits.png kaalub umbes 330KiB, seega see probleem ei lahenda: enamik .text consists precisely of OpenCV code.

Basically, there’s only one option left — loading part of the code onto the QSPI flash (it has a special operating mode for memory mapping on the system bus, so the processor can directly access this data). However, there’s a problem: first, QSPI flash memory is not available immediately after rebooting the device (you need to separately initialize memory-mapped mode), and second, you can't "flash" this memory with a conventional bootloader.

Lõpuks otsustati sünkroonida kogu kood QSPI-sse ja kirjutada see oma laadimisseadmestikku, mis saab vajaliku binaari TFTP kaudu.

Tulemus

Idee portida see teek Emboxile tekkis umbes aasta tagasi, kuid mitmel põhjusel on see korduvalt edasi lükatud. Üks neist põhjustest on libstdc++ ja standardne mallide teek. C++ toe toimetamine Emboxis ületab selle artikli raames käsitletava teema ulatuse, seega ütlen lihtsalt, et oleme suutnud saavutada vajaliku toetuse selle teegi tööks 🙂.

Lõpuks saadi need probleemid ületatud (vähemalt piisavalt, et OpenCV näide töötaks) ning näide käivitus. Plaadil kulus 40 pikemat sekundit servade tuvastamiseks Canny filtriga. See on muidugi liiga kaua (on ideid, kuidas seda optimeerida, sellest võiks kirjutada eraldi artikli, kui see õnnestub).

Küll aga oli vahe-eesmärk prototüübi loomine, mis näitaks OpenCV käitamise põhimõttelise võimaluse STM32-l, seega on see eesmärk saavutatud, hurraa!

tl;dr: samm-sammuline juhend

0: Laadige Emboxi lähtekood, näiteks nii:

    git clone https://github.com/embox/embox && cd ./embox

1: Alustame käivituslaadija koostamisest, mis "programmeerib" QSPI mälupulga.

    make confload-arm/stm32f7cube

Nüüd tuleb seadistada võrk, kuna laadime kujundi TFTP kaudu. Arvutite ja hosti IP-aadresside määramiseks tuleb muuta faili conf/rootfs/network.

Konfiguratsiooni näidis:

iface eth0 inet static
    address 192.168.2.2
    netmask 255.255.255.0
    gateway 192.168.2.1
    hwaddress aa:bb:cc:dd:ee:02

gateway — hosti aadress, kust pilt laaditakse, address — seadme aadress.

Pärast seda koondame laadija:

    make

2: Tavaline laadimine laadijale (palun andke andeks mäng sõnadega) seadmesse — siin pole midagi spetifilist, tuleb seda teha nagu igasuguste muude rakenduste puhul STM32F7Discovery jaoks. Kui te ei tea, kuidas seda teha, võite sellest lugeda siin.
3: Pildi kompileerimine OpenCV konfigureerimisega.

    make confload-platform/opencv/stm32f7discovery
    make

4: Sektsioonide väljavõtmine ELF-ist, mis tuleb QSPI-sse kirjutada, failis qspi.bin

    arm-none-eabi-objcopy -O binary build/base/bin/embox build/base/bin/qspi.bin 
        --only-section=.text --only-section=.rodata 
        --only-section='.ARM.ex*' 
        --only-section=.data

Kaustas conf on skript, mis seda teeb, nii et saate selle käivitada

    ./conf/qspi_objcopy.sh # Vajalik binaar -- build/base/bin/qspi.bin

5: Tftp abil laadime qspi.bin.bin QSPI-mälupulgale. Selleks tuleb hostis kopeerida qspi.bin tftp-serveri juurkatalooge (tavaliselt on see /srv/tftp/ või /var/lib/tftpboot/; vajalikud paketid on saadaval enamikus tuntud distributsioonides, neid nimetatakse tavaliselt tftpd või tftp-hpa, mõnikord tuleb teha systemctl start tftpd.service käivitamiseks).

    # вариант для tftpd
    sudo cp build/base/bin/qspi.bin /srv/tftp
    # вариант для tftp-hpa
    sudo cp build/base/bin/qspi.bin /var/lib/tftpboot

Emboxis (st laadijana) tuleb täita järgmine käsk (eeldame, et serveri aadress on 192.168.2.1):

    embox> qspi_loader qspi.bin 192.168.2.1

6: Käsk goto on vajalik, et "hüppata" QSPI-mällu. Konkreetne asukoht varieerub sõltuvalt sellest, kuidas pilt linkib, seda aadressi saab vaadata käsuga mem 0x90000000 (algus aadress mahtus pildi teise 32-bitise sõna); lisaks tuleb seadistada suurus lippudega -s, steki aadress asub aadressil 0x90000000, näiteks:

    embox>mem 0x90000000
    0x90000000:     0x20023200  0x9000c27f  0x9000c275  0x9000c275
                      ↑           ↑
              see aadress    see aadress 
                stekist        esimese
                           instruktsiooni

    embox>goto -i 0x9000c27f -s 0x20023200 # Lipp -i on vajalik, et keelata katkestused süsteemi initsialiseerimise ajal

7: Käivitame

    embox> servad 20

ja naudime 40-sekundiliste piiride otsingut 🙂

Kui miski läheb valesti, siis kirjutage issue meie reposse, või embox-devel@googlegroups.com listi, või kommenteerige siin.

Allikas: habr.com