12.4. Kättely ja kyvykkyyksien neuvottelu

Sekä kamera että isäntä saapuvat siirtokerrokseen omine käsityksineen siitä, miten protokollan tulisi toimia: mitkä CRC-tilat, vaaditaanko kuittauksia ja mikä on suurin payload, jonka ne voivat puskuroida. Ennen kuin varsinainen liikenne alkaa, ne vaihtavat kättelyn, joka kiinnittää nuo parametrit loppuistunnoksi.

12.4.1. Isäntä avaa yhteyden

Kamerapuoli käynnistää protokollapinon käynnistyksen yhteydessä (tai sovellus käynnistää sen uudelleen funktiolla protocol.init() muuttaakseen parametreja) ja jää sitten hiljaa odottamaan isäntää. Kameran näkökulmasta ei ole mitään tehtävää ennen kuin paketti saapuu.

Isäntäpuoli avaa siirtoyhteyden – USB-portin tai UARTin – ja lähettää välittömästi PROTO_SYNC-paketin (käskykoodi 0x00). Tässä paketissa on maaginen payload, jonka avulla kamera tunnistaa sen, vaikka molemmat päät olisivat ajautuneet pois synkronista, ja se on ainoa paketti, johon kamera koskaan vastaa ennen kyvykkyyksien neuvottelua.

Jos kamera ei vastaa uudelleenlähetyksen aikakatkaisun kuluessa, isäntä lähettää PROTO_SYNC-paketin uudelleen, enintään rtx_retries kertaa. Sen jälkeen se luovuttaa ja raportoi yhteysvirheen. Tämä uudelleenyritys saa ”irrota, kytke takaisin, käynnistä isäntäskripti uudelleen” -toiminnan toimimaan ilman, että kameran tarvitsee tietää isännän kadonneen.

12.4.2. Kyvykkyyksien vaihto

Kun kamera kuittaa synkronoinnin, isäntä lähettää PROTO_GET_CAPS-paketin (käskykoodi 0x01) kysyäkseen, mitä kamera tukee. Vastauksen payload raportoi:

  • CRC-tarkistus käytössä tai pois käytöstä

  • Sekvenssinumeroiden seuranta käytössä tai pois käytöstä

  • Kuittaukset käytössä tai pois käytöstä

  • Tapahtumailmoitukset käytössä tai pois käytöstä

  • Kameran suurin payload-koko tavuina

  • Nykyiset uudelleenlähetysten yritysmäärät, aikakatkaisu ja kyselyparametrit

Isäntä vertaa näitä omaan kokoonpanoonsa. Jos isännän täytyy muuttaa jotakin niistä – esimerkiksi neuvotella pienempi suurin payload, koska sen vastaanottopuskuri on pienempi kuin kameran – se lähettää PROTO_SET_CAPS-paketin (käskykoodi 0x02) uusilla arvoilla. Kamera konfiguroi pinonsa uudelleen ja kuittaa. Tästä eteenpäin jokainen siirtoyhteyden ylittävä paketti noudattaa tuota jaettua sopimusta.

Jos isäntä ei ohita mitään, oletukset ovat kaikki päällä: CRC-tarkistus, sekvenssinumeroiden seuranta, kuittaukset ja tapahtumailmoitukset. Oletusarvoinen suurin payload on kameran korttikohtainen puskuri vähennettynä 14 tavun kehystysylimäärällä (10 tavun otsikko plus 4 tavun lopussa oleva payload-CRC). Useimpiin kamera-kannettava-töihin oletukset ovat oikea lähtökohta; luotettavuussivu käsittelee, milloin ja miksi sovellus kytkee osia niistä pois.

12.4.3. Kanavien etsintä

Kyvykkyyksien jälkeen isäntä lähettää CHANNEL_LIST-paketin (käskykoodi 0x20). Kamera vastaa luettelolla rekisteröidyistä kanavista – neljä sisäänrakennettua (stdin, stdout, stream, profile) plus kaikki, jotka sovellus on rekisteröinyt funktiolla protocol.register(). Jokainen merkintä sisältää kanavan ID:n, sen nimen ja sen kyvykkyysliput (vain luku, vain kirjoitus, lukittavissa).

Isäntä tallettaa luettelon ja käyttää sitä myöhemmin, kun sovelluskoodi pyytää channel_read("frame") tai channel_write("config", ...) – nimi haetaan kanavan ID:ksi kerran, ja sitten jokainen sitä seuraava paketti kyseisellä kanavalla käyttää ID:tä suoraan.

Jos kamera rekisteröi uuden kanavan alkuperäisen luettelon jälkeen – yleistä, kun sovellus alkaa toimia kättelyn jälkeen – kamera lähettää CHANNEL_REGISTERED-tapahtumapaketin. Isäntä kuuntelee niitä ja päivittää sisäisen kanavaluettelonsa, joten varhain liittynyt isäntäskripti näkee uusien rekisteröityjen kanavien ilmestyvän ilman uudelleenkäynnistystä.

Kättely vie muutaman edestakaisen viestin yhteyden muodostuksessa eikä koskaan toistu sen jälkeen. Vakaan tilan liikenne on pelkkiä paketteja: kehystettyjä tavuja sisään, kehystettyjä tavuja ulos, kanavien ID:t jo tiedossa molemmissa päissä.