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.
| Cœur | NPU | Simulateur |
|---|---|---|---|
| Cortex-M7 | Aucun | QEMU |
| 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
aptsudo apt install qemu-system-armmacOS – 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 |
|---|---|
| Le répertoire |
| Le système de fichiers ROM en lecture seule de la carte, intégré à l’image du micrologiciel à partir de |
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".