14.1.1.3. Симулятори

Два значення TARGET збирають мікропрограму для запуску всередині симулятора на вашому хості, без підключеного обладнання. Вони існують для того, щоб мікропрограму можна було запускати та тестувати будь-де.

TARGET	Ядро	NPU	Симулятор
MPS2_AN500	Cortex-M7	None	QEMU
MPS3_AN547	Cortex-M55	Ethos-U55 (256 MACs)	Arm FVP – Corstone SSE-300

MPS2_AN500 – це базова ціль Cortex-M7 без NPU. Вона працює під QEMU, який швидко запускається та є легким способом перевірити платформо-незалежний код і набір тестів.

MPS3_AN547 – це Cortex-M55 з NPU Ethos-U55, що працює на Fast Models від Arm – FVP, який моделює еталонну підсистему Corstone SSE-300. Це ціль для перевірки NPU та шляху ML-моделі в симуляції.

Обидві надають файлову систему ROM та достатньо RAM (а M55 – ще й NPU), тому скрипти комп’ютерного зору та ML виконуються без змін.

Реального датчика немає, але модуль csi все одно працює з віртуальним – csi.CSI.snapshot() повертає синтетичний анімований тестовий шаблон (прокручувана шахівниця у відтінках сірого, градієнт у RGB565), а не живу сцену. Щоб обробити реальний вміст зображення, завантажте його з файлу: image.Image з фікстури у файловій системі ROM або потік image.ImageIO для записаних кадрів.

14.1.1.3.1. Збирання та запуск

Кожен симулятор – це інструмент хоста, який ви встановлюєте самостійно. Ви збираєте ціль як будь-яку іншу (дивіться Збірка мікропрограми), а потім запускаєте її через run під відповідним симулятором – run збирає образ ROMFS, завантажує мікропрограму та залишає її працювати із серійним з’єднанням, до якого ви можете підключитися.

14.1.1.3.1.1. MPS2_AN500 (QEMU)

QEMU постачається в більшості менеджерів пакетів як системний емулятор Arm:

• Linux (Debian / Ubuntu) – встановіть його за допомогою apt

  sudo apt install qemu-system-arm
  

• macOS – встановіть його за допомогою Homebrew:

  brew install qemu
  

Потім зберіть та запустіть ціль:

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

14.1.1.3.1.2. MPS3_AN547 (Arm FVP)

FVP – це Fixed Virtual Platform від Arm для Corstone SSE-300, що постачається у складі Arm Virtual Hardware. Вона доступна лише для Linux – на Mac використовуйте натомість ціль QEMU вище.

Завантажте набір, розпакуйте його та додайте його каталог bin/ до вашого 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"

FVP також потребує бібліотек Python з SDK у LD_LIBRARY_PATH під час запуску. Експортуйте його один раз на оболонку з кореня репозиторію – читання SDK_VERSION зберігає його коректним у міру оновлення закріпленого SDK репозиторієм:

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

Потім зберіть та запустіть ціль:

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

14.1.1.3.2. Запуск набору тестів

Модульні тести знаходяться у scripts/unittest/tests/, а їх фікстурні зображення та дані – у scripts/unittest/data/. Вони запускаються за допомогою mpremote, який монтує scripts/unittest/ на запущений симулятор та виконує його run.py.

Зв’язок із симулятором повільний зі стандартним mpremote, тому використовуйте копію, що постачається в репозиторії, із застосованим патчем серійного зв’язку (застосуйте його один раз):

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

Для MPS2_AN500 під QEMU запустіть ціль – вона виводить псевдотермінал, на якому знаходиться її серійний порт (наприклад, /dev/pts/5):

make TARGET=MPS2_AN500 run

Потім, з іншої оболонки, спрямуйте пропатчений mpremote на цей пристрій:

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

Для MPS3_AN547 під FVP серійний порт натомість є telnet-сокетом на порту 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 виявляє та виконує кожен тест, виводячи рядок PASSED / FAILED для кожного тесту з часом виконання та підсумком у кінці.

14.1.1.3.3. Додавання тесту

Тести виявляються автоматично. Щоб додати тест, розмістіть у scripts/unittest/tests/ файл, що визначає функцію unittest(data_path, temp_path), яка повертає True, коли тест проходить, та False, коли він не проходить:

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

Аргументи data_path та temp_path вказують на дві файлові системи, які бачить симулятор під час виконання набору тестів:

Шлях	Забезпечується
/remote	Каталог хоста scripts/unittest/, змонтований наживо через з’єднання mpremote. run.py та виявлені ним tests/ знаходяться тут, тому додавання чи редагування тесту набуває чинності при наступному запуску без перезбирання. temp_path – це /remote/temp на пристрої, що є вашим scripts/unittest/temp/ на хості – придатний для запису тимчасовий каталог для тестів, що створюють файли.
/rom	Файлова система ROM плати, доступна лише для читання, вбудована в образ мікропрограми з romfs_config.json: тестові фікстури (з scripts/unittest/data/) та вбудовані ML-моделі. data_path – це /rom – доступайтеся до фікстури як data_path + "/<file>".

Тож новий тест не потребує перезбирання, але нова фікстура потребує: образ ROM формується на основі romfs_config.json, а не окремих файлів даних, тому примусьте перезбирання, оновивши час файлу romfs_config.json плати (або make TARGET=<TARGET> clean) та запустивши знову.

Очікувані значення стверджуються безпосередньо в тесті, тому немає окремого файлу очікуваного виводу, який потрібно підтримувати. Щоб пропустити тест під час виконання – наприклад, коли йому потрібне обладнання, яке симулятор не моделює – викиньте виняток, повідомлення якого містить "SKIPPED".