Protocole de communication série simple point à point

Question

J'ai besoin d'un simple protocole de communication entre deux appareils (un PC et un microcontrôleur). Le PC doit envoyer certaines commandes et les paramètres de la micro. Le micro doit transmettre un tableau d'octets (données de capteur).

Les données doivent être protégé du bruit (en plus de la vérification de la parité, je pense que j'ai besoin de quelques autres données méthode de correction).

Est-il une solution standard pour ce faire? (J'ai besoin seulement d'une idée, pas l'ensemble de la solution).

P. S. Tout conseil est le bienvenue. P. P. S Désolé pour les fautes de grammaire, j'espère que vous comprenez.

Edit 1. Je n'ai pas décidé s'il sera maître/esclave protocole ou des deux côtés peut initier la communication. Le PC doit savoir quand les micro ont fait un travail, et peut envoyer des données. Il peut interroger en permanence la micro si les données sont prêtes, ou le micro peut envoyer des données, quand un travail est terminé. Je ne sais pas ce qui est mieux et plus simple.

Edit 2. Matériel et de la couche physique du protocole. Depuis RS-232C de série de la norme utilisée dans le PC, je vais utiliser la communication asynchrone. Je vais utiliser seulement RxD, TxD et GND de signaux. Je ne peux pas utiliser d'autres fils, parce que le microcontrôleur autant que je sache, ne les supporte pas. BTW, je suis en utilisant le AVR ATmega128 puce.

Je vais donc utiliser fixe le débit en bauds, 8 bits de données, 2 bits de stop, sans parité (ou avec?).

Protocole de liaison de données. C'est ce que ma question préoccupe surtout des. Merci pour suggérer HDLC, PPP et Modbus protocoles. Je vais de recherche sur elle.

Answer 1

Je voudrais utiliser HDLC. J'ai eu de la chance avec elle dans le passé. Je le ferais pour un point à un autre de série suffit d'utiliser la Asynchrones cadrage et oublier toutes les autres choses qu'il serait sans doute exagéré.

En plus de l'utilisation de HDLC pour l'élaboration du paquet. J'ai formater mon paquet comme suit. C'est la façon dont les options sont passées à l'aide de 802.11

U8 cmd;
U8 len;
u8 payload[len];

La taille totale de chaque paquet de commande est len +2

Vous pouvez alors définir des commandes comme

#define TRIGGER_SENSOR 0x01
#define SENSOR_RESPONSE 0x02

L'autre avantage est que vous pouvez ajouter de nouvelles commandes et si vous concevez votre parser correctement à ignorer undefined commandes, puis vous aurez un peu de rétro-compatibilité.

Donc, en mettant tout cela ensemble, le paquet ne peut ressembler à celui-ci.

 // total packet length minus flags len+4
 U8 sflag;   //0x7e start of packet end of packet flag from HDLC
 U8 cmd;     //tells the other side what to do.
 U8 len;     // payload length
 U8 payload[len];  // could be zero len
 U16 crc;
 U8 eflag;   //end of frame flag

Le système va alors suivre la série de flux pour le drapeau 0x7e et quand il est là, vous vérifiez la longueur pour voir si c'est pklen >= 4 et pklen=len+4 et que le crc est valide. Remarque: ne pas compter sur crc pour les petits paquets, vous obtiendrez beaucoup de faux positifs également vérifier la longueur. Si la longueur ou la crc ne correspond pas tout simplement réinitialiser la longueur et de la crc et de commencer avec le décodage de la nouvelle image. Si c'est un match copiez ensuite le paquet à un nouveau tampon et de le passer à votre traitement de la commande de la fonction. Toujours réinitialisation de la longueur et de la crc lorsque le drapeau est reçu.

Pour votre commande de fonction de traitement d'attraper le cmd et len et ensuite utiliser un commutateur pour gérer chaque type de commande. J'ai aussi besoin que d'un certains événements envoyer une réponse, de sorte que le système se comporte comme un appel de procédure à distance est régie par les événements.

Ainsi, par exemple, le capteur de l'appareil peut avoir une minuterie ou de répondre à une commande pour prendre une lecture. Il serait alors le format d'un paquet et l'envoyer vers le PC et le PC ne répond qu'il a reçu le paquet. Si non, alors le capteur de l'appareil pourrait renvoyer à un délai d'attente.

Aussi, lorsque vous faites un transfert de réseau, vous devez concevoir comme une pile de réseau comme le modle OSI comme Foredecker points à ne pas oublier la couche physique des choses. Mon post avec le HDLC est la couche liaison de données et la RPC et de la gestion de commande est la Couche Application.

Answer 2

RS232 protocoles sont délicats. La suggestion d'utiliser HDLC, en est une bonne, mais ce n'est pas l'ensemble de la solution. Il y a d'autres choses que vous devez décider:

• Comment le taux de transmission entre les deux appareils est-elle déterminée? Autobuad? Prédéfinis, ou un ensemble d'expliquer?
• Allez-vous faire de contrôle de flux dans le logiciel ou le matériel ou les deux? Remarque, si vous utilisez le contrôle de flux matériel, alors vous devez vous assurer que les câbles sont correctement construit.
• En parlant de câbles, c'est une énorme douleur avec RS233. Selon le périphérique, vous devrez peut-être utiliser un câble direct, ou une croix sur le câble, ou une variante.
• À l'aide d'un logiciel de base de mécanisme de contrôle de flux peut être efficace, car elle permet le plus simple câble à utiliser - il suffit de trois filaire (TX, RX et commune).
• Avez-vous de choisir un 7 ou 8 bits de mot?
• HW de parité ou de logiciel de vérification d'erreur.

Je vous suggère d'aller avec 8 bits de données, pas de matériel de parité, 1 bit d'arrêt, et d'utiliser un logiciel basé sur le contrôle de flux. Vous devez utiliser autobaud si votre matériel le supporte. Si non, alors autobaud est diablement difficile à faire dans le logiciel.

Answer 3

Il y a quelques bonnes réponses ici, voici quelques indications utiles:

Même si vos paquets ne sont pas séparées, l'octet de synchronisation est un moyen essentiel de réduire le nombre d'endroits où vous devez vous essayez de construire un paquet. Vos appareils ont souvent à traiter avec un tas de données inutiles (j'.e à la fin d'un paquet lors d'un vol qu'ils se sont, ou le résultat d'un matériel de collision). Sans un octet de synchronisation, vous devez essayer de faire un paquet de chaque octet de vous recevoir. L'octet de synchronisation signifie que seuls les 1/255 octets de bruit aléatoire pourrait être le premier octet de votre paquet. Aussi FANTASTIQUE quand vous voulez sauter sur votre protocole.

Avoir une adresse sur vos paquets ou même juste un peu, en disant: maître / esclave ou le pc ou le dispositif est utile lorsque vous regardez les paquets via un snoop outil d'un type ou d'une autre. Vous pouvez le faire en ayant un autre octet de synchronisation pour le PC de l'APPAREIL. Aussi, cela signifie qu'un appareil ne répondra pas à son propre écho.

Vous voudrez peut-être regarder dans la correction des erreurs (comme de Hamming). Vous créez un package de 8 bits de données dans un 12 bits protégés octet. L'un de ces 12 bits peuvent être retournées en route et l'original de la 8 bits de récupération. Utile pour le stockage de données (sur Cd) ou lorsque l'appareil ne peut pas ré-envoyer facilement (liaisons par satellite, d'une manière rf).

Paquet de numéros de rendre la vie plus facile. Un paquet envoyé porte un numéro, les réponses portent le même numéro un d'un drapeau en disant "réponse". Cela signifie que les paquets qui ne sont jamais arrivés (synchronisation corrompu dire) sont facilement détectés par l'expéditeur et en mode full-duplex avec une liaison lente, deux commandes peuvent être envoyées avant la première réponse est reçue. Cela rend également l'analyse de protocole plus facile (Un tiers ne peut en comprendre les paquets ont été reçus avec aucune connaissance du protocole sous-jacent)

Avoir un seul maître est un jeu génial de simplification. Cela dit, dans un environnement de full-duplex, il n'importe pas beaucoup à tous. Il suffit de dire que vous devez toujours le faire, sauf si vous essayez d'économiser de l'énergie ou vous faites quelque chose de l'événement conduit à l'extrémité du périphérique (entrée de l'état a changé, échantillon de prêt).

Answer 4

Ma suggestion est modbus. C'est un protocole standard simple et efficace pour la communication avec les appareils, doté de capteurs et de paramètres (par exemple, un automate). Vous pouvez obtenir les spécifications sur http://www.modbus.org . Cela existe depuis 1979 et gagne en popularité, vous n'aurez aucun problème à trouver des exemples et des bibliothèques.

Answer 5

Voici un protocole de remplacement:

u8  Sync          // A constant value which always marks the start of a packet
u16 Length        // Number of bytes in payload
u8  Data[Length]  // The payload
u16 Crc           // CRC

Utilisez RS232/UART, comme le PC (port série) et le processeur (UART) peut déjà gérer qu'avec un minimum de tracas (juste besoin d'un MAX232 puce ou similaire pour faire le décalage de niveau).

Et à l'aide de RS232/UART, vous n'avez pas à vous inquiéter au sujet de maître/esclave, si elle n'est pas pertinente. Le contrôle de flux est disponible si nécessaire.

Suggéré logiciel PC: soit écrire votre propre, ou Docklight pour la simple surveillance et de contrôle (version d'évaluation est gratuite).

Pour plus de contrôle d'erreur, le plus simple est le contrôle de parité, ou si vous avez besoin de quelque chose de plus puissant, peut-être codage convolutif.

En tout cas, quoi que vous fassiez: keep it simple!

EDIT: en Utilisant RS232 avec un PC est encore plus facile qu'elle ne l'habitude d'être, comme vous pouvez maintenant obtenir USB / RS232/TTL convertisseurs. Une fin qui se passe dans votre PC de la prise USB, et apparaît comme un port série normal; l'autre est à 5 V ou 3,3 V signaux qui peuvent être connectés directement à votre processeur, avec pas de changement nécessaire.

Nous avons utilisé TTL-232R-3V3 de FDTI Puce, qui fonctionne parfaitement pour ce type d'application.