14.5. Zusammenfassung

Sie haben den Lebenszyklus einer Cam durchlaufen – vom funktionierenden Werkbank-Skript bis zum ausgelieferten Produkt:

  • Eigene Firmware-Builds – die Entwicklungsumgebung, das Bauen des Firmware-Images aus dem Quellcode, das Flashen auf eine Cam und der Debugging-Pfad von VS Code Cortex-Debug zum kommandozeilenbasierten gdbrunner, wenn auf der Firmware-Seite etwas nicht stimmt.

  • Die Anwendung ausliefern – das Einbacken des Anwendungscodes in die Firmware über eingefrorene Module, das Einbacken von Assets in ein ROMFS-Image und die Suchreihenfolge, die bestimmt, welche Kopie einer Datei die Laufzeit beim Booten tatsächlich lädt. Die sich daraus ergebende Aufteilung: boot.py für die Umgebungseinrichtung vor der REPL, main.py als Einstiegspunkt der Anwendung, eingefrorenes main.py für den Einstieg und ROMFS für alles andere.

  • Härtung für die Produktion – die logging-Bibliothek, die in einen bekannten Pfad schreibt, ein machine.WDT, der einmal pro Hauptschleifen-Durchlauf gefüttert wird, ein try / except auf oberster Ebene, das Abstürze in protokollierte Ereignisse statt in Resets verwandelt, Dateisystemhygiene, die Dateioperationen schnell hält, während die Anwendung über Monate im Feld Datensätze ansammelt, und – wenn das Produkt es erfordert – Flash-Ausleseschutz.

  • Fortgeschrittenes Material – TLS-Zertifikate für Cams, die sich gegenüber Netzwerkdiensten authentifizieren und den Datenverkehr mit ihnen verschlüsseln müssen.

Eine ausgelieferte Cam hat all dies an Ort und Stelle: Ihr Anwendungscode läuft aus dem Firmware-Image, ihr Watchdog wird einmal pro Hauptschleifen-Durchlauf gefüttert, ihr Log landet in einem datierten Verzeichnis auf der SD-Karte und – wenn das Produkt es erfordert – ihr Flash wurde gegen Auslesen gesperrt.

14.5.1. Wie es von hier aus weitergeht

Die Produktion ist das letzte Kapitel des Tutorials. Von hier an teilt sich die Dokumentation in Referenzmaterial auf:

  • Die Bibliotheksreferenz ist die alphabetische „Wie lautet der genaue Name dieses Aufrufs“-Sicht auf jedes Modul, das die Cam bereitstellt – machine, logging, os, csi, image, ml und den Rest.

  • Die boardspezifischen Quickref-Seiten decken die Besonderheiten jeder Cam in der OpenMV-Produktlinie ab – Pinbelegungen, einhängbare Busse, Board-IDs, Verfügbarkeit von Peripheriegeräten und die kleinen Unterschiede, die wichtig werden, wenn die Anwendung auf einem bestimmten Bauteil landen muss.

  • Die Sensor-Referenzseiten und Shield-Referenzseiten decken die einzelnen Bildsensoren und Aufsteck-Shields ab, die eine Cam tragen kann – die bauteilspezifischen Spezifikationen, Pinbelegungen und Hinweise, die die Anwendung bei der Auswahl von Sensoren und Shields für einen Build benötigt.

  • Die MicroPython-Sprachreferenz deckt die Sprache selbst ab – Syntaxunterschiede zu CPython, die Implementierungsdetails, die wichtig werden, wenn ein Skript beide überspannt, und die Inline-Assembler-Referenz für den seltenen Fall, dass Python zu langsam ist.

Das Tutorial ist der Weg von „Ich habe eine neue Cam in der Hand“ zu „Ich habe ein Produkt ausgeliefert.“ Von hier an ist die Cam ein Teil eines größeren Systems, für das die Anwendung verantwortlich ist, und die Arbeit ist die der Anwendung selbst.