14.5. Podsumowanie

Przeszedłeś przez cykl życia kamery od działającego skryptu na biurku do dostarczonego produktu:

  • Niestandardowe kompilacje oprogramowania układowego – środowisko deweloperskie, budowanie obrazu oprogramowania układowego ze źródeł, wgrywanie go na kamerę oraz ścieżka debugowania od VS Code Cortex-Debug do uruchamianego z wiersza poleceń gdbrunner, gdy coś jest nie tak po stronie oprogramowania układowego.

  • Dostarczanie aplikacji – wbudowanie kodu aplikacji w oprogramowanie układowe za pomocą zamrożonych modułów, wbudowanie zasobów w obraz ROMFS oraz kolejność wyszukiwania, która decyduje, którą kopię pliku środowisko uruchomieniowe faktycznie wczytuje przy starcie. Wynikający z tego podział: boot.py na konfigurację środowiska przed REPL, main.py jako punkt wejścia aplikacji, zamrożony main.py dla wejścia oraz ROMFS dla całej reszty.

  • Utwardzanie do produkcji – biblioteka logging zapisująca do znanej ścieżki, machine.WDT karmiony raz na iterację pętli głównej, try / except na najwyższym poziomie zamieniający awarie w zalogowane zdarzenia zamiast resetów, higiena systemu plików utrzymująca szybkość operacji na plikach w miarę jak aplikacja gromadzi rekordy przez miesiące w terenie, oraz – gdy produkt tego wymaga – ochrona pamięci flash przed odczytem.

  • Materiał zaawansowany – certyfikaty TLS dla kamer, które muszą uwierzytelniać się wobec usług sieciowych i szyfrować z nimi ruch.

Dostarczona kamera ma to wszystko na swoim miejscu: jej kod aplikacji działa z obrazu oprogramowania układowego, jej watchdog jest karmiony raz na iterację pętli głównej, jej dziennik trafia do datowanego katalogu na karcie SD, a – gdy produkt tego wymaga – jej pamięć flash została zablokowana przed odczytem.

14.5.1. Dokąd dalej

Produkcja to ostatni rozdział samouczka. Stąd dokumentacja dzieli się na materiały referencyjne:

  • Dokumentacja bibliotek to alfabetyczny widok typu „jaka jest dokładna nazwa tego wywołania” dla każdego modułu, który udostępnia kamera – machine, logging, os, csi, image, ml i pozostałych.

  • Strony szybkiego odniesienia dla poszczególnych płytek obejmują szczegóły każdej kamery z linii produktowej OpenMV – układy wyprowadzeń, montowalne magistrale, identyfikatory płytek, dostępność urządzeń peryferyjnych oraz drobne różnice, które mają znaczenie, gdy aplikacja musi trafić na konkretny element.

  • Strony referencyjne sensorów i strony referencyjne nakładek (shields) obejmują poszczególne sensory obrazu i nakładki, które kamera może nosić – specyfikacje poszczególnych elementów, układy wyprowadzeń oraz uwagi potrzebne aplikacji przy wyborze sensorów i nakładek do kompilacji.

  • Dokumentacja języka MicroPython obejmuje sam język – różnice składniowe względem CPython, szczegóły implementacyjne, które mają znaczenie, gdy skrypt znajduje się na styku obu, oraz dokumentację asemblera inline na rzadki przypadek, gdy Python jest zbyt wolny.

Samouczek to droga od „mam w ręku nową kamerę” do „dostarczyłem produkt”. Stąd kamera jest jednym z elementów większego systemu, za który odpowiada aplikacja, a praca należy już do samej aplikacji.