12.1. Miksi protokollakirjasto

Kaapelipari ja siirtonopeus riittävät siirtämään tavuja kamerasta isäntä-PC:lle. Sekä USB-CDC että UART antavat kameran ohjelmalle tietovirran, jossa write työntää tavuja toisesta päästä sisään ja read ottaa niitä toisesta päästä ulos. Mitä protokollakirjasto siis lisää tämän päälle?

Kolme asiaa, jotka joutuisit kirjoittamaan itse joka kerta, jos yrittäisit rakentaa vakavasti otettavan kamera-isäntäkanavan suoraan raakojen tavujen päälle:

Kehystys. Tavuvirralla ei ole sisäänrakennettua rakennetta. Kamera kirjoittaa temp=42 ja isäntä lukee temp= sekä myöhemmin saapuvan keskeytyksen, sitten 42 ja seuraavan viestin alun humid=..., joka jo sotkeutuu siihen. Tavuilla ei ole rajoja. Jokainen vähänkään monimutkaisempi isäntälinkki päätyy keksimään jonkin merkin – \n viestien väliin, pituusetuliitteiset otsikot, ohjausmerkit binääripayloadeille – jotta vastaanottaja tietää, mihin yksi viesti loppuu ja seuraava alkaa. Protokollakirjasto antaa sinulle yhtenäisen pakettimuodon, jossa on synkronointisana ja pituuskenttä, eikä vastaanottajan tarvitse koskaan arvata.

Luotettavuus. USB-CDC ei normaalitoiminnassa pudota tavuja huomaamatta, mutta UART pudottaa (kun isäntä ei ehdi käsitellä porttia riittävän nopeasti), ja irrotettu ja uudelleen kytketty sarjakaapeli voi jättää toisen pään keskeneräisen paketin varaan. Oikea ratkaisu on havaita vioittuminen, pyytää toista päätä lähettämään uudelleen ja antaa sovelluskoodille vain ehjinä saapuneita viestejä. Protokollakirjasto tekee tämän jokaiselle paketille CRC:n ja pakettikohtaisten kuittausten avulla – oletuksena päällä; sovellus ei näe uudelleenlähetyksiä.

Kanavointi. Kameran ja isännän välillä on tasan yksi USB-CDC-portti. Jos kamera virtauttaa kuvaa ja isäntä lähettää sille asetuksia ja IDE lukee stdout-virtaa print-tulosteita varten, kaikkien kolmen vaihdon on jaettava tuo yksi tavuvirta. Protokollakirjasto antaa jokaiselle itsenäiselle virralle kanava-numeron, antaa kameran rekisteröidä kullekin Python-luokan ja estää isännän kunkin kanavan lukuja häiritsemästä toisiaan. Sovelluskoodista katsottuna jokainen kanava näyttää omalta yksityiseltä linkiltään.

12.1.1. Miksi et kirjoittaisi sitä itse

Voit kyllä. Vie muutaman viikon työn saada kaikki kolme oikein sarjalinjalla ja toiset muutamat viikot saada kehystys käsittelemään kuumakytkennästä toipumisen siististi, uudelleenlähetykset toimimaan tuhlaamatta energiaa edestakaisiin viesteihin ja kanavoijan selviämään osittaisista luvuista sotkematta yhden kanavan tavuja toiseen.

Protokollakirjasto on jo tehnyt tuon työn, se on validoitu jokaisella tuetulla kameralla, ja sillä on isäntäpuolella vastaavat kirjastot, jotka puhuvat samaa siirtomuotoa. Sen käyttäminen tarkoittaa, että kamerapuolen koodi on yksi pieni luokka kanavaa kohti ja isäntäpuolen koodi on Camera-objekti, jolla on channel_read- ja channel_write-metodit. Säästetty ajattelutila siirtyy siihen, mitä sovellus todella tekee.

Tämä luku opettaa protokollan perusteista alkaen: siirtomuodon, kehystyssäännöt, luotettavuuskoneiston, kanavamallin ja lopulta Python-luokat molemmissa päissä. Loppuun mennessä lukija osaa rakentaa isännän graafisen käyttöliittymän, joka keskustelee kameran kanssa, skriptin, joka virtauttaa sensoridataa kamerasta kannettavalle, ja sellaisen interaktiivisen kalibrointityökalun, jollainen toimitetaan paketissa openmv-projects/tools/.