14.1.1.3. Szimulátorok#

Két TARGET érték a firmware-t úgy építi fel, hogy az egy szimulátorban fusson a gazdagépeden, csatlakoztatott hardver nélkül. Azért léteznek, hogy a firmware bárhol futtatható és tesztelhető legyen.

TARGET

Mag

NPU

Szimulátor

MPS2_AN500

Cortex-M7

Nincs

QEMU

MPS3_AN547

Cortex-M55

Ethos-U55 (256 MACs)

Arm FVP – Corstone SSE-300

Az MPS2_AN500 az alap Cortex-M7 cél NPU nélkül. QEMU alatt fut, amely gyorsan indul, és a könnyűsúlyú módja a platformfüggetlen kód és a tesztcsomag gyakorlatoztatásának.

Az MPS3_AN547 egy Cortex-M55 az Ethos-U55 NPU-val, amely az Arm Fast Models- on – az FVP-n – fut, amely a Corstone SSE-300 referencia-alrendszert modellezi. Ez a cél az NPU és az ML-modell útvonal szimulációban való gyakorlatoztatásához.

Mindkettő biztosítja a ROM-fájlrendszert és bőséges RAM-ot (és az NPU-t az M55-ön), így a látó- és ML-szkriptek módosítás nélkül futnak.

Nincs valódi érzékelő, de a csi modul továbbra is működik egy virtuális ellen – a csi.CSI.snapshot() egy szintetikus, animált tesztmintát ad vissza (egy görgetődő sakktáblát szürkeárnyalatosban, egy színátmenetet RGB565-ben), nem élő jelenetet. Valódi képtartalom feldolgozásához töltsd be inkább egy fájlból: egy image.Image-et a ROM-fájlrendszerben lévő rögzítményből, vagy egy image.ImageIO adatfolyamot rögzített képkockákhoz.

14.1.1.3.1. Felépítés és futtatás#

Minden szimulátor egy gazdagépi eszköz, amelyet magad telepítesz. Egy célt ugyanúgy építesz fel, mint bármely mást (lásd A firmware felépítése), majd a run paranccsal futtatod a megfelelő szimulátor alatt – a run felépíti a ROMFS-képet, elindítja a firmware-t, és futva hagyja egy soros kapcsolattal, amelyhez csatlakozhatsz.

14.1.1.3.1.1. MPS2_AN500 (QEMU)#

A QEMU a legtöbb csomagkezelőben Arm rendszeremulátorként szállítódik:

  • Linux (Debian / Ubuntu) – telepítsd az apt-tal:

    sudo apt install qemu-system-arm
    
  • macOS – telepítsd a Homebrew-val:

    brew install qemu
    

Ezután építsd fel és futtasd a célt:

make -j$(nproc) TARGET=MPS2_AN500
make TARGET=MPS2_AN500 run

14.1.1.3.1.2. MPS3_AN547 (Arm FVP)#

Az FVP az Arm Fixed Virtual Platformja a Corstone SSE-300-hoz, amely az Arm Virtual Hardware részeként szállítódik. Csak Linuxra érhető el – Macen használd inkább a fenti QEMU-célt.

Töltsd le a csomagot, csomagold ki, és tedd a bin/ könyvtárát a PATH-odra:

wget https://artifacts.tools.arm.com/avh/11.31.28/avh-linux-x86_11.31_28_Linux64.tar.gz
mkdir -p ~/fvp
tar --strip-components=1 -xzf avh-linux-x86_11.31_28_Linux64.tar.gz -C ~/fvp
export PATH="$HOME/fvp/bin:$PATH"

Az FVP-nek futtatáskor az SDK Python-könyvtáraira is szüksége van az LD_LIBRARY_PATH-on. Exportáld egyszer parancsértelmezőnként a repó gyökeréből – az SDK_VERSION beolvasása helyesen tartja, ahogy a repó frissíti a rögzített SDK-t:

export LD_LIBRARY_PATH="$HOME/openmv-sdk-$(cat SDK_VERSION)/python/lib:$LD_LIBRARY_PATH"

Ezután építsd fel és futtasd a célt:

make -j$(nproc) TARGET=MPS3_AN547
make TARGET=MPS3_AN547 run

14.1.1.3.2. A tesztcsomag futtatása#

Az egységtesztek a scripts/unittest/tests/ könyvtárban élnek, a rögzítményképeikkel és adataikkal a scripts/unittest/data/ könyvtárban. Az mpremote paranccsal futnak, amely felcsatolja a scripts/unittest/ könyvtárat a futó szimulátorra, és végrehajtja annak run.py fájlját.

A szimulátor-kapcsolat lassú a gyári mpremote-tal, ezért használd a repóban mellékelt példányt az alkalmazott soros javítással (alkalmazd egyszer):

patch -N -p1 -d lib/micropython < tools/mpremote-qemu-serial.patch

Az MPS2_AN500 esetén QEMU alatt indítsd el a célt – kiírja azt a pszeudoterminált, amelyen a soros portja van (például /dev/pts/5):

make TARGET=MPS2_AN500 run

Ezután egy másik parancsértelmezőből irányítsd a javított mpremote-ot arra az eszközre:

python3 lib/micropython/tools/mpremote/mpremote.py connect /dev/pts/5 \
    mount scripts/unittest/ run scripts/unittest/run.py

Az MPS3_AN547 esetén az FVP alatt a soros port helyette egy telnet-foglalat az 5555-ös porton:

make TARGET=MPS3_AN547 run
python3 lib/micropython/tools/mpremote/mpremote.py connect socket://localhost:5555 \
    mount scripts/unittest/ run scripts/unittest/run.py

A run.py felfedezi és végrehajtja az összes tesztet, tesztenként kiír egy PASSED / FAILED sort az időzítéssel, a végén pedig egy összefoglalót.

14.1.1.3.3. Teszt hozzáadása#

A teszteket automatikusan felfedezi a rendszer. Egy hozzáadásához tegyél egy fájlt a scripts/unittest/tests/ könyvtárba, amely definiál egy unittest(data_path, temp_path) függvényt, amely True-t ad vissza, ha a teszt sikeres, és False-t, ha sikertelen:

# scripts/unittest/tests/circles.py
def unittest(data_path, temp_path):
    import image

    img = image.Image(data_path + "/shapes.ppm", copy_to_fb=True)
    circles = img.find_circles(threshold=5000, x_margin=30, y_margin=30, r_margin=30)
    return len(circles) == 1 and circles[0][0:] == (118, 56, 22, 5856)

A data_path és temp_path argumentumok arra a két fájlrendszerre mutatnak, amelyet a szimulátor lát, amíg a csomag fut:

Útvonal

Mögötte

/remote

A gazdagép scripts/unittest/ könyvtára, élőben felcsatolva az mpremote kapcsolaton keresztül. A run.py és az általa felfedezett tests/ itt él, így egy teszt hozzáadása vagy szerkesztése a következő futtatáskor érvénybe lép újraépítés nélkül. A temp_path az eszközön /remote/temp, ami a gazdagéped scripts/unittest/temp/ könyvtára – egy írható ideiglenes könyvtár a fájlokat létrehozó tesztekhez.

/rom

A lap csak olvasható ROM-fájlrendszere, amely a firmware-képbe a romfs_config.json-ból épül be: a tesztrögzítmények (a scripts/unittest/data/ könyvtárból) és a mellékelt ML-modellek. A data_path a /rom – egy rögzítményt a data_path + "/<file>" formában érsz el.

Tehát egy új teszt nem igényel újraépítést, de egy új rögzítmény igen: a ROM-kép a romfs_config.json-hoz van kötve, nem az egyes adatfájlokhoz, ezért kényszerítsd ki az újraépítést a lap romfs_config.json fájljának érintésével (vagy a make TARGET=<TARGET> clean-nel), és futtasd újra.

A várt értékek a tesztben sorba ágyazva vannak állítva, így nincs külön elvárt kimeneti fájl, amelyet karban kellene tartani. Egy teszt futás közbeni kihagyásához – például amikor olyan hardvert igényel, amelyet a szimulátor nem modellez – válts ki egy kivételt, amelynek üzenete tartalmazza a "SKIPPED" szöveget.