12.4. Handshake und Aushandlung der Fähigkeiten

Kamera und Host kommen beide mit ihren eigenen Vorstellungen davon zum Transport, wie das Protokoll ablaufen soll: welche CRC-Modi, ob ACKs erforderlich sind, wie groß die größte Nutzlast ist, die sie puffern können. Bevor der eigentliche Datenverkehr beginnt, tauschen sie einen Handshake aus, der diese Parameter für den Rest der Sitzung festlegt.

12.4.1. Der Host öffnet die Verbindung

Die Kameraseite startet den Protokollstack beim Booten (oder die Anwendung startet ihn mit protocol.init() neu, um Parameter zu ändern) und wartet dann ruhig auf einen Host. Aus Sicht der Kamera gibt es nichts zu tun, bis ein Paket eintrifft.

Die Hostseite öffnet den Transport – USB-Port oder UART – und sendet sofort ein PROTO_SYNC-Paket (Opcode 0x00). Dieses Paket hat eine magische Nutzlast, die es der Kamera ermöglicht, es zu erkennen, selbst wenn beide Seiten die Synchronisation verloren haben, und es ist das einzige Paket, auf das die Kamera jemals antwortet, bevor die Fähigkeiten ausgehandelt sind.

Wenn die Kamera nicht innerhalb des Übertragungswiederholungs-Timeouts antwortet, sendet der Host erneut PROTO_SYNC, bis zu rtx_retries Mal. Danach gibt er auf und meldet einen Verbindungsfehler. Diese Wiederholung ist es, die „abstecken, wieder einstecken, das Host-Skript neu starten“ funktionieren lässt, ohne dass die Kamera wissen muss, dass der Host weg war.

12.4.2. Austausch der Fähigkeiten

Sobald die Kamera die Synchronisation bestätigt, sendet der Host PROTO_GET_CAPS (Opcode 0x01), um zu fragen, was die Kamera unterstützt. Die Antwort-Nutzlast meldet:

  • CRC-Validierung aktiviert oder deaktiviert

  • Sequenznummer-Verfolgung aktiviert oder deaktiviert

  • ACKs aktiviert oder deaktiviert

  • Ereignisbenachrichtigungen aktiviert oder deaktiviert

  • Die maximale Nutzlastgröße der Kamera in Bytes

  • Die aktuelle Anzahl der Übertragungswiederholungen, das Timeout und die Polling-Parameter

Der Host vergleicht diese mit seiner eigenen Konfiguration. Wenn der Host einen davon ändern muss – zum Beispiel, um eine kleinere maximale Nutzlast auszuhandeln, weil sein Empfangspuffer kleiner ist als der der Kamera – sendet er PROTO_SET_CAPS (Opcode 0x02) mit den neuen Werten. Die Kamera konfiguriert ihren Stack neu und bestätigt. Von hier an folgt jedes Paket, das über die Leitung geht, diesem gemeinsamen Vertrag.

Wenn der Host nichts überschreibt, sind die Standardwerte alle aktiviert: CRC-Validierung, Sequenznummer-Verfolgung, ACKs und Ereignisbenachrichtigungen. Die maximale Standard-Nutzlast ist der platinenspezifische Puffer der Kamera abzüglich 14 Byte Framing-Overhead (der 10-Byte-Header plus die nachgestellte 4-Byte-Nutzlast-CRC). Für die meisten Kamera-zu-Laptop-Arbeiten sind die Standardwerte der richtige Ausgangspunkt; die Seite zur Zuverlässigkeit behandelt, wann und warum eine Anwendung Teile davon abschaltet.

12.4.3. Kanal-Erkennung

Nach den Fähigkeiten sendet der Host CHANNEL_LIST (Opcode 0x20). Die Kamera antwortet mit einer Liste der registrierten Kanäle – die vier eingebauten (stdin, stdout, stream, profile) plus alle, die die Anwendung mit protocol.register() registriert hat. Jeder Eintrag enthält die ID des Kanals, seinen Namen und seine Fähigkeits-Flags (nur lesen, nur schreiben, sperrbar).

Der Host legt die Liste ab und verwendet sie später, wenn der Anwendungscode channel_read("frame") oder channel_write("config", ...) aufruft – der Name wird einmal in eine Kanal-ID aufgelöst, danach verwendet jedes folgende Paket auf diesem Kanal die ID direkt.

Wenn die Kamera nach der ursprünglichen Liste einen neuen Kanal registriert – üblich, wenn eine Anwendung erst nach dem Handshake zu laufen beginnt – gibt die Kamera ein CHANNEL_REGISTERED-Ereignispaket aus. Der Host lauscht darauf und aktualisiert seine interne Kanalliste, sodass ein Host-Skript, das sich früh verbunden hat, neu registrierte Kanäle ohne Neustart erscheinen sieht.

Der Handshake benötigt beim Verbindungsaufbau ein paar Round-Trips und wiederholt sich danach nie wieder. Der eingeschwungene Datenverkehr besteht nur aus Paketen: gerahmte Bytes hinein, gerahmte Bytes hinaus, die Kanal-IDs sind auf beiden Seiten bereits bekannt.