🍓 🚓 🧕🏾 Ballade de transfert de données 💤 💃🏻 🏇🏽

Dans les premières lignes de mon hémorragie de texte, je veux dire ce qui suit: Cela a été beaucoup écrit à ce sujet, je vais également écrire ma vision. Les interfaces standard pour la transmission d'informations sont excellentes, mais pour mes besoins, elles ne permettent pas un transfert de données satisfaisant (enfin, ou presque). J'essaierai de faire quelques ajouts afin d'amener cela à l'état qui me convient.

Il y a 2 appareils ou plus à une distance suffisamment grande (1-100 mètres) entre lesquels les données doivent être transmises. Après avoir examiné certaines interfaces (rs232 / 422/485, I2C, Ethernet), je suis arrivé à la conclusion que soit elles ne garantissent pas un transfert de données sans ambiguïté, je n'aimais pas non plus beaucoup de fils, elles ne donnent pas de réponse que les informations sont acceptées. J'ai décidé de prendre l'interface RS485 comme base - cela peut aller loin de ses avantages, 2 fils, vous pouvez connecter un tas d'appareils en même temps, c'est simple, (UART) est sur presque n'importe quel contrôleur.

Dans mon cas, le schéma classique 1 conduisant le reste des esclaves me convient. L'algorithme de messagerie est le suivant: les données sont transmises en cycles d'échange, un cycle d'échange consiste en un message qui est transmis du maître à l'esclave, en réponse le maître reçoit le message de l'esclave, tous les autres sont silencieux. Sur la même base, implémentez une demande de données depuis un appareil esclave.

Un cycle d'échange.

Pour répondre à mes besoins de transfert de données, je dois résoudre seulement deux questions. Première question: la vérification de l'octet transmis est basée sur l'interface RS-485 elle-même, mais elle ne garantit pas un octet transmis de manière fiable - si un octet est trouvé dans l'interface elle-même, il est rejeté des données reçues, mais il est toujours possible de transférer le mauvais octet - s'il a changé (il a mal tourné) ) un nombre pair de bits dans un octet. c'est-à-dire une vérification est requise pour le nombre d'octets transmis et la validité des octets dans les données transmises.

Question deux: réception d'un message de réponse à celui transmis.

Sur la première question: ce schéma est proposé: l'octet initial, l'octet du nombre de
caractères transmis dans le message entier, autre chose, l'octet de somme de contrôle (BCS), l'octet final.

Remarque: l'octet de somme de contrôle doit être considéré comme modulo 2.

Sur la base du schéma proposé, on peut juger que si la réponse ne revient pas, le suiveur n'est pas disponible. Dans ce cas, des options sont possibles lorsqu'un message endommagé atteint le suiveur et qu'il n'y répond pas, ou que le message lui parvient et qu'il envoie la réponse, mais la réponse va mal et le leader l'ignore.

Pour corriger cela, il a été accepté: si la réponse ne vient pas (ou vient mais n'est pas fiable), répéter (le nombre de fois sans folie) répéter le cycle d'échange en cours. L'erreur suivante peut se produire ici. Supposons que nous envoyions une commande indiquant à l'appareil que vous devez augmenter le volume de +1 unité. Lorsque le message parvient à l'esclave, il exécute la commande pour augmenter le volume et envoie une réponse `` ok, j'ai fait comme vous le vouliez '', mais il peut s'avérer que la réponse va mal et le présentateur ne comprend pas que la commande a déjà été exécutée et envoie à nouveau le message. Par conséquent, lors de la réception d'une commande du côté esclave, le volume sera déjà ajouté de +2 unités. Pour éviter ce phénomène, il est habituel d'introduire un identifiant (NS - numéro de message) de la différence de message. Si le numéro de message est répété, il s'agit d'un message répété et la commande spécifiée n'a pas besoin d'être exécutée,mais envoyez simplement le message de réponse précédent.

J'entre également ici 2 autres paramètres - c'est le numéro (code) de l'appareil auquel les données sont transmises et le numéro (sous-code) indiquant quelle commande doit être exécutée (ou quelles données se trouvent dans le message).

En conséquence, je vais tout rassembler et parcourir l'algorithme, en utilisant l'exemple de l'augmentation du seuil du relais par la température de 5 degrés Celsius et en prenant la lecture de la température actuelle de l'esclave pour 1 cycle d'échange: je

génère les données transmises du maître:

lorsque le message est reçu, l'esclave regarde 2 octets, où est le nombre d'octets envoyés, si le nombre d'octets envoyés est égal au nombre de reçus, alors le message n'a pas perdu d'octets, alors nous regardons l'octet de départ (caractère) si it = '$', et aussi l'octet de fin (caractère) si it = ' # '- ceci est un message de voyageant à l'esclave.

Immédiatement, je considérerai les options de message possibles du maître à l'esclave avec des erreurs dans les octets initial et final, ainsi que l'option avec une erreur dans le nombre d'octets dans le message. Je réserverai tout de suite 3 valeurs de paramètres que je considérerai correctes 2 et 3, c'est-à-dire si 2 paramètres sur 3 possibles coïncident, je considère le message comme valable.

1. octet de début = '$', nombre d'octets reçus = 7 (nombre d'octets envoyés = 7), l'octet de fin n'est pas égal à '#';
2. l'octet initial n'est pas égal à '$', le nombre d'octets reçus = 7 (le nombre d'octets envoyés = 7), l'octet final = '#';
3. octet de début = '$', nombre d'octets reçus = 7 (nombre d'octets envoyés = 7, nombre d'octets différent de 7), octet final = '#'.

Ensuite, nous calculons la somme de contrôle des 3 octets restants (octets 3, 4, 5), si elle coïncide avec le BCS, nous continuons d'analyser les données, nous examinons ces données pour cet appareil et ce qui devrait être fait dessus, dans notre cas, le code esclave est 55 et le sous-code 2 dit sur la nécessité d'ajouter 5 degrés supplémentaires au seuil du relais et dans le message de réponse pour envoyer les données de température actuelles. Je vérifie le NS s'il n'est pas égal au numéro de message précédent, puis j'exécute la commande et ajoute 5 degrés à la valeur actuelle du seuil de relais. S'ils sont égaux (NS), alors je n'effectue pas les actions indiquées, puis je procède à la formation d'un message de réponse.

application du schéma ['$'] [nombre d'octets envoyés / reçus] [...] ['#'] - avec une forte probabilité garantit qu'une telle combinaison ne pourra pas être trouvée dans les données transmises, et provoquera un faux message.

Je forme les données transmises de l'esclave sur la base du message reçu:

Le principe de traitement est le suivant: regardez 2 octets où le nombre d'octets envoyés est, si le nombre d'octets envoyés est égal au nombre d'octets reçus et aussi l'octet de début = '@' et l'octet de fin = '&' - c'est un message de l'esclave au maître. Si nécessaire, j'utilise le mécanisme 2 sur 3, similaire à celui décrit ci-dessus uniquement pour le message de réponse (pour les caractères '@' et '&'). Lors de la réception de ce message, l'hôte analyse la somme de contrôle 9 (du 3ème au 11ème) octets, si la somme de contrôle correspond, les données dans le message sont considérées comme fiables et une analyse de données plus approfondie se poursuit. Si le code, le sous-code et le NS des messages envoyés et reçus coïncident, nous continuons d'analyser la réponse au message envoyé par l'hôte. Vient ensuite l'analyse des données reçues,dans mon cas, dans le 6e octet, une valeur de 1 signifie que la commande pour augmenter de 5 degrés jusqu'au seuil de relais a réussi, les 5 octets restants indiquent les lectures de température actuelles; le 7e octet est un indicateur indiquant la fiabilité de la température transmise (c.-à-d. J'envisage l'option sur laquelle l'esclave est activé et répond, mais le capteur peut ne pas fonctionner) et 4 octets de valeurs de température flottante de type.

L'utilisation de 2 caractères de test au début et à la fin d'un message à forte probabilité garantit qu'en cas d'erreur de ne pas confondre les messages de l'esclave et du maître. Les données aléatoires (non aléatoires) dans le canal ne gâcheront pas l'échange.

Un peu sur la transmission des données de l'esclave à l'esclave, et un message centralisé à tous les esclaves du maître.

Tout d'abord, le dernier - la transmission du maître par l'esclave est effectuée en attribuant le code d'appareil 255, qui indique à l'esclave qu'il s'agit d'un message centralisé, puis il ne reste plus qu'à résoudre le problème des sous-codes communs, il peut également être groupé par codes d'appareil attribuer le code d'appareil 254 et 3 ou 4 appareils recevront un message utilisant ce code; le reste l'ignorera, naturellement, la partie de l'envoi des réponses des esclaves ne devrait pas fonctionner ici, c'est-à-dire il n'est pas garanti que les abonnés aient accepté ces messages sans ambiguïté!

Lors de la transmission de données de l'esclave à l'esclave, mise en œuvre par le maître, envoie un message à l'esclave (esclave1) à partir duquel les informations doivent être envoyées à l'autre esclave (esclave2), esclave1 envoie une réponse au maître tandis que l'esclave2 écoute cette réponse en prenant les données pour lui-même. Encore une fois, il n'y a aucune garantie d'une livraison de message non ambiguë de slave1 à slave2, cela doit être pris en compte!

Capacités d'interface nombre d'appareils théoriquement connectés environ 250, commandes / types de données jusqu'à 248 pour chaque appareil, la longueur des informations utiles dans le message pouvant aller jusqu'à 250 octets.

Parlez des pièges:

Tous les transferts de données sont conçus pour fonctionner à temps, c'est-à-dire certains retards entre les messages doivent être observés. Je recommande également que vous fassiez un délai fixe entre le message envoyé par le maître et la réponse de l'esclave afin que l'esclave puisse générer des données et les transmettre complètement au canal.

Le moment d'organiser les réponses de l'esclave est également important, il peut arriver que l'esclave soit occupé et ait plusieurs messages de données sur son canal à la fois, vous devez éviter les réponses aux messages obsolètes (car le leader ne les attend plus) en les ignorant, en exécutant les commandes uniquement des derniers messages et y répondre.

Séparément, je voudrais souligner la question de la synchronisation des appareils en fonction du temps - il convient de garder à l'esprit que la synchronisation temporelle de l'esclave lors de la réception d'un message nécessite de prendre en compte le délai de transmission des données vers le canal (à une vitesse de 9600, un message de 10 octets sera transmis pendant environ 11 ms) et le moment où l'interruption se déclenchera après recevoir des données du côté esclave, s'il n'y a pas d'interruption, il convient de considérer le temps de vérifier l'arrivée des données dans la mémoire tampon de l'appareil, etc.

Il convient également de noter que le renvoi d'une boucle de message ajoute également des nuances, je recommande d'utiliser l'envoi de messages sans répétitions pour la synchronisation de l'heure et la composition de messages avec un nouveau NS.

PSJ'ai des doutes que j'ai découvert quelque chose de nouveau ici, tout cela est dans une certaine mesure utilisé quelque part dans différentes interfaces! Avec la main légère de l'auteur de ce gribouillis et l'application de ce protocole dans mes développements, je souhaite donner le nom à ce protocole de transfert de données «SRDB2».

Ballade de transfert de données

More articles: