12.1. Por qué una biblioteca de protocolo

Un par de cables y una velocidad en baudios bastan para mover bytes desde una cámara hasta un PC anfitrión. Tanto USB-CDC como UART le dan al programa de la cámara un flujo donde write introduce bytes por un extremo y read los extrae por el otro. Entonces, ¿qué añade una biblioteca de protocolo sobre eso?

Tres cosas que tendrías que escribir tú mismo, cada vez, si intentaras construir un canal serio de cámara a anfitrión directamente sobre bytes en bruto:

Encuadre (framing). Un flujo de bytes no tiene estructura inherente. La cámara escribe temp=42 y el anfitrión lee temp= más una interrupción que llega más tarde, luego 42 más el siguiente mensaje que empieza por humid=... ya entremezclándose con él. Los bytes no tienen límites. Todo enlace de anfitrión no trivial acaba inventando algún marcador – \n entre mensajes, encabezados con prefijo de longitud, secuencias de escape para cargas binarias – para que el receptor sepa dónde termina un mensaje y empieza el siguiente. La biblioteca de protocolo te da un formato de paquete uniforme con una palabra de sincronización y un campo de longitud, y el receptor nunca tiene que adivinar.

Fiabilidad. USB-CDC no descarta bytes de forma silenciosa en condiciones normales, pero UART sí lo hace (cuando el anfitrión deja de atender el puerto con suficiente rapidez), y un cable serie desconectado y vuelto a conectar puede dejar a un lado con un paquete parcial. Lo correcto es detectar la corrupción, pedir al otro lado que retransmita y entregar al código de aplicación únicamente los mensajes que llegaron intactos. La biblioteca de protocolo hace eso con cada paquete mediante un CRC y confirmaciones por paquete – activadas por defecto; la aplicación no ve los reintentos.

Multiplexación. Existe exactamente un puerto USB-CDC entre la cámara y el anfitrión. Si la cámara está transmitiendo una imagen y el anfitrión le está enviando configuración y el IDE está leyendo stdout para la salida de print, los tres intercambios tienen que compartir ese único flujo de bytes. La biblioteca de protocolo le da a cada flujo independiente un número de canal, permite que la cámara registre una clase de Python para cada uno y evita que las lecturas del anfitrión en cada canal interfieran con las demás. Desde el código de aplicación, cada canal parece su propio enlace privado.

12.1.1. Por qué no escribirlo tú mismo

Puedes hacerlo. Son unas semanas de trabajo conseguir que las tres cosas funcionen correctamente sobre una línea serie, y otras tantas semanas para que el encuadre maneje limpiamente la recuperación de conexión en caliente, las retransmisiones funcionen sin malgastar energía en idas y vueltas, y el multiplexor sobreviva a lecturas parciales sin corromper los bytes de un canal mezclándolos con los de otro.

La biblioteca de protocolo ya ha hecho ese trabajo, ha sido validada en todas las cámaras admitidas y tiene bibliotecas equivalentes en el lado del anfitrión que hablan el mismo formato de cable. Usarla significa que el código del lado de la cámara es una pequeña clase por canal y el código del lado del anfitrión es un objeto Camera con los métodos channel_read y channel_write. El espacio mental ahorrado se dedica a lo que la aplicación realmente hace.

Este capítulo enseña el protocolo desde cero: el formato de cable, las reglas de encuadre, el mecanismo de fiabilidad, el modelo de canales y, finalmente, las clases de Python en ambos extremos. Al terminar, el lector puede construir una GUI de anfitrión que se comunique con la cámara, un script que transmita datos de sensores desde la cámara al portátil, y el tipo de herramienta de calibración interactiva que se incluye en openmv-projects/tools/.