12.1. Pourquoi une bibliothèque de protocole

Une paire de câbles et un débit en bauds suffisent pour transférer des octets d’une caméra vers un PC hôte. L’USB-CDC et l’UART donnent tous deux au programme de la caméra un flux où write insère des octets d’un côté et read les récupère de l’autre. Alors, qu’est-ce qu’une bibliothèque de protocole ajoute par-dessus cela ?

Trois choses que vous devriez écrire vous-même, à chaque fois, si vous tentiez de construire un canal sérieux caméra-vers-hôte directement à partir d’octets bruts :

Le découpage en trames. Un flux d’octets n’a aucune structure intrinsèque. La caméra écrit temp=42 et l’hôte lit temp= suivi d’une interruption qui arrive plus tard, puis 42 accolé au message suivant qui commence déjà par humid=.... Les octets n’ont pas de frontières. Toute liaison hôte non triviale finit par inventer un marqueur quelconque – \n entre les messages, des en-têtes préfixés par la longueur, des séquences d’échappement pour les charges utiles binaires – afin que le récepteur sache où un message se termine et où le suivant commence. La bibliothèque de protocole vous fournit un format de paquet uniforme avec un mot de synchronisation et un champ de longueur, et le récepteur n’a jamais à deviner.

La fiabilité. L’USB-CDC ne perd pas d’octets silencieusement en fonctionnement normal, mais l’UART le fait (lorsque l’hôte cesse de desservir le port assez rapidement), et un câble série débranché puis rebranché peut laisser un côté avec un paquet partiel. La bonne chose à faire est de détecter la corruption, de demander à l’autre côté de retransmettre, et de ne jamais transmettre au code applicatif que des messages arrivés intacts. La bibliothèque de protocole fait cela pour chaque paquet à l’aide d’un CRC et d’accusés de réception par paquet – activés par défaut ; l’application ne voit pas les retransmissions.

Le multiplexage. Il n’existe qu’un seul port USB-CDC entre la caméra et l’hôte. Si la caméra diffuse une image et que l’hôte lui envoie sa configuration et que l’IDE lit stdout pour la sortie de print, ces trois échanges doivent partager cet unique flux d’octets. La bibliothèque de protocole attribue à chaque flux indépendant un numéro de canal, permet à la caméra d’enregistrer une classe Python pour chacun, et empêche les lectures de l’hôte sur chaque canal d’interférer avec les autres. Du point de vue du code applicatif, chaque canal ressemble à sa propre liaison privée.

12.1.1. Pourquoi ne pas l’écrire vous-même

Vous le pouvez. Cela représente quelques semaines de travail pour obtenir les trois éléments correctement sur une ligne série, et quelques semaines de plus pour que le découpage en trames gère proprement la récupération après branchement à chaud, que les retransmissions fonctionnent sans gaspiller d’énergie en allers-retours, et que le multiplexeur survive aux lectures partielles sans corrompre les octets d’un canal dans ceux d’un autre.

La bibliothèque de protocole a déjà accompli ce travail, a été validée sur chaque caméra prise en charge, et dispose de bibliothèques correspondantes côté hôte qui parlent le même format de transmission. L’utiliser signifie que le code côté caméra se résume à une petite classe par canal et que le code côté hôte est un objet Camera doté des méthodes channel_read et channel_write. L’espace mental ainsi économisé est consacré à ce que l’application fait réellement.

Ce chapitre enseigne le protocole depuis la base : le format de transmission, les règles de découpage en trames, la mécanique de fiabilité, le modèle de canaux et, enfin, les classes Python aux deux extrémités. À la fin, le lecteur sera capable de construire une interface graphique hôte qui dialogue avec la caméra, un script qui diffuse les données du capteur de la caméra vers un ordinateur portable, et le genre d’outil de calibration interactif fourni dans openmv-projects/tools/.