14.2.2.2. Sestavení obrazu ROMFS

Obraz ROMFS je souborový systém rezidentní ve flash paměti určený jen pro čtení, který běhové prostředí automaticky připojí na /rom. Řeší problém s aktivy, kterým se zakončila předchozí stránka: soubory modelů strojového učení, tabulky štítků, konfiguraci JSON, šablony obrazů – cokoli, co aplikace otevírá a čte, ale nikdy nezapisuje – se dostane do sestavení, aniž by se platila cena za vložení jako literálů v Pythonu.

Tři věci činí z ROMFS správný nástroj pro dodávaná aktiva:

  • Souborový systém je součástí obrazu firmwaru. Koncoví uživatelé nemohou smazat soubor z /rom, upravit jej ani nahradit vlastním.

  • Soubory v /rom jsou přístupné na místě. Konzumenti jako modul ml načítající soubor modelu získají přímý pohled do flash paměti bez kopie do RAM – vícemegabajtový model na /rom se „načte“ v podstatě zdarma, zatímco stejný soubor na /sdcard se při načítání přečte do RAM a zůstává tam po celou dobu životnosti reference. Běžné open() + read kopíruje na vyžádání: každé volání read(n) zkopíruje n bajtů z flash paměti do RAM v okamžiku volání, přičemž holé read() si vyžádá celý soubor.

  • /rom a /rom/lib jsou při spuštění přidány do sys.path. Python balíčky vložené do obrazu jsou importovatelné podle názvu; v místě volání nic zvláštního.

14.2.2.2.1. Sestavení obrazu

Obrazy ROMFS se vytvářejí, upravují a flashují přes IDE. Používejte jej jako zdroj pravdy pro obsah každé dodávané oblasti ROMFS.

Důvod, proč na tom záleží: soubory modelů mají požadavky na zarovnání, které zavaděč za běhu vynucuje. Soubory .tflite musí být zarovnány na hranice 16 bajtů a NPU čipu N6 vyžaduje pro zkompilované modely zarovnání na 32 bajtů. IDE toto zarovnání aplikuje automaticky při zápisu obrazu. Nástroje, které procházejí zdrojový strom bez aplikace zarovnání – zejména mpremote romfs – vytvoří obraz, který se připojí čistě, ale jehož modely selžou při prvním volání inference.

Editor ROMFS v IDE je interaktivní zobrazení obsahu obrazu. Soubory a složky lze přidávat, přejmenovávat a mazat v paměti; uložení zapíše výsledek jako soubor .img připravený k flashování. Typická struktura pro aplikaci, která dodává model spolu s několika aktivy a Python balíčkem, vypadá takto:

model.tflite
labels.txt
config.json
templates/
    calibration.jpg
lib/
    mylib/
        __init__.py
        helpers.py

Tip

Jak IDE, tak mpremote křížově kompilují soubory .py na bytekód .mpy při cestě do obrazu ROMFS, takže je kamera importuje, aniž by při načítání platila cenu za parsování. Zdrojové soubory v editoru zůstávají .py; obraz obsahuje .mpy.

Jakmile je obraz naflashován, je strom viditelný z MicroPythonu na /rom/

>>> import os
>>> os.listdir('/rom')
['model.tflite', 'labels.txt', 'config.json', 'templates', 'lib']
>>> import mylib
>>> mylib.helpers
<module 'mylib.helpers' from '/rom/lib/mylib/helpers.mpy'>

14.2.2.2.2. Většina aplikace sídlí v ROMFS

ROMFS je správným domovem pro téměř vše, co aplikace dodává: knihovny, které importuje, soubory modelů, které načítá, konfiguraci, kterou čte, jakékoli aktivum, jehož výstup pochází z nástroje sestavení vytvářejícího strom souborů (konvertory modelů, obrazové pipeline, balíčkovače aktiv) a – což je důležité – samotný aplikační kód.

Strana zmrazených modulů by měla zůstat malá: boot.py pro nastavení před REPL, main.py jako tenký vstupní bod a pouze knihovny, bez kterých se kamera opravdu nemůže spustit. Vše ostatní jde do ROMFS, kde iterace nad ním znamená nový .img uložený z IDE a znovu naflashovaný – bez nutnosti opětovného sestavení firmwaru, bez nutnosti mít po ruce sadu nástrojů.

Vzorec, který z toho vyplývá, je main.py, který nedělá nic jiného, než deleguje řízení do aplikace rezidentní v ROMFS:

# main.py (frozen)
import app
app.run()

# /rom/app/__init__.py (in ROMFS)
def run():
    ...

Změna v app je úpravou ROMFS a opětovným flashováním. Sestavení firmwaru zůstává nezměněno po celou dobu životnosti produktu, pokud se na straně zmrazených modulů něco skutečně nemusí změnit.