12.1. Miért kell protokollkönyvtár

Egy pár kábel és egy átviteli sebesség (baud) elég ahhoz, hogy bájtokat mozgassunk a kameráról egy gazda PC-re. Az USB-CDC és az UART egyaránt olyan adatfolyamot ad a kamera programjának, ahol a write bájtokat tölt be az egyik végén, a read pedig kiveszi azokat a másikon. Mit ad tehát ehhez hozzá egy protokollkönyvtár?

Három dolgot, amelyet minden alkalommal magadnak kellene megírnod, ha komoly kamera-gazda csatornát próbálnál nyers bájtokra közvetlenül felépíteni:

Keretezés. Egy bájtfolyamnak nincs belső struktúrája. A kamera kiírja a temp=42 üzenetet, a gazda pedig beolvassa a temp= részt, majd egy később érkező megszakítást, aztán a 42-t és a következő, humid=... kezdetű üzenetet, amely már belefolyik az előzőbe. A bájtoknak nincsenek határaik. Minden nem triviális gazdakapcsolat előbb-utóbb valamilyen jelzőt talál ki – \n az üzenetek között, hosszal előtagolt fejléceket, escape-szekvenciákat a bináris hasznos teherhez –, hogy a fogadó tudja, hol ér véget az egyik üzenet, és hol kezdődik a következő. A protokollkönyvtár egységes csomagformátumot ad egy szinkronszóval és egy hosszmezővel, így a fogadónak soha nem kell találgatnia.

Megbízhatóság. Az USB-CDC normál működés közben nem ejt el csendben bájtokat, az UART viszont igen (amikor a gazda nem szolgálja ki elég gyorsan a portot), és egy soros kábel kihúzása és visszadugása az egyik oldalon részleges csomagot hagyhat hátra. A helyes eljárás az, ha észleljük a sérülést, megkérjük a másik oldalt az újraküldésre, és csak sértetlenül megérkezett üzeneteket adunk át az alkalmazás kódjának. A protokollkönyvtár ezt minden csomagnál elvégzi egy CRC-vel és csomagonkénti nyugtázással – alapértelmezetten bekapcsolva; az alkalmazás nem látja az újrapróbálkozásokat.

Multiplexelés. A kamera és a gazda között pontosan egy USB-CDC port van. Ha a kamera egy képet streamel, és a gazda konfigurációt küld neki, és az IDE a stdout-ot olvassa a print kimenetéért, mind a három adatcserének osztoznia kell ezen az egyetlen bájtfolyamon. A protokollkönyvtár minden független adatfolyamnak ad egy csatorna-számot, lehetővé teszi, hogy a kamera mindegyikhez regisztráljon egy Python osztályt, és megakadályozza, hogy a gazda egyik csatornán végzett olvasásai zavarják a többit. Az alkalmazás kódja felől nézve minden csatorna saját privát kapcsolatnak tűnik.

12.1.1. Miért ne írd meg magad

Megteheted. Néhány hét munka, hogy mindhármat helyesen működtesd egy soros vonalon, és további néhány hét, hogy a keretezés tisztán kezelje a melegcserélés utáni helyreállítást, az újraküldések körutak nélkül se pazaroljanak energiát, és a multiplexer túléljen részleges olvasásokat anélkül, hogy az egyik csatorna bájtjait a másikba keverné.

A protokollkönyvtár ezt a munkát már elvégezte, minden támogatott kamerán validálva van, és a gazda oldalon vannak hozzá illeszkedő könyvtárak, amelyek ugyanazt a vezetékformátumot beszélik. A használatával a kamera oldali kód csatornánként egyetlen kis osztály, a gazda oldali kód pedig egy Camera objektum a channel_read és channel_write metódusokkal. A felszabadult fejmunka odakerül, amit az alkalmazás valóban csinál.

Ez a fejezet alapoktól tanítja a protokollt: a vezetékformátumot, a keretezési szabályokat, a megbízhatósági gépezetet, a csatornamodellt, végül pedig a Python osztályokat mindkét végen. A végére az olvasó képes lesz olyan gazda GUI-t építeni, amely beszél a kamerával, olyan szkriptet, amely érzékelőadatokat streamel a kameráról a laptopra, és olyan interaktív kalibrációs eszközt, amilyen a openmv-projects/tools/ alatt található.