14.1.1.3. Simuladores#

Dos valores de TARGET compilan el firmware para ejecutarse dentro de un simulador en su host, sin hardware conectado. Existen para que el firmware pueda ejecutarse y probarse en cualquier lugar.

TARGET

Núcleo

NPU

Simulador

MPS2_AN500

Cortex-M7

Ninguno

QEMU

MPS3_AN547

Cortex-M55

Ethos-U55 (256 MACs)

Arm FVP – Corstone SSE-300

MPS2_AN500 es el objetivo Cortex-M7 base sin NPU. Se ejecuta bajo QEMU, que arranca rápido y es la forma ligera de ejercitar el código independiente de la plataforma y el conjunto de pruebas.

MPS3_AN547 es un Cortex-M55 con la NPU Ethos-U55, ejecutado sobre los Fast Models de Arm – el FVP, que modela el subsistema de referencia Corstone SSE-300. Este es el objetivo para ejercitar la NPU y la ruta del modelo de ML en simulación.

Ambos proporcionan el sistema de archivos ROM y abundante RAM (y la NPU en el M55), de modo que los scripts de visión y de ML se ejecutan sin modificaciones.

No hay un sensor real, pero el módulo csi sigue funcionando contra uno virtual – csi.CSI.snapshot() devuelve un patrón de prueba sintético y animado (un tablero de ajedrez que se desplaza en escala de grises, un degradado en RGB565), no una escena en vivo. Para procesar contenido de imagen real, cárguelo de un archivo en su lugar: una image.Image a partir de un fixture en el sistema de archivos ROM, o un flujo image.ImageIO para fotogramas grabados.

14.1.1.3.1. Compilar y ejecutar#

Cada simulador es una herramienta de host que usted mismo instala. Compile un objetivo como cualquier otro (véase Compilar el firmware), luego ejecútelo con run bajo el simulador correspondiente – run compila la imagen ROMFS, arranca el firmware y lo deja en ejecución con una conexión serie a la que puede conectarse.

14.1.1.3.1.1. MPS2_AN500 (QEMU)#

QEMU se distribuye en la mayoría de los gestores de paquetes como el emulador de sistema Arm:

  • Linux (Debian / Ubuntu) – instálelo con apt:

    sudo apt install qemu-system-arm
    
  • macOS – instálelo con Homebrew:

    brew install qemu
    

Después compile y ejecute el objetivo:

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

14.1.1.3.1.2. MPS3_AN547 (Arm FVP)#

El FVP es la Fixed Virtual Platform de Arm para el Corstone SSE-300, distribuida como parte de Arm Virtual Hardware. Solo está disponible para Linux – en un Mac, use el objetivo QEMU de arriba en su lugar.

Descargue el paquete, extráigalo y ponga su directorio bin/ en su 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"

El FVP también necesita las bibliotecas de Python del SDK en LD_LIBRARY_PATH cuando se ejecuta. Expórtelo una vez por shell desde la raíz del repositorio – leer SDK_VERSION lo mantiene correcto a medida que el repositorio actualiza el SDK fijado:

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

Después compile y ejecute el objetivo:

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

14.1.1.3.2. Ejecutar el conjunto de pruebas#

Las pruebas unitarias residen en scripts/unittest/tests/, con sus imágenes de fixture y datos en scripts/unittest/data/. Se ejecutan con mpremote, que monta scripts/unittest/ en el simulador en ejecución y ejecuta su run.py.

El enlace del simulador es lento con el mpremote estándar, así que use la copia incluida en el repositorio con el parche de serie aplicado (aplíquelo una vez):

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

Para MPS2_AN500 bajo QEMU, inicie el objetivo – imprime el pseudoterminal en el que está su puerto serie (por ejemplo /dev/pts/5):

make TARGET=MPS2_AN500 run

Luego, desde otro shell, apunte el mpremote parcheado a ese dispositivo:

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

Para MPS3_AN547 bajo el FVP, el puerto serie es en cambio un socket telnet en el puerto 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 descubre y ejecuta cada prueba, imprimiendo una línea PASSED / FAILED por prueba con el tiempo y un resumen al final.

14.1.1.3.3. Añadir una prueba#

Las pruebas se descubren automáticamente. Para añadir una, coloque un archivo en scripts/unittest/tests/ que defina una función unittest(data_path, temp_path) que devuelva True cuando la prueba pasa y False cuando falla:

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

Los argumentos data_path y temp_path apuntan a los dos sistemas de archivos que el simulador ve mientras se ejecuta el conjunto de pruebas:

Ruta

Respaldado por

/remote

El directorio scripts/unittest/ del host, montado en vivo sobre la conexión mpremote. run.py y los tests/ que descubre residen aquí, de modo que añadir o editar una prueba surte efecto en la siguiente ejecución sin recompilar. temp_path es /remote/temp en el dispositivo, que es el scripts/unittest/temp/ de su host – un directorio temporal de escritura para las pruebas que crean archivos.

/rom

El sistema de archivos ROM de solo lectura de la placa, incorporado en la imagen del firmware a partir de romfs_config.json: los fixtures de prueba (de scripts/unittest/data/) y los modelos de ML incluidos. data_path es /rom – acceda a un fixture como data_path + "/<file>".

Así, una nueva prueba no necesita recompilación, pero un nuevo fixture sí: la imagen ROM se basa en romfs_config.json en lugar de en los archivos de datos individuales, así que fuerce la recompilación tocando (touch) el romfs_config.json de la placa (o make TARGET=<TARGET> clean) y ejecutando de nuevo.

Los valores esperados se afirman en línea en la prueba, por lo que no hay un archivo de salida esperada aparte que mantener. Para omitir una prueba en tiempo de ejecución – por ejemplo cuando necesita hardware que el simulador no modela – lance una excepción cuyo mensaje contenga "SKIPPED".