Comme la communication série asynchrone est largement répandue parmi les appareils électroniques, même de nos jours, je pense que beaucoup d'entre nous ont rencontré une telle question de temps en temps. Considérez un appareil électronique D
et un ordinateur PC
connecté à une ligne série (RS-232 ou similaire) et requis pour échanger des informations en continu . C'est-à-dire qu'il PC
envoie un cadre de commande chacun X ms
et D
répond avec un rapport d'état / un cadre de télémétrie chacun Y ms
(le rapport peut être envoyé en réponse à des demandes ou indépendamment - peu importe ici). Les trames de communication peuvent contenir toutes les données binaires arbitraires . En supposant que les trames de communication sont des paquets de longueur fixe.
Le problème:
Comme le protocole est continu, le côté récepteur peut perdre la synchronisation ou simplement «se joindre» au milieu d'une trame envoyée en cours, il ne saura donc pas où se trouve le début de la trame (SOF). Si les données ont une signification différente en fonction de leur position par rapport au SOF, les données reçues seront corrompues, potentiellement pour toujours.
La solution recherchée
Schéma de délimitation / synchronisation fiable pour détecter le SOF avec un temps de récupération court (c'est-à-dire qu'il ne faut pas plus de, disons 1 trame pour se resynchroniser).
Les techniques existantes que je connais (et en utilise):
1) En-tête / somme de contrôle - SOF comme valeur d'octet prédéfinie. Somme de contrôle à la fin du cadre.
- Avantages: Simple.
- Inconvénients: pas fiable. Temps de récupération inconnu.
2) Remplissage d'octets:
- Avantages: récupération fiable et rapide, peut être utilisée avec n'importe quel matériel
- Inconvénients: pas adapté à la communication basée sur une trame de taille fixe
3) Marquage du 9e bit - ajoutez chaque octet au bit supplémentaire, tandis que SOF marqué avec 1
et les octets de données sont marqués avec 0
:
- Avantages: récupération fiable et rapide
- Inconvénients: nécessite un support matériel. Non directement pris en charge par la plupart du
PC
matériel et des logiciels.
4) Marquage du 8e bit - sorte d'émulation de ce qui précède, tout en utilisant le 8e bit au lieu du 9e, ce qui ne laisse que 7 bits pour chaque mot de données.
- Avantages: Récupération fiable et rapide, peut être utilisée avec n'importe quel matériel.
- Inconvénients: nécessite un schéma de codage / décodage de / vers la représentation conventionnelle 8 bits vers / depuis la représentation 7 bits. Un peu de gaspillage.
5) Timeout based - supposez le SOF comme le premier octet après un certain temps d'inactivité défini.
- Avantages: Pas de surcharge de données, simple.
- Inconvénients: pas si fiable. Ne fonctionnera pas bien avec des systèmes de synchronisation médiocres comme, par exemple, un PC Windows. Surdébit potentiel de débit.
Question: Quelles sont les autres techniques / solutions possibles pour résoudre le problème? Pouvez-vous indiquer les inconvénients dans la liste ci-dessus qui peuvent être facilement contournés, les supprimant ainsi? Comment concevez-vous (ou voulez-vous) concevoir votre protocole système?