Olen üks operatsioonisüsteemi arendajatest Embox, ja selles artiklis rääkisin sellest, kuidas suutsin OpenCV-d STM32746G plaadil käivitada.

Kui otsingumootorisse sisestada midagi sellist nagu «OpenCV on STM32 board», siis leiab üsna palju inimesi, kes on huvitatud selle biblioteka kasutamisest STM32 plaatidel või teistel mikroprotsessoritel.
On mitmeid videoid, mis pealkirja põhjal peaksid demonstreerima seda, mida on vaja, kuid tavaliselt (kõigis videot, mida olen näinud) on STM32 plaadil tehtud ainult pildi saamine kaamerast ja tulemuse kuvamine ekraanil, samas kui pildi töötlemine toimus kas tavalises arvutis või võimsamatel plaatidel (näiteks Raspberry Pi).

Miks see on keeruline?

Otsingupäringute populaarsus on tingitud sellest, et OpenCV on kõige populaarsem arvutinägemise teek, seega on paljud arendajad selle eest tuttavad, ja võimalus käivitada lauaarvutiks mõeldud kood mikroprotsessoril lihtsustab arendamisprotsessi. Kuid miks ei ole siiani populaarseid lahenduste retsepte selle probleemi lahendamiseks?

OpenCV kasutamise probleem väiksematel plaatidel on seotud kahe omadusega:

Kui teegi isegi minimaalse moodulite kogumiga kokku panna, siis STM32F7Discovery välkmälusse lihtsalt ei mahu (isegi ilma operatsioonisüsteemita) väga suure koodi tõttu (mitu megabaidi instruktsioone)
Ise teek on kirjutatud C++-s, seega
- On vajalik C++ jooksuta teatamine (erandid jne)
- Vähe LibC/Posix toe, mis tavaliselt on integreeritud süsteemide opsüsteemidesse — on vajalik C++ standardraamatukogu ja STL malliraamatukogu (vector jne)

Portimine Emboxi

Nagu tavaliselt, enne kui porteerite mõnda programmide opsüsteemi, on hea proovida see koguda sellisel kujul, nagu arendajad selle ette nägid. Meie juhul ei ole sellega probleeme — algkoodid on saadaval GitHubis, teeki saab GNU/Linux'is tavalise cmake abil kokku panna.

Headest uudistest — OpenCV-d saab otse väljaõppe kaudu kokku panna staatilise teegina, mis muudab portimise lihtsamaks. Kogume teegi standardse config-iga ja vaatame, palju ruumi nad kasutavad. Iga moodul kogutakse eraldi teegina.

> 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)

Viimane rida näitab, et .bss ja .data ei võta palju ruumi, kuid koodi on enam kui 70 MiB. On selge, et kui see staatiliselt kindla rakendusega siduda, siis koodi maht väheneb.

Proovime eemaldada võimalikult palju mooduleid, et koostada minimaalne näide (mis näiteks lihtsalt kuvab OpenCV versiooni), nii et vaatame. cmake .. -LA ja blokeerime kõik valikutes, mida on võimalik blokeerida.

        -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, see on ainult üks teegi moodul, teiselt poolt, see pole koodi suuruse optimeerimise tõttu (-Os). ~3 MiB koodi – see on ikka veel piisavalt palju, kuid annab juba lootust edule.

Käivitamine emulaatoris

Emulaatoris on lihtsam siluda, seega veendume kõigepealt, et teek töötab qemu-s. Emuleeritud platvormiks valisin Integrator/CP, kuna esiteks on see samuti ARM ja teiseks toetab Embox selle platvormi jaoks graafika väljundit.

Emboxil on mehhanism väliste teekide kompileerimiseks, millega lisame OpenCV moodulina (edastades kõik samad valikud «minimaalse» töötlemise jaoks staatiliste teekidena), pärast seda lisan kõige lihtsama rakenduse, mis näeb välja järgmiselt:

