12.1. Porquê uma biblioteca de protocolo

Um par de cabos e uma taxa de baud é suficiente para mover bytes de uma câmara para um PC anfitrião. USB-CDC e UART fornecem ambos ao programa da câmara um fluxo onde write coloca bytes numa extremidade e read os retira pela outra. Então o que é que uma biblioteca de protocolo acrescenta a isso?

Três coisas que teria de escrever você mesmo, sempre, se tentasse construir um canal sério entre câmara e anfitrião diretamente em bytes brutos:

Enquadramento. Um fluxo de bytes não tem estrutura inerente. A câmara escreve temp=42 e o anfitrião lê temp= mais uma interrupção que chega mais tarde, depois 42 mais a próxima mensagem a começar com humid=... já a misturar-se. Os bytes não têm fronteiras. Cada ligação ao anfitrião não trivial acaba por inventar algum marcador – \n entre mensagens, cabeçalhos com prefixo de comprimento, sequências de escape para payloads binários – para que o recetor saiba onde termina uma mensagem e começa a seguinte. A biblioteca de protocolo fornece um formato de pacote uniforme com uma palavra de sincronização e um campo de comprimento, e o recetor nunca tem de adivinhar.

Fiabilidade. USB-CDC não perde bytes silenciosamente em funcionamento normal, mas UART perde (quando o anfitrião demora demasiado a servir a porta), e um cabo série desligado e reconectado pode deixar um lado com um pacote parcial. A coisa certa a fazer é detetar a corrupção, pedir ao outro lado para retransmitir, e apenas entregar ao código da aplicação mensagens que chegaram intactas. A biblioteca de protocolo faz isso para cada pacote com um CRC e reconhecimentos por pacote – ativados por omissão; a aplicação não vê as retransmissões.

Multiplexagem. Existe exatamente uma porta USB-CDC entre a câmara e o anfitrião. Se a câmara está a transmitir uma imagem e o anfitrião está a enviar-lhe configuração e o IDE está a ler stdout para saída de print, as três trocas têm de partilhar esse único fluxo de bytes. A biblioteca de protocolo atribui a cada fluxo independente um número de canal, permite à câmara registar uma classe Python para cada um, e impede que as leituras do anfitrião num canal interfiram com os outros. Do ponto de vista do código da aplicação, cada canal parece uma ligação privada própria.

12.1.1. Porquê não escrever isso você mesmo

Pode. São algumas semanas de trabalho para acertar nos três numa linha série e mais algumas semanas para fazer o enquadramento gerir a recuperação de ligação a quente de forma limpa, as retransmissões funcionarem sem desperdiçar energia em viagens de ida e volta, e o multiplexador sobreviver a leituras parciais sem corromper os bytes de um canal para outro.

A biblioteca de protocolo já fez esse trabalho, foi validada em todas as câmaras suportadas, e tem bibliotecas correspondentes no lado do anfitrião que falam o mesmo formato de linha. Utilizá-la significa que o código do lado da câmara é uma pequena classe por canal e o código do lado do anfitrião é um objeto Camera com métodos channel_read e channel_write. O espaço mental poupado vai para o que a aplicação realmente faz.

Este capítulo ensina o protocolo de raiz: o formato de linha, as regras de enquadramento, o mecanismo de fiabilidade, o modelo de canais, e finalmente as classes Python em ambas as extremidades. No final, o leitor pode construir uma GUI de anfitrião que fala com a câmara, um script que transmite dados de sensor da câmara para um portátil, e o tipo de ferramenta de calibração interativa que é incluída em openmv-projects/tools/.