12.1. Proč knihovna protokolu

K přenosu bajtů z kamery do hostitelského PC stačí pár kabelů a přenosová rychlost (baud rate). USB-CDC i UART poskytují programu kamery proud, kde write vkládá bajty na jednom konci a read je odebírá na druhém. Co tedy knihovna protokolu k tomu přidává navíc?

Tři věci, které byste museli pokaždé napsat sami, kdybyste se pokusili postavit seriózní kanál mezi kamerou a hostitelem přímo nad surovými bajty:

Rámcování (framing). Bajtový proud nemá žádnou vlastní strukturu. Kamera zapíše temp=42 a hostitel přečte temp= plus přerušení, které dorazí později, pak 42 plus následující zprávu začínající humid=..., která už do toho přechází. Bajty nemají hranice. Každé netriviální hostitelské spojení nakonec vymyslí nějaký oddělovač – \n mezi zprávami, hlavičky s předponou délky, escape sekvence pro binární data – aby příjemce věděl, kde jedna zpráva končí a další začíná. Knihovna protokolu vám dává jednotný formát paketu se synchronizačním slovem a polem délky, takže příjemce nikdy nemusí hádat.

Spolehlivost. USB-CDC za běžného provozu bajty tiše neztrácí, ale UART ano (když hostitel nezačne port obsluhovat dostatečně rychle) a sériový kabel odpojený a znovu zapojený může jednu stranu zanechat s neúplným paketem. Správné je poškození detekovat, požádat druhou stranu o opětovné odeslání a aplikačnímu kódu předávat pouze zprávy, které dorazily nepoškozené. Knihovna protokolu to dělá pro každý paket pomocí CRC a potvrzení (acknowledgement) pro každý paket – ve výchozím nastavení zapnuto; aplikace opětovná odeslání nevidí.

Multiplexování. Mezi kamerou a hostitelem je přesně jeden USB-CDC port. Pokud kamera streamuje obraz a zároveň jí hostitel posílá konfiguraci a zároveň IDE čte stdout pro výstup z print, musí všechny tři výměny sdílet tento jediný bajtový proud. Knihovna protokolu dává každému nezávislému proudu číslo kanálu, umožňuje kameře pro každý z nich zaregistrovat třídu v Pythonu a brání tomu, aby čtení hostitele na jednotlivých kanálech vzájemně kolidovala. Z pohledu aplikačního kódu vypadá každý kanál jako jeho vlastní soukromé spojení.

12.1.1. Proč si to nenapsat sami

Můžete. Správně zprovoznit všechny tři věci na sériové lince zabere pár týdnů a další pár týdnů zabere, aby rámcování čistě zvládalo zotavení po připojení za chodu (hot-plug), opětovná odeslání fungovala bez plýtvání energií na výměny tam a zpět a multiplexer přežil neúplná čtení, aniž by zaměnil bajty jednoho kanálu za bajty jiného.

Knihovna protokolu už tuto práci odvedla, byla ověřena na každé podporované kameře a má odpovídající knihovny na straně hostitele, které mluví stejným přenosovým formátem. Její použití znamená, že kód na straně kamery je jedna malá třída na kanál a kód na straně hostitele je objekt Camera s metodami channel_read a channel_write. Ušetřený mentální prostor jde na to, co aplikace skutečně dělá.

Tato kapitola učí protokol od základů: přenosový formát, pravidla rámcování, mechanismy spolehlivosti, model kanálů a nakonec třídy v Pythonu na obou koncích. Na konci dokáže čtenář postavit hostitelské GUI, které komunikuje s kamerou, skript, který streamuje data ze senzoru z kamery do notebooku, a takový druh interaktivního kalibračního nástroje, jaký je součástí openmv-projects/tools/.