Série Simple point-to-point protocol de communication

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 le bruit protégé (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.

Modifier 1. Je n'ai pas décidé si ce 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.

Modifier 2. Matériel et la couche physique 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.

  • Similaire à: stackoverflow.com/questions/815029
  • "Les données doit être protégé du bruit". Ensuite, vous ne devriez pas être à l'aide de RS-232 pour commencer... c'est un amateur de la solution. Utilisation RS-422/RS-485.
  • avez-vous eu un coup d'oeil à ma réponse ci-dessous ? Je crois qu'il offre un cadre agréable et convivial solution
InformationsquelleAutor |
  1. 37

    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 Asynchrone 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 mettre le paquet serait la suivante.

     //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.

    Également lorsque vous effectuez 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 la couche physique des trucs. Mon post avec le HDLC est le couche liaison de données et la RPC et de la gestion de commande est la Couche Application.

    • +1 pour asynchrone de l'encadrement. Il a résolu ma question posée ici: stackoverflow.com/questions/815029/...
    • Rex, Pourquoi avez-vous mis eflag à la fin de la cadres? Sflag avec sflag échapper + longueur doit être suffisante pour lire les images.
    • Parce que si il n'utilise sflag, il doit attendre que l'image suivante. En utilisant eflag, il sait (quand il se eflag) qu'il a obtenu l'ensemble du cadre.
    • Comme Micheal points, c'est très important et agit comme déclencheur pour accepter ou de jeter le paquet que vous ne voulez pas compter sur la possible corruption de données pour déterminer la fin d'un paquet.
    InformationsquelleAutor Rex Logan
  2. 10

    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 la vitesse 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 doit assurez-vous que les câbles sont correctement construit.
    • 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).
    • Pensez-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.

    • +1 pour ne pas ignorer la couche physique
    • (1) je vais utiliser fixe la vitesse de transmission. (2) je ne suis pas sûr si j'ai besoin de contrôle de flux. De la charge du trafic n'est pas très élevé. (3) je n'ai pas de problèmes avec les câbles, je peux le faire moi-même. (4) je vais utiliser trois câble (TxD, Rxd et GND). (5) je prends une 8 bits du mot. (6) j'ai besoin d'un logiciel de vérification d'erreur car HW parité ne détecte que les 50% d'erreurs. Merci.
    InformationsquelleAutor Foredecker
  3. 8

    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 certain 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 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).

    InformationsquelleAutor
  4. 5

    Ma suggestion est modbus.
    C'est un moyen efficace et facile protocole standard pour la communication avec des appareils qui a des capteurs et des paramètres (par exemple un AUTOMATE).
    Vous pouvez obtenir le cahier des charges à http://www.modbus.org. Il a été autour depuis 1979 et est gagne en popularité, vous n'aurez aucun problème à trouver des exemples et des bibliothèques.

    • J'ai peur de ne pas avoir assez d'expérience pour le mettre en œuvre. J'utilise de l'assemblée et ne peut pas trouver toutes les bibliothèques. C'est un lourd protocole. Néanmoins, je vais garder cela à l'esprit. Merci.
    • Il y a beaucoup de documents à lire, mais en fait elle n'est pas beaucoup de code lors de la mise en œuvre. L'effort est probablement sur une paire avec la suggestion de HDLC.
    InformationsquelleAutor Martin Liesén
  5. 5

    J'ai lu cette question il y a quelques mois, ayant exactement le même problème, et n'a pas vraiment trouver quelque chose de suffisamment efficace pour un petit de 8 bits micro avec de petites quantités de RAM. Inspiré par can et LIN j'ai construit quelque chose pour faire le travail. Je l'ai appelé MIN (Microcontrôleur Réseau d'Interconnexion) et j'ai téléchargé sur GitHub ici:

    https://github.com/min-protocol/min

    Il existe deux implémentations de là: on en C embarqué, l'un en Python pour un PC. Plus un petit "hello world" programme de test où le PC envoie des commandes et le micrologiciel de l'éclairage LED. J'ai blogué à propos de l'obtention de cette place et en cours d'exécution sur une carte Arduino ici:

    https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/

    MIN est assez simple. Je fixe la couche 0 représentation (8 bits de données, 1 bit de stop, pas de parité), mais à gauche de la vitesse de transmission de l'ouvrir. Chaque trame commence avec trois 0xAA octets en binaire est 1010101010, une belle pulsetrain faire autobaud taux de détection si l'une des extrémités veut adapter dynamiquement à l'autre. Les cadres sont de 0 à 15 octets de charge utile, avec 16 bits de Fletcher somme de contrôle ainsi que d'un octet de contrôle et d'un 8-bits de l'identificateur (de dire à l'application de ce que les données de la charge utile contient).

    Le protocole utilise le personnage de farce, de sorte que 0xAA 0xAA 0xAA indique toujours de début de trame. Cela signifie que si un appareil qui vient de sortir de réinitialiser toujours se synchronise avec le début de la trame suivante (un des objectifs de conception pour MIN est de ne jamais laisser passer une incomplète ou incorrecte du cadre). Cela signifie aussi il n'y a pas besoin spécifiques inter-octets et inter-cadre des contraintes de temps. Tous les détails du protocole sont dans le dépôt GitHub wiki.

    Il y a de la place pour des améliorations futures avec MIN. J'ai laissé quelques crochets pour bloquer la transmission de message (4 bits de l'octet de contrôle sont réservés) et pour plus de négociation au niveau des capacités (identificateur 0xFF est réservé) donc il y a beaucoup de possibilités pour ajouter le support pour les fonctionnalités requises.

    InformationsquelleAutor
  6. 3

    Voici une autre protocole:

    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

    Utilisation 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: à l'Aide 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 de 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.

    • Ce n'est pas un protocole - son tout simplement une structure de données. Vous n'avez pas de décrire la façon dont le contrôle de flux de travaux, ou de mise en mémoire tampon, ou d'une erreur de détection ou de correction.
    • Le faible niveau de la partie, et le contrôle de flux, est gérée par le matériel. La qeustion de ne pas mentionner de mise en mémoire tampon, donc ni ai-je (astuce: sur le microcontrôleur, utiliser des mémoires tampon circulaire). J'ai donné quelques idées pour la détection d'erreurs & correction - mais le reste est à l'interlocuteur. Je ne veux pas en faire trop facile!
    • Je pense que j'ai besoin de garantir que la Synchronisation nombre ne se produiront pas dans la Longueur, des Données et des CRC. Dois-Je? Aussi j'ai besoin de contrôle de données est livré (par la transmission d'une réponse à des données). J'ai donc à vous inquiéter au sujet de maître/esclave. Par contrôle de flux vous dire le contrôle de flux matériel? Je pense que je ne vais pas l'utiliser. Je vais écrire un logiciel PC moi-même. J'ai choisi le système d'exploitation Linux pour le PC, donc Docklight n'est pas pertinent. Si je vais utiliser CRC, pourquoi je dois utiliser le contrôle de parité? Je n'ai pas entendu parler de codage convolutif, donc je vais le vérifier. Je vous remercie pour votre commentaire.
    • Si vous spécifiez un minimum de temps entre les messages, que c'est OK pour la synchronisation de l'octet à paraître également dans le message, que son but est de signaler le début d'un message après cette lacune; de cette manière, il permet d'éviter les erreurs dues au bruit entre les paquets. (2) je ne veux dire H/W contrôle de flux, mais si le bénéficiaire reconnaît chaque paquet, et peut mettre en mémoire tampon les données assez rapidement, alors il n'est pas nécessaire. (3) Si vous utilisez de la CRC, la parité n'est pas nécessaire, oui.
    • S'il vous plaît pas plus de main-conçu, non des protocoles standard.
    • si c'est une application personnalisée, simple, personnalisé, protocole de peut être la meilleure solution. Un protocole standard n'est pas forcément la réponse à toutes les situations.
    • Pour l'enregistrement, ce est un joli "standard" protocole, car il contient au minimum les éléments nécessaires et personnalisé les protocoles RS-232-être regardé comme cela pour les 30 dernières années. HDLC est complètement exagéré pour un simple point-à-point de connexion où ni nœud est un externe.

    InformationsquelleAutor Steve Melnikoff
  7. 2

    Ma seule suggestion est que si vous avez besoin de bruit résistant, vous pourriez vouloir utiliser full-duplex RS-422/485. Vous pouvez utiliser un IC similaire à cette sur le AVR côté, puis d'un RS-232->RS-422 convertisseur sur le côté de PC comme le 485PTBR ici. Si vous pouvez trouver ou faire un câble blindé (deux fils blindés à paire torsadée), alors vous aurez encore plus de protection. Et tout cela est invisible pour les micro et PC - pas de modification logicielle.

    Quoi que vous fassiez, assurez-vous que vous utilisez un full-duplex système et assurez-vous que la lecture/écriture des lignes sont revendiqués sur l'IC.

    InformationsquelleAutor Stephen Friederichs
  8. 2

    Vous pouvez avoir un coup d'oeil à Télémétrie et de son implémentation en python Pytelemetry

    Principales caractéristiques

    C'est un PubSub basée sur le protocole, mais à la différence de MQTT, il est un point-to-point protocol, pas de courtier.

    Que tout pubsub protocole, vous pouvez publier à partir d'une extrémité d'un topic et être informé sur l'autre extrémité sur le sujet.

    Sur le side, la publication d'une rubrique est aussi simple que :

    publish("someTopic","someMessage")

    Pour les nombres:

    publish_f32("foo",1.23e-4)
publish_u32("bar",56789)

    Cette manière d'envoyer des variables peut sembler limité, mais la prochaine étape à l'intention d'ajouter un sens supplémentaire à la rubrique de l'analyse en faisant des choses comme ça :

    //Add an indexing meaning to the topic
publish("foo:1",45) //foo with index = 1
publish("foo:2",56) //foo with index = 2

//Add a grouping meaning to the topic
publish("bar/foo",67) //foo is under group 'bar'

//Combine
publish("bar/foo:45",54)

    C'est bien si vous avez besoin d'envoyer des tableaux, des structures de données complexes, etc.

    Aussi, le PubSub modèle est idéal en raison de sa flexibilité. Vous pouvez construire maître/esclave des applications, des périphériques, etc.

    De la bibliothèque C Série Simple point-to-point protocol de communication

    La bibliothèque C est très simple à ajouter à tout nouvel appareil aussi longtemps que vous avez une bonne UART bibliothèque sur elle.

    Vous suffit d'instancier une structure de données appelée TM_transport (défini par Telemetry), et d'attribuer le 4 pointeurs de fonction read readable write writeable.

    //your device's uart library function signatures (usually you already have them)
int32_t read(void * buf, uint32_t sizeToRead);
int32_t readable();
int32_t write(void * buf, uint32_t sizeToWrite);
int32_t writeable();

    À l'utilisation de la Télémétrie, il vous suffit d'ajouter le code suivant

    //At the beginning of main function, this is the ONLY code you have to add to support a new device with telemetry
TM_transport transport;
transport.read = read;
transport.write = write;
transport.readable = readable;
transport.writeable = writeable;

//Init telemetry with the transport structure
init_telemetry(&transport);  

//and you're good to start publishing
publish_i32("foobar",...

    Bibliothèque Python Série Simple point-to-point protocol de communication

    Sur le bureau à côté, il y a le pytelemetry module qui implémente le protocole.

    Si vous connaissez python, le code suivant se connecte à un port série, publie une fois sur le sujet foo, imprime tous reçu des sujets pendant 3 secondes puis s'arrête.

    import runner
import pytelemetry.pytelemetry as tm
import pytelemetry.transports.serialtransport as transports
import time

transport = transports.SerialTransport()
telemetry = tm.pytelemetry(transport)
app = runner.Runner(transport,telemetry)

def printer(topic, data):
    print(topic," : ", data)

options = dict()
options['port'] = "COM20"
options['baudrate'] = 9600

app.connect(options)

telemetry.subscribe(None, printer)
telemetry.publish('bar',1354,'int32')
time.sleep(3)

app.terminate()

    Si vous ne savez pas python, vous pouvez utiliser l'interface de ligne de commande

    Pytelemetry CLI Série Simple point-to-point protocol de communication

    De la ligne de commande peut être démarré avec

    pytlm

    Alors vous pouvez connect, ls(liste) a reçu des sujets, print les données reçues sur un sujet, pub(publier) sur un sujet, ou d'ouvrir un plot sur un sujet pour afficher les données reçues en temps réel

    Série Simple point-to-point protocol de communication

    Série Simple point-to-point protocol de communication

    InformationsquelleAutor
  9. 1

    Concernant la parité des contrôles (comme il est venu plusieurs fois ici):

    Ils sont la plupart du temps inutile. Si vous êtes inquiet que d'un seul bit peut être changé dans l'erreur, il est alors très probable qu'une deuxième bit peut également changer et vous obtiendrez un faux positif du contrôle de parité.

    Utiliser quelque chose de léger, comme CRC16 avec une table de recherche - il peut être calculé que chaque octet est reçu et est fondamentalement juste un XOR. Steve Melnikoff la suggestion est idéal pour les petits micros.

    Je vous suggère aussi de la transmission de données lisibles par l'homme, plutôt que binaire brut (si la performance n'est pas votre première priorité). Il permettra de faciliter le débogage et les fichiers journaux beaucoup plus agréable.

    InformationsquelleAutor
  10. 0

    Vous ne spécifiez pas exactement comment le microcontrôleur se comporte, mais tout transmis à partir de la micro-être une réponse directe à une commande à partir du PC? Si faire alors il semble que vous pouvez utiliser une configuration maître/esclave protocole de quelque sorte (ce sera généralement la solution la plus simple). Si les deux côtés peuvent initier la communication, vous avez besoin d'un plus générale de données de protocole de couche de liaison. HDLC est un protocole classique pour cela. Bien que le protocole complet est probablement un overkill pour vos besoins, vous pourriez, par exemple, à moins d'utiliser le même format de trame. Vous pouvez également jeter un oeil à PPP pour voir si il y a quelque chose d'utile parties.

    • >> trouverez toutes les informations transmises à partir de la micro-être une réponse directe à une commande à partir du PC? Une n'ont pas encore décidé. Je pense que oui, si c'est plus simple. Un PC doit savoir, lorsque les données sont prêtes. Il peut envoyer en permanence de commande pour micro, pour lui demander si elle prêt pour envoi. Mais peut-être qu'il sera mieux si un micro envoyer le signal à un PC, lorsque les données sont prêtes.
    InformationsquelleAutor hlovdal
  11. 0

    peut-être cette question peut être complètement stupide, mais quelqu'un a pris en compte l'utilisation de l'un des X/Y/Z MODEM protocoles?

    Le principal avantage de l'utilisation de l'un des protocoles mentionnés ci-dessus est la grande disponibilité de prêt-à-utiliser des mises en œuvre dans divers environnements de programmation.

    InformationsquelleAutor
  12. -2

    SLIP et UDP. Sérieusement.

    Tous les PC et les appareils similaires parler.

    Il y a un bon livre et des exemples de TCP Maigre

    Jeremy Bentham a sournoisement eu un PIC de faire travailler TCP/IP. Un RÉGULATEUR de tension est aussi bon comme un PIC à droite ?

    Je le recommande UDP au lieu de cela, c'est vachement facile.

    • UDP n'est pas fiable du tout.
    • Si nous parlions de l'informatique embarquée (aka RPi, Odroids,...), j'aurais hocha la tête. Nous parlons ici d'un micro-contrôleur de parler à un (et un seul) sur PC. TCP et UDP (en-Tête 16 octets) sont à l'aide de la propriété intellectuelle (en-Tête 16 octets) qui est à l'aide de MAC (en-Tête de 14 octets) qui est de type Ethernet (Cadrage de 8 octets + CRC 4 octets). Mettant cela sur un µC est énorme: pour envoyer un octet, il vous en coûtera 58 octets de surcharge.
    InformationsquelleAutor