Pour garantir la transmission et s'affranchir des erreurs, on a le choix entre un protocole interactif ou à répétition.
1) Protocole simplex répétitif (par exemple : clés électroniques ou protocole X10) :
2) Protocole duplex interactif (par exemple : protocole I2C) :
Avec ce protocole :
En fait, on n'est pas obligé de faire un choix. On peut même considérer que chaque terminal peut avoir un protocole particulier. Le central choisira en fonction de la destination.
Dans le cas d'une liaison filaire, le bus RS485 peut être partagé avec une transmission analogique différentielle, dont le mode commun est plus haut que 5V. Dans ce cas, il sera fréquent d'avoir des impulsions qui seront vues comme parasites par les récepteurs RS485.
Si on utilise autre chose que le bus RS485 (radio ou optique, par exemple), la présence de parasites est hautement probable.
On constate que la gestion des erreurs de transmission et donc la robustesse du protocole est de la plus haute importance.
TYPE DE DETECTION D'ERREUR |
|||||
Matériel |
Bit de parité |
Duplication quartet |
Répétition octet |
checksum + Accusé de réception |
|
TYPES D'ERREURS ET CAPACITE A DETECTER CES ERREURS |
|||||
Erreur de format : exemple : on attendait un bit stop et c'est un zéro. |
oui |
||||
Parasite non différentiel |
possible |
||||
Erreur de start : un parasite est compris comme le front descendant d'un bit start. Il s'en suit la réception fictive d'un octet dont des LSB sont nuls, de la forme : FF, FE, FC, F8, F0, E0, C0, 80, 00 selon la longueur du parasite. |
non |
50% |
75% |
100% |
100% |
Erreur sur un bit : typiquement un parasite différentiel au moment de l'échantillonnage bit |
non |
100% |
100% |
100% |
100% |
Idem mais sur plusieurs bits |
non |
50% |
100% |
100% |
100% |
IMPLANTATION |
|||||
overhead en taille sur la liaison |
0 |
+1/8 |
2 fois |
N fois |
+8 octets typ |
taille du logiciel (base MCS51) |
4 inst |
30 instr |
30 instr + timer |
30 instr + gestion buffer |
|
espionnage par PC sur port COM |
oui |
non |
oui |
possible |
|
difficulté d'implantation, de validation, coût |
0 |
epsilon |
€ |
€€ |
€€€ |
Impression générale |
très simple, pas cher, mais peu performant |
valide en mode simplex |
valide en mode duplex |
Deux cas présents selon les capacités du terminal adressé :
On peut aussi cumuler les 2 méthodes, c'est à dire duppliquer les données sensibles (adresses par exemple) tout en utilisant un accusé de réception par dessus.
Les données à transmettre doivent être précédées de l’adresse du terminal destinataire.
On peut prévoir aussi un champ pour mettre l’adresse du maître émetteur.
On peut aussi prévoir un champ pour mettre la longueur du message, et pourquoi pas enfin un champ pour mettre une somme de contrôle.
On vient de ré-inventer le protocole RFC768, UDP (User Datagram Protocol) utilisé dans la mouvance Internet, basé sur des mots de 32 bits, donc offrant des adresses sur 16 bits.
0.......7 8.....15 16....23 24.....31
+--------+--------+--------+--------+
| Central | Terminal |
+--------+--------+--------+--------+
| Length | Checksum |
+--------+--------+--------+--------+
| data octets ...
+---------------- ...
Champ | Signification |
Central | Adresse du central |
Terminal | Adresse du terminal adressé |
Length | Nombre d'octets dans le champs data |
Checksum | Somme de tous les octets transmis |
On pourrait aller jusqu’au protocole TCP (Transmission Control Protocol, RFC793) mais il est bien compliqué pour faire de la domotique. Toutefois, il présente l'énorme avantage d'être un standard industriel très fort.
Bref on considère une encapsulation de type RFC768, un peu aménagée pour permettre l’utilisation de terminaux ASCII standards et simplifier son implantation dans un µcontrôleur.
Exemple : U,U,0,0,0,0x01,1,d est un datagramme valide (‘d’=somme de contrôle binaire)
Le central envoie un message à un terminal.
Si celui ci reçoit un message où il décode son adresse, il doit renvoyer un accusé de réception composé comme un message. Il faut indiquer comment le datagramme a été reçu, et pouvoir associer ce compte rendu au datagramme initial. Une solution simple consiste à répéter le check sum du datagramme initial.
La réponse pourrait ainsi comporter 9 octets :
C'est le cas le plus simple. Le central répète N fois le message, le terminal adressé prends en considération le message s'il est reçu au moins P fois correctement, pendant un temps déterminé (non infini !). On utilise l'octet 5 de protocole pour indiquer le numéro de répétition du datagramme, de x1 à xF maximum.
La longueur des messages sera sans doute inférieure à 10 octets, soit 100 bits par message. A 9600 bauds cela représente une durée de 10.4 ms par message. Choisir une répétition de 10, fait que le central va passer 100 ms à émettre le même ordre. Après, tout dépend de la longueur des perturbations possibles du bus ; considérer que 3 datagrammes valides sur 10 sont suffisant, c’est prendre l’hypothèse qu’il existe au moins 3 « fenêtres » calmes de 10ms dans toute tranche de 100ms.
Il n'y a jamais de réponse à un ordre émis en répétition.
Gestion des erreurs à l'émission d'un datagramme :
Gestion des erreurs à la réception d'un détagramme :