12.4. Handskakning och kapacitetsförhandling

Kameran och värden anländer båda till transporten med sina egna idéer om hur protokollet ska köras: vilka CRC-lägen, om ACK:er krävs, vilken den största nyttolast de kan buffra är. Innan riktig trafik startar utbyter de en handskakning som fastställer dessa parametrar för resten av sessionen.

12.4.1. Värden öppnar anslutningen

Kamerasidan startar protokollstacken vid uppstart (eller så startar applikationen om den med protocol.init() för att ändra parametrar), och sitter sedan tyst och väntar på en värd. Ur kamerans synvinkel finns det ingenting att göra förrän ett paket anländer.

Värdsidan öppnar transporten – USB-port eller UART – och skickar omedelbart ett PROTO_SYNC-paket (opcode 0x00). Detta paket har en magisk nyttolast som låter kameran känna igen det även om båda sidor kommit ur synk, och det är det enda paket som kameran någonsin svarar på innan kapaciteter förhandlats.

Om kameran inte svarar inom omsändningstidsgränsen skickar värden PROTO_SYNC igen, upp till rtx_retries gånger. Därefter ger den upp och rapporterar ett anslutningsfel. Det är omförsöket som får ”dra ut, sätt i igen, starta om värdskriptet” att fungera utan att kameran behöver veta att värden försvann.

12.4.2. Kapacitetsutbyte

När kameran bekräftar synkroniseringen skickar värden PROTO_GET_CAPS (opcode 0x01) för att fråga vad kameran stöder. Svarsnyttolasten rapporterar:

  • CRC-validering aktiverad eller inaktiverad

  • Sekvensnummerspårning aktiverad eller inaktiverad

  • ACK:er aktiverade eller inaktiverade

  • Händelsenotifieringar aktiverade eller inaktiverade

  • Kamerans maximala nyttolaststorlek i bytes

  • Aktuellt antal omsändningsförsök, tidsgräns och pollningsparametrar

Värden jämför dessa mot sin egen konfiguration. Om värden behöver ändra någon av dem – till exempel för att förhandla fram en mindre maximal nyttolast eftersom dess mottagningsbuffert är mindre än kamerans – skickar den PROTO_SET_CAPS (opcode 0x02) med de nya värdena. Kameran omkonfigurerar sin stack och bekräftar. Från och med nu följer varje paket som korsar tråden det delade kontraktet.

Om värden inte åsidosätter något är standardvärdena alla på: CRC-validering, sekvensnummerspårning, ACK:er och händelsenotifieringar. Den maximala standardnyttolasten är kamerans buffert per kort minus 14 bytes inramningsoverhead (det 10 bytes stora huvudet plus den 4 bytes stora avslutande nyttolast-CRC:n). För det mesta arbetet mellan kamera och bärbar dator är standardvärdena rätt utgångspunkt; tillförlitlighetssidan beskriver när och varför en applikation stänger av delar av dem.

12.4.3. Kanalupptäckt

Efter kapaciteterna skickar värden CHANNEL_LIST (opcode 0x20). Kameran svarar med en lista över registrerade kanaler – de fyra inbyggda (stdin, stdout, stream, profile) plus eventuella som applikationen registrerat med protocol.register(). Varje post bär kanalens ID, dess namn och dess kapacitetsflaggor (skrivskyddad, endast skrivbar, låsbar).

Värden lagrar listan och använder den senare när applikationskoden begär channel_read("frame") eller channel_write("config", ...) – namnet slås upp till ett kanal-ID en gång, och sedan använder varje efterföljande paket på den kanalen ID:t direkt.

Om kameran registrerar en ny kanal efter den initiala listan – vanligt när en applikation börjar köra efter handskakningen – avger kameran ett CHANNEL_REGISTERED-händelsepaket. Värden lyssnar efter dessa och uppdaterar sin interna kanallista, så att ett värdskript som anslöt tidigt ser nyregistrerade kanaler dyka upp utan omstart.

Handskakningen tar några tur-och-retur-anrop vid anslutningsuppsättning och upprepas sedan aldrig. Trafik i jämviktstillstånd är bara paket: inramade bytes in, inramade bytes ut, med kanal-ID:na redan kända på båda sidor.