14.1.1.3. Simulateurs#

Deux valeurs de TARGET compilent le micrologiciel pour qu’il s’exécute à l’intérieur d’un simulateur sur votre hôte, sans matériel connecté. Elles existent pour que le micrologiciel puisse être exécuté et testé partout.

TARGET

Cœur

NPU

Simulateur

MPS2_AN500

Cortex-M7

Aucun

QEMU

MPS3_AN547

Cortex-M55

Ethos-U55 (256 MACs)

Arm FVP – Corstone SSE-300

MPS2_AN500 est la cible Cortex-M7 de base sans NPU. Elle s’exécute sous QEMU, qui démarre rapidement et constitue la manière légère d’exercer le code indépendant de la plateforme et la suite de tests.

MPS3_AN547 est un Cortex-M55 doté du NPU Ethos-U55, exécuté sur les Fast Models d’Arm – le FVP, qui modélise le sous-système de référence Corstone SSE-300. C’est la cible pour exercer le NPU et le chemin du modèle ML en simulation.

Les deux fournissent le système de fichiers ROM et une RAM abondante (ainsi que le NPU sur le M55), de sorte que les scripts de vision et de ML s’exécutent sans modification.

Il n’y a pas de véritable capteur, mais le module csi fonctionne tout de même avec un capteur virtuel – csi.CSI.snapshot() renvoie une mire de test synthétique et animée (un damier défilant en niveaux de gris, un dégradé en RGB565), pas une scène en direct. Pour traiter un contenu d’image réel, chargez-le plutôt depuis un fichier : une image.Image issue d’un fixture du système de fichiers ROM, ou un flux image.ImageIO pour des trames enregistrées.

14.1.1.3.1. Compilation et exécution#

Chaque simulateur est un outil hôte que vous installez vous-même. Vous compilez une cible comme n’importe quelle autre (voir Compiler le micrologiciel), puis vous l’exécutez avec run sous le simulateur correspondant – run construit l’image ROMFS, démarre le micrologiciel et le laisse en cours d’exécution avec une connexion série à laquelle vous pouvez vous attacher.

14.1.1.3.1.1. MPS2_AN500 (QEMU)#

QEMU est disponible dans la plupart des gestionnaires de paquets en tant qu’émulateur système Arm :

  • Linux (Debian / Ubuntu) – installez-le avec apt

    sudo apt install qemu-system-arm
    
  • macOS – installez-le avec Homebrew

    brew install qemu
    

Compilez ensuite et exécutez la cible

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

14.1.1.3.1.2. MPS3_AN547 (Arm FVP)#

Le FVP est la Fixed Virtual Platform d’Arm pour le Corstone SSE-300, fournie dans le cadre de Arm Virtual Hardware. Il n’est disponible que sous Linux – sur un Mac, utilisez plutôt la cible QEMU ci-dessus.

Téléchargez le bundle, extrayez-le et placez son répertoire bin/ dans votre PATH

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"

Le FVP a aussi besoin des bibliothèques Python du SDK dans LD_LIBRARY_PATH lorsqu’il s’exécute. Exportez-le une fois par shell depuis la racine du dépôt – lire SDK_VERSION le maintient correct à mesure que le dépôt met à jour le SDK épinglé

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

Compilez ensuite et exécutez la cible

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

14.1.1.3.2. Exécution de la suite de tests#

Les tests unitaires résident dans scripts/unittest/tests/, avec leurs images de fixture et leurs données dans scripts/unittest/data/. Ils sont exécutés avec mpremote, qui monte scripts/unittest/ sur le simulateur en cours d’exécution et exécute son run.py.

Le lien du simulateur est lent avec mpremote standard, utilisez donc la copie fournie dans le dépôt avec le correctif série appliqué (appliquez-le une fois)

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

Pour MPS2_AN500 sous QEMU, démarrez la cible – elle affiche le pseudo-terminal sur lequel se trouve son port série (par exemple /dev/pts/5)

make TARGET=MPS2_AN500 run

Ensuite, depuis un autre shell, pointez le mpremote corrigé vers ce périphérique

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

Pour MPS3_AN547 sous le FVP, le port série est plutôt une socket telnet sur le port 5555

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

run.py découvre et exécute chaque test, affichant une ligne PASSED / FAILED par test avec le chronométrage et un récapitulatif à la fin.

14.1.1.3.3. Ajout d’un test#

Les tests sont découverts automatiquement. Pour en ajouter un, déposez dans scripts/unittest/tests/ un fichier qui définit une fonction unittest(data_path, temp_path) renvoyant True lorsque le test réussit et False lorsqu’il échoue

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

Les arguments data_path et temp_path pointent vers les deux systèmes de fichiers que le simulateur voit pendant l’exécution de la suite :

Chemin

Soutenu par

/remote

Le répertoire scripts/unittest/ de l’hôte, monté en direct via la connexion mpremote. run.py et les tests/ qu’il découvre résident ici, de sorte qu’ajouter ou modifier un test prend effet à l’exécution suivante sans recompilation. temp_path est /remote/temp sur le périphérique, qui correspond au scripts/unittest/temp/ de votre hôte – un répertoire de travail accessible en écriture pour les tests qui créent des fichiers.

/rom

Le système de fichiers ROM en lecture seule de la carte, intégré à l’image du micrologiciel à partir de romfs_config.json : les fixtures de test (issues de scripts/unittest/data/) et les modèles ML fournis. data_path est /rom – accédez à un fixture avec data_path + "/<file>".

Ainsi, un nouveau test ne nécessite aucune recompilation, mais une nouvelle fixture en nécessite une : l’image ROM est indexée sur romfs_config.json plutôt que sur les fichiers de données individuels, forcez donc la recompilation en touchant le romfs_config.json de la carte (ou make TARGET=<TARGET> clean) et en réexécutant.

Les valeurs attendues sont vérifiées en ligne dans le test, il n’y a donc pas de fichier de sortie attendue distinct à maintenir. Pour ignorer un test à l’exécution – par exemple lorsqu’il nécessite du matériel que le simulateur ne modélise pas – levez une exception dont le message contient "SKIPPED".