version.cpp:

#include 
#include 

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

    return 0;
}

Kompileerime süsteemi, käivitame – saame oodatud väljundi.

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

  Platvorm:
    Aeg:                          2019-06-21T10:02:18Z
    Host:                        Linux 5.1.7-arch1-1-ARCH x86_64
    Sihitarget:                  Üldine arm-unknown-none
    CMake:                       3.14.5
    CMake generaator:            Unix Makefiles
    CMake ehitusvahend:         /usr/bin/make
    Konfiguratsioon:             Debug

  CPU/HW omadused:
    Alus:
      nõutud:                    DETECT
      keelatud:                  VFPV3 NEON

  C/C++:
    Ehitatud dünaamilisteks teekideks?:      EI

 Edasi on teised kogumise parameetrid - milliste lippudega see kompileeritud on,
  millised OpenCV moodulid on kogumisse kaasatud jne.

Järgmine samm on käivitada mõni näidis, parem oleks mõni standardne, mida arendajad ise pakuvad. oma veebilehel. Ma valisin Canny servade detektori.

Näidis tuli natuke ümber kirjutada, et tulemus otse frame bufferisse kuvada. Seda tuli teha, kuna funktsioon imshow() oskab pilte kuvada QT, GTK ja Windowsi liideste kaudu, mida STM32 seadistuses kindlasti ei ole. Tegelikult saab QT-d ka STM32F7Discovery-l käivitada, aga sellest räägitakse juba teises artiklis 🙂

Pärast lühikest arutelu, millises formaadis servade detektori töö tulemus hoitakse, saame pildi.

Originaalpilt

Tulemus

Käivitus STM32F7Discovery-l

32F746GDISCOVERY-l on mitu mälusegmenti, mida saame erinevalt kasutada

320KiB järgnevat mälu
1MiB välkmälu pildifaili jaoks
8MiB SDRAM
16MiB QSPI NAND välkmälukaart
microSD mälukaardi pesad

SD-kaarti saab kasutada piltide salvestamiseks, kuid minimaalse näidise käitamise kontekstis ei ole see eriti kasulik.
Ekraanil on eraldusvõime 480×272, seega frame bufferi mälu suurus on 522 240 baiti 32-bitise sügavusega, st see on suurem kui operatiivmälu suurus, seega frame buffer ja hunnik (mis on vajalik ka OpenCV jaoks, et hoida andmeid piltide ja abistruktuuride jaoks) asub SDRAM-is, kõik muu (mälu stekkide ja muude süsteemivajaduste jaoks) saadetakse RAM-i.

Kui võtta STM32F7Discovery minimaalne konfiguratsioon (kõik võrgud välja visata, kõik käsud, stekke võimalikult väikesteks teha jne) ja lisada sinna OpenCV koos näidistega, on nõutav mälu järgmine:

   text    data     bss     dec     hex filename
2876890  459208  312736 3648834  37ad42 build/base/bin/embox

Nende jaoks, kes ei ole eriti tuttavad sellega, kuhu sektsioonid paigutatakse, selgitan: .text ja .rodata sisaldavad juhiseid ja konstande (lihtsalt öeldes, readonly-andmeid), .data sisaldavad muudetavaid andmeid, .bss sisaldab nullitud muutujaid, millele tuleb siiski koht anda (see sektsioon "läheb" RAM-i).

Hea uudis on see, et .data/.bss peavad mahutama, aga probleem on selles, et .text ruumi on ainult 1MiB. Näiteks saab näidisekraanist pildi eemaldada ja lugeda seda SD-kaardilt mällu käivitamisel, aga fruits.png kaalub umbes 330KiB, nii et see probleem ei lahenda: suurem osa .text koostis on tõepoolest OpenCV kood. .text Põhimõtteliselt jääb üle vaid üks — laadida koodi osa QSPI-mälupulgale (sel on spetsiaalne töörežiim, mis võimaldab mälu süsteembussile kaardistada, mistõttu protsessor saab neile andmetele otse juurde pääseda). Kuid on üks probleem: esiteks, QSPI-mälupulga mälu ei ole kohe pärast seadme taaskäivitamist saadaval (moodul tuleb eraldi initsialiseerida), teiseks ei saa seda mälupulka tavalise laadijaga "välja kirjutada".

Lõpuks otsustati siduda kogu kood QSPI-sse ja kirjutada selle peale kohandatud laadija, mis saab vajaliku binaari TFTP kaudu.

Idee portida see teek Emboxile tekkis umbes aasta tagasi, kuid see lükati korduvalt edasi erinevatel põhjustel. Üks neist on libstdc++ ja standardne malliraamatukogu toetus. C++ toetuse probleem Emboxis jääb sellest artiklist väljapoole, seega ütlen vaid, et meil õnnestus saavutada vajaliku mahuga toetus selle teegi jaoks 🙂

Tulemus

Lõppkokkuvõttes need probleemid ületati (vähemalt piisavas ulatuses OpenCV näidise tööks) ja näidis käivitus. 40 pikka sekundit võtab arvel servade leidmine Canny filtriga. See on muidugi liiga pikk (on mõtteid, kuidas seda optimeerida, sellest võiks kirjutada eraldi artikli juhul, kui see õnnestub).

Siiski oli vahe-eesmärk luua prototüüp, mis näitab põhimõttelist võimalust käivitada OpenCV STM32-l, seega see eesmärk saavutati, hurraa!

tl;dr: samm-sammuline juhend

0: Laadige Emboxi allikakoodid alla, näiteks nii:

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

    1: Alustame laadija kogumisega, mis "välja kirjutab" QSPI mälupulga.

make confload-arm/stm32f7cube

    tee confload-arm/stm32f7cube

Nüüd tuleb seadistada võrk, kuna me laadime kujutise TFTP kaudu. IP-aadresside seadmiseks plaadil ja hostil 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

värav — hosti aadress, kust kuvandi laadimine toimub, aadress — seadme aadress.

Pärast seda kogume käivitaja:

tee

2: Tavaline käivitaja laadimine seadmele (palun vabandage mängu sõna) — siin pole midagi spetsiifilist, seda tuleb teha nagu iga teise rakenduse puhul STM32F7Discovery jaoks. Kui te ei tea, kuidas seda teha, saate lugeda sellest siit.
3: Kujutise kompileerimine OpenCV konfiguratsiooniga.

    make confload-platform/opencv/stm32f7discovery
    make

4: ELF sektsioonide eraldamine, mis tuleb kirjutada QSPI-sse, faili 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, seega on võimalik see käivitada

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

5: TFTP abil laadime qspi.bin.bin QSPI-mälupulgale. Hostis tuleb qspi.bin kopeerida tftp-serveri juurkaustasse (tavaliselt on see /srv/tftp/ või /var/lib/tftpboot/; vastava serveri paketid on enamiku populaarsete distributsioonide jaoks olemas, tavaliselt nimetatakse tftpd või tftp-hpa, mõnikord tuleb teha systemctl start tftpd.service selle 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. käivitajas) tuleb sisestada selline käsk (eeldades, 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üpata" QSPI-mälu. Konkreetne asukoht võib varieeruda sõltuvalt sellest, kuidas kujutis linkitakse, seda aadressi saab vaadata käsuga mem 0x90000000 (algusaadress on teise 32-bitise sõna kujutisest); samuti on vajalik seada virna märk sümboliga -s, virna aadress asub aadressil 0x90000000, näide:

    embox>mem 0x90000000
    0x90000000:     0x20023200  0x9000c27f  0x9000c275  0x9000c275
                      ↑           ↑
              see aadress    see  aadress 
                virnast        esimese
                           käsu

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

7: Käivitame