12.1. Varför ett protokollbibliotek

Ett par kablar och en baudhastighet räcker för att flytta bytes från en kamera till en värd-PC. Både USB-CDC och UART ger kameraprogrammet en ström där write lägger in bytes i ena änden och read tar ut dem i den andra. Så vad tillför ett protokollbibliotek utöver detta?

Tre saker som du själv skulle behöva skriva, varje gång, om du försökte bygga en seriös kanal mellan kamera och värd direkt ovanpå råa bytes:

Inramning. En byteström har ingen inneboende struktur. Kameran skriver temp=42 och värden läser temp= plus ett avbrott som kommer senare, sedan 42 plus nästa meddelande som börjar med humid=... redan på väg in i det. Bytes har inga gränser. Varje icke-trivial värdlänk slutar med att uppfinna någon sorts markör – \n mellan meddelanden, längdprefixerade huvuden, escape-sekvenser för binära nyttolaster – så att mottagaren vet var ett meddelande slutar och nästa börjar. Protokollbiblioteket ger dig ett enhetligt paketformat med ett synkord och ett längdfält, och mottagaren behöver aldrig gissa.

Tillförlitlighet. USB-CDC tappar inte bytes tyst under normal drift, men det gör UART (när värden inte betjänar porten tillräckligt snabbt), och en seriekabel som dras ut och sätts i igen kan lämna ena sidan med ett ofullständigt paket. Det rätta att göra är att upptäcka korruptionen, be den andra sidan att sända om, och endast någonsin lämna intakt anlända meddelanden till applikationskoden. Protokollbiblioteket gör detta för varje paket med en CRC och bekräftelser per paket – påslaget som standard; applikationen ser inte omsändningarna.

Multiplexning. Det finns exakt en USB-CDC-port mellan kameran och värden. Om kameran strömmar en bild och värden skickar konfiguration till den och IDE:n läser stdout för print-utdata, måste alla tre utbytena dela den enda byteströmmen. Protokollbiblioteket ger varje oberoende ström ett kanal-nummer, låter kameran registrera en Python-klass för var och en, och hindrar värdens läsningar på varje kanal från att störa de andra. Sett från applikationskoden ser varje kanal ut som sin egen privata länk.

12.1.1. Varför inte skriva det själv

Du kan. Det är några veckors arbete att få alla tre rätt på en seriell linje och ytterligare några veckor att få inramningen att hantera återställning vid varminkoppling rent, omsändningarna att fungera utan att bränna energi på tur-och-retur-anrop, och multiplexern att överleva ofullständiga läsningar utan att korrumpera en kanals bytes in i en annans.

Protokollbiblioteket har redan utfört det arbetet, har validerats på varje kamera som stöds, och har matchande bibliotek på värdsidan som talar samma trådformat. Att använda det innebär att kamerasidans kod är en liten klass per kanal och värdsidans kod är ett Camera-objekt med metoderna channel_read och channel_write. Det mentala utrymmet som sparas går till vad applikationen faktiskt gör.

Detta kapitel lär ut protokollet från grunden: trådformatet, inramningsreglerna, tillförlitlighetsmaskineriet, kanalmodellen, och slutligen Python-klasserna i båda ändarna. När du är klar kan läsaren bygga ett värd-GUI som talar med kameran, ett skript som strömmar sensordata från kamera till bärbar dator, och den sorts interaktiva kalibreringsverktyg som ingår i openmv-projects/tools/.