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.
| Mag | NPU | Szimulátor |
|---|---|---|---|
| Cortex-M7 | Nincs | QEMU |
| 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-armmacOS – 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 |
|---|---|
| A gazdagép |
| A lap csak olvasható ROM-fájlrendszere, amely a firmware-képbe a |
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.