12.1. Perché una libreria di protocollo

Una coppia di cavi e un baud rate sono sufficienti per spostare byte da una camera a un PC host. Sia USB-CDC che UART forniscono al programma della camera un flusso in cui write inserisce byte da un capo e read li preleva dall’altro. Quindi cosa aggiunge una libreria di protocollo a tutto questo?

Tre cose che dovresti scrivere tu stesso, ogni volta, se provassi a costruire un canale serio da camera a host direttamente sui byte grezzi:

Framing. Un flusso di byte non ha alcuna struttura intrinseca. La camera scrive temp=42 e l’host legge temp= più un interrupt che arriva più tardi, poi 42 più il messaggio successivo che inizia con humid=... già sovrapposto. I byte non hanno confini. Ogni collegamento host non banale finisce per inventare qualche marcatore – \n tra i messaggi, intestazioni con prefisso di lunghezza, sequenze di escape per i payload binari – in modo che il ricevitore sappia dove finisce un messaggio e inizia il successivo. La libreria di protocollo ti offre un formato di pacchetto uniforme con una parola di sincronizzazione e un campo di lunghezza, e il ricevitore non deve mai tirare a indovinare.

Affidabilità. USB-CDC non perde byte silenziosamente durante il normale funzionamento, ma UART sì (quando l’host smette di servire la porta abbastanza rapidamente), e un cavo seriale scollegato e ricollegato può lasciare un lato con un pacchetto parziale. La cosa giusta da fare è rilevare la corruzione, chiedere all’altro lato di ritrasmettere e consegnare al codice applicativo solo messaggi arrivati intatti. La libreria di protocollo fa questo per ogni pacchetto con un CRC e conferme per pacchetto – attive per impostazione predefinita; l’applicazione non vede i tentativi di ritrasmissione.

Multiplexing. C’è esattamente una porta USB-CDC tra la camera e l’host. Se la camera sta trasmettendo un’immagine e l’host le sta inviando la configurazione e l’IDE sta leggendo stdout per l’output di print, tutti e tre gli scambi devono condividere quell’unico flusso di byte. La libreria di protocollo assegna a ogni flusso indipendente un numero di canale, consente alla camera di registrare una classe Python per ciascuno e impedisce che le letture dell’host su un canale interferiscano con le altre. Dal punto di vista del codice applicativo, ogni canale appare come un proprio collegamento privato.

12.1.1. Perché non scriverlo da soli

Puoi farlo. Sono alcune settimane di lavoro per far funzionare correttamente tutti e tre su una linea seriale e altre settimane per far gestire al framing in modo pulito il ripristino a caldo, per far funzionare le ritrasmissioni senza sprecare energia in round-trip, e per far sopravvivere il multiplexer alle letture parziali senza corrompere i byte di un canale facendoli finire in quelli di un altro.

La libreria di protocollo ha già svolto quel lavoro, è stata convalidata su ogni camera supportata e dispone di librerie corrispondenti sul lato host che parlano lo stesso formato di trasmissione. Usarla significa che il codice lato camera è una piccola classe per canale e il codice lato host è un oggetto Camera con i metodi channel_read e channel_write. Lo spazio mentale risparmiato va a tutto ciò che l’applicazione fa effettivamente.

Questo capitolo insegna il protocollo dalle fondamenta: il formato di trasmissione, le regole di framing, il meccanismo di affidabilità, il modello a canali e infine le classi Python a entrambe le estremità. Alla fine il lettore sarà in grado di costruire una GUI host che dialoga con la camera, uno script che trasmette dati del sensore dalla camera al laptop e quel tipo di strumento di calibrazione interattivo incluso in openmv-projects/tools/.