12.1. Por que uma biblioteca de protocolo

Um par de cabos e uma taxa de transmissão (baud rate) bastam para mover bytes de uma câmera para um PC host. Tanto USB-CDC quanto UART fornecem ao programa da câmera um fluxo onde write coloca bytes em uma extremidade e read os retira da outra. Então, o que uma biblioteca de protocolo acrescenta a isso?

Três coisas que você teria de escrever sozinho, toda vez, se tentasse construir um canal sério câmera-para-host diretamente sobre bytes brutos:

Enquadramento. Um fluxo de bytes não tem estrutura inerente. A câmera escreve temp=42 e o host lê temp= mais uma interrupção que chega depois, então 42 mais a próxima mensagem começando com humid=... já se misturando a ele. Bytes não têm fronteiras. Todo link de host não trivial acaba inventando algum marcador – \n entre mensagens, cabeçalhos com prefixo de comprimento, sequências de escape para cargas binárias – para que o receptor saiba onde uma mensagem termina e a próxima começa. A biblioteca de protocolo lhe dá um formato de pacote uniforme com uma palavra de sincronização e um campo de comprimento, e o receptor nunca precisa adivinhar.

Confiabilidade. O USB-CDC não descarta bytes silenciosamente em operação normal, mas a UART descarta (quando o host para de atender a porta com rapidez suficiente), e um cabo serial desconectado e reconectado pode deixar um lado com um pacote parcial. A coisa certa a fazer é detectar a corrupção, pedir ao outro lado que retransmita e só entregar ao código da aplicação mensagens que chegaram intactas. A biblioteca de protocolo faz isso para cada pacote com um CRC e confirmações por pacote – ativadas por padrão; a aplicação não vê as retentativas.

Multiplexação. Existe exatamente uma porta USB-CDC entre a câmera e o host. Se a câmera está transmitindo uma imagem e o host está enviando configuração a ela e o IDE está lendo stdout para a saída de print, todas as três trocas têm de compartilhar esse único fluxo de bytes. A biblioteca de protocolo dá a cada fluxo independente um número de canal, permite que a câmera registre uma classe Python para cada um e impede que as leituras do host em cada canal interfiram nas dos outros. Do ponto de vista do código da aplicação, cada canal parece seu próprio link privado.

12.1.1. Por que não escrever isso você mesmo

Você pode. São algumas semanas de trabalho para acertar os três corretamente em uma linha serial e mais algumas semanas para fazer o enquadramento lidar com a recuperação de hot-plug de forma limpa, as retransmissões funcionarem sem gastar energia em idas e vindas, e o multiplexador sobreviver a leituras parciais sem corromper os bytes de um canal nos de outro.

A biblioteca de protocolo já fez esse trabalho, foi validada em todas as câmeras suportadas e tem bibliotecas correspondentes no lado do host que falam o mesmo formato de transmissão. Usá-la significa que o código no lado da câmera é uma pequena classe por canal e o código no lado do host é um objeto Camera com os métodos channel_read e channel_write. O espaço mental economizado vai para o que quer que a aplicação realmente faça.

Este capítulo ensina o protocolo desde o início: o formato de transmissão, as regras de enquadramento, o maquinário de confiabilidade, o modelo de canais e, por fim, as classes Python em ambas as pontas. Ao final, o leitor poderá construir uma GUI de host que conversa com a câmera, um script que transmite dados de sensor da câmera para o laptop e o tipo de ferramenta de calibração interativa que acompanha openmv-projects/tools/.