OpenMV MicroPython
12.4. Handshake en capability-onderhandeling¶
De cam en de host komen allebei bij het transport aan met hun eigen ideeën over hoe het protocol zou moeten draaien: welke CRC-modi, of ACK’s vereist zijn, en wat de grootste payload is die ze kunnen bufferen. Voordat het echte verkeer begint, wisselen ze een handshake uit die die parameters voor de rest van de sessie vastlegt.
12.4.1. De host opent de verbinding¶
De cam-kant start de protocolstack bij het opstarten (of de applicatie herstart hem met protocol.init() om parameters te wijzigen) en wacht dan rustig op een host. Vanuit het oogpunt van de cam is er niets te doen totdat er een pakket binnenkomt.
De host-kant opent het transport – USB-poort of UART – en stuurt onmiddellijk een PROTO_SYNC-pakket (opcode 0x00). Dit pakket heeft een magische payload waardoor de cam het kan herkennen, zelfs als beide kanten uit synchronisatie zijn geraakt, en het is het enige pakket waarop de cam ooit reageert voordat de capabilities zijn onderhandeld.
Als de cam niet binnen de hertransmissie-timeout antwoordt, stuurt de host opnieuw PROTO_SYNC, tot rtx_retries keer. Daarna geeft hij het op en meldt een verbindingsfout. Het opnieuw proberen is wat “loskoppelen, opnieuw aansluiten, het host-script herstarten” laat werken zonder dat de cam hoeft te weten dat de host was verdwenen.
12.4.2. Capability-uitwisseling¶
Zodra de cam de sync bevestigt, stuurt de host PROTO_GET_CAPS (opcode 0x01) om te vragen wat de cam ondersteunt. De antwoord-payload meldt:
of CRC-validatie ingeschakeld of uitgeschakeld is
of sequence-number-tracking ingeschakeld of uitgeschakeld is
of ACK’s ingeschakeld of uitgeschakeld zijn
of event-notificaties ingeschakeld of uitgeschakeld zijn
de maximale payloadgrootte van de cam in bytes
het huidige aantal hertransmissiepogingen, de timeout en de polling-parameters
De host vergelijkt die met zijn eigen configuratie. Als de host er een van moet wijzigen – bijvoorbeeld om een kleinere maximale payload te onderhandelen omdat zijn ontvangstbuffer kleiner is dan die van de cam – stuurt hij PROTO_SET_CAPS (opcode 0x02) met de nieuwe waarden. De cam herconfigureert zijn stack en bevestigt. Vanaf hier volgt elk pakket dat over de lijn gaat dat gedeelde contract.
Als de host niets overschrijft, staan de standaardwaarden allemaal aan: CRC-validatie, sequence-number-tracking, ACK’s en event-notificaties. De standaard maximale payload is de buffer per board van de cam minus 14 bytes framing-overhead (de 10-byte header plus de 4-byte afsluitende payload-CRC). Voor het meeste werk tussen cam en laptop zijn de standaardwaarden het juiste uitgangspunt; de pagina over betrouwbaarheid behandelt wanneer en waarom een applicatie er onderdelen van uitschakelt.
12.4.3. Kanaalontdekking¶
Na de capabilities stuurt de host CHANNEL_LIST (opcode 0x20). De cam antwoordt met een lijst van geregistreerde kanalen – de vier ingebouwde (stdin, stdout, stream, profile) plus alle die de applicatie heeft geregistreerd met protocol.register(). Elk item bevat de ID van het kanaal, de naam ervan en de capability-vlaggen (read-only, write-only, vergrendelbaar).
De host bewaart de lijst en gebruikt die later wanneer applicatiecode om channel_read("frame") of channel_write("config", ...) vraagt – de naam wordt eenmalig opgezocht naar een kanaal-ID, waarna elk volgend pakket op dat kanaal de ID rechtstreeks gebruikt.
Als de cam na de eerste lijst een nieuw kanaal registreert – gebruikelijk wanneer een applicatie pas na de handshake begint te draaien – zendt de cam een CHANNEL_REGISTERED-eventpakket uit. De host luistert daarnaar en vernieuwt zijn interne kanaallijst, zodat een host-script dat vroeg verbinding maakte nieuw geregistreerde kanalen ziet verschijnen zonder te herstarten.
De handshake neemt bij het opzetten van de verbinding een paar round-trips in beslag en herhaalt zich daarna nooit. Het verkeer in stabiele toestand bestaat alleen uit pakketten: geframede bytes erin, geframede bytes eruit, met de kanaal-ID’s al bij beide kanten bekend.