12.1. Warum eine Protokollbibliothek

Ein Kabelpaar und eine Baudrate genügen, um Bytes von einer Kamera zu einem Host-PC zu übertragen. Sowohl USB-CDC als auch UART geben dem Kameraprogramm einen Stream, bei dem write an einem Ende Bytes hineingibt und read sie am anderen Ende herausnimmt. Was fügt also eine Protokollbibliothek darüber hinaus hinzu?

Drei Dinge, die Sie jedes Mal selbst schreiben müssten, wenn Sie versuchten, einen ernstzunehmenden Kamera-zu-Host-Kanal direkt auf rohen Bytes aufzubauen:

Framing. Ein Byte-Stream hat keine inhärente Struktur. Die Kamera schreibt temp=42 und der Host liest temp= sowie einen später eintreffenden Interrupt, dann 42 plus die nächste Nachricht, die mit humid=... beginnt und bereits hineinläuft. Bytes haben keine Grenzen. Jede nicht-triviale Host-Verbindung erfindet am Ende irgendeine Markierung – \n zwischen Nachrichten, Längen-Präfix-Header, Escape-Sequenzen für binäre Nutzdaten – damit der Empfänger weiß, wo eine Nachricht endet und die nächste beginnt. Die Protokollbibliothek gibt Ihnen ein einheitliches Paketformat mit einem Sync-Wort und einem Längenfeld, und der Empfänger muss nie raten.

Zuverlässigkeit. USB-CDC verliert im Normalbetrieb keine Bytes stillschweigend, UART hingegen schon (wenn der Host den Port nicht schnell genug bedient), und ein abgezogenes und wieder eingestecktes serielles Kabel kann eine Seite mit einem unvollständigen Paket zurücklassen. Das Richtige ist, die Beschädigung zu erkennen, die Gegenseite um eine erneute Übertragung zu bitten und dem Anwendungscode nur unversehrt angekommene Nachrichten zu übergeben. Die Protokollbibliothek tut das für jedes Paket mit einer CRC und Bestätigungen pro Paket – standardmäßig aktiviert; die Anwendung bekommt die Wiederholungen nicht zu sehen.

Multiplexing. Es gibt genau einen USB-CDC-Port zwischen Kamera und Host. Wenn die Kamera ein Bild streamt und der Host ihr eine Konfiguration sendet und die IDE stdout für die print-Ausgabe liest, müssen sich alle drei Austausche diesen einzelnen Byte-Stream teilen. Die Protokollbibliothek gibt jedem unabhängigen Stream eine Kanal-Nummer, lässt die Kamera für jeden eine Python-Klasse registrieren und sorgt dafür, dass sich die Lesevorgänge des Hosts auf den einzelnen Kanälen nicht gegenseitig stören. Aus Sicht des Anwendungscodes sieht jeder Kanal wie seine eigene private Verbindung aus.

12.1.1. Warum das nicht selbst schreiben

Sie können das. Es sind ein paar Wochen Arbeit, alle drei auf einer seriellen Leitung korrekt hinzubekommen, und noch ein paar Wochen, um das Framing eine Hot-Plug-Wiederherstellung sauber handhaben zu lassen, die erneuten Übertragungen zu ermöglichen, ohne Energie für Round-Trips zu verschwenden, und den Multiplexer partielle Lesevorgänge überstehen zu lassen, ohne die Bytes eines Kanals in die eines anderen zu verfälschen.

Die Protokollbibliothek hat diese Arbeit bereits erledigt, wurde auf jeder unterstützten Kamera validiert und hat passende Bibliotheken auf der Host-Seite, die dasselbe Wire-Format sprechen. Sie zu verwenden bedeutet, dass der kameraseitige Code aus einer kleinen Klasse pro Kanal besteht und der hostseitige Code ein Camera-Objekt mit den Methoden channel_read und channel_write ist. Der eingesparte gedankliche Aufwand fließt in das, was die Anwendung tatsächlich tut.

Dieses Kapitel vermittelt das Protokoll von Grund auf: das Wire-Format, die Framing-Regeln, die Zuverlässigkeitsmechanik, das Kanalmodell und schließlich die Python-Klassen auf beiden Seiten. Am Ende kann der Leser eine Host-GUI bauen, die mit der Kamera spricht, ein Skript, das Sensordaten von der Kamera zum Laptop streamt, und die Art von interaktivem Kalibrierungswerkzeug, wie es in openmv-projects/tools/ ausgeliefert wird.