Protocole général pour le transfert de données d'un système à un autre?

18

Quel est le protocole général pour envoyer des informations d'un système à un autre? Par exemple, disons que nous avons des informations collectées à partir du microcontrôleur sur une période de temps que nous voulons envoyer à un autre microcontrôleur. J'ai entendu parler des interfaces SPI et I2C, mais je ne sais pas quand vous utilisez une méthode plutôt qu'une autre et comment vous l'implémentez. Existe-t-il d'autres méthodes que SPI et I2C qui sont courantes? Le processus de mise en œuvre est-il similaire pour différents microcontrôleurs? Est-ce essentiellement une analyse des octets de données que je fais sur le microcontrôleur récepteur?

i2c spi data

— O_O
source

4

Quelle est la chose concrète que vous voulez faire?

— starblue

Il suffit de penser à comment obtenir différents éléments d'un système pour se transmettre des données dans une petite boîte, de sorte que la distance peut être supposée très courte. La raison d'avoir différentes pièces dans une boîte est de simplifier les fonctions afin que chaque pièce ait sa propre fonction (j'espère que cela a du sens ..)

— O_O

2

ce n'est pas ce que les gens appellent normalement un système. Ce sont plutôt ce que je définirais comme des sous-systèmes. Ils font partie de ce que vous pourriez considérer comme un seul système accomplissant un seul ensemble de tâches. C'est de la sémantique, mais je pense que beaucoup de vos réponses sont très générales parce qu'elles n'ont pas une idée parfaite de ce que vous recherchez dans la question.

— Kortuk

1

dans le sens de ce qu'a dit Kortuk, cela aide à définir le problème. Une question importante à vous poser est de savoir si vous pourriez avoir l'intention de remplacer des sous-systèmes individuels par différentes implémentations de la même fonction, ou s'il s'agit d'une conception unique en l'état. Si vous utilisez un vrai bus et exposez les détails d'implémentation des sous-systèmes à votre processeur, un changement de sous-système nécessite un changement de / w pour votre contrôleur, alors que si vous utilisez une interface de communication, peu importe la façon dont vous implémentez un (remplacement ) sous-système, tant qu'il répond au même protocole de message.

— JustJeff

Il n'est pas plus simple de fractionner les fonctionnalités sur plusieurs appareils sans autre raison que de séparer les tâches. Les communications et la synchronisation sont plus complexes que d'avoir deux processus dans le même micro. Maintenant, si ces processus ont des profils de latence particulièrement incompatibles (l'un doit se mettre à jour rapidement tandis que l'autre peut prendre un certain temps pour terminer un morceau), alors il PEUT y avoir une raison valable de les diviser. Même alors, la solution la plus courante consiste à utiliser des interruptions ou à trouver un moyen de décomposer la tâche plus longue. Avec ce que vous avez décrit, je penche pour penser que vous devriez repenser cela.

— darron

10

SPI et I2C sont assez similaires, en ce sens qu'ils sont vraiment plus utilisés pour connecter des périphériques à un contrôleur ou à un processeur, que pour transférer réellement des données entre les systèmes. L'USB est une autre interface que les gens semblent vouloir traiter comme un système de communication, qui est en fait un bus de connexion périphérique.

La communication entre les systèmes n'est pas exactement comme connecter un périphérique à un bus. La connexion par bus permet au processeur de frapper directement sur les registres d'un appareil, tandis qu'une interface de communication vous permet d'envoyer / recevoir des flux de données. Un périphérique connecté sur un bus a généralement besoin d'un pilote de périphérique, alors qu'avec les communications, peu importe ce qui est connecté à l'autre extrémité, en ce qui concerne l'ordinateur hôte.

Bien sûr, cela devient tout le temps une frontière plus floue. Des choses comme PCI et ISA sont incontestablement des bus; I2C, SPI, USB sont sans doute des bus; tandis que RS232, RS485 et Ethernet sont définitivement des interfaces de communication. Mais il y a aussi des choses comme le bus CAN et le 1553, qui concernent certainement le déplacement de données, mais d'une manière très impliquée.

— JustJeff
source

CANbus est très impliqué, et Ethernet ne l'est pas? CAN est très simple à utiliser pour les simples messages de va-et-vient. Ce sont des puces dédiées et la plupart des familles prennent en charge en interne leurs micro contrôleurs.

— Kortuk

@Kortuk - dans la mesure où quelque chose comme 232 a une sorte de symétrie d'égal à égal, alors que 1553 ou CAN imposent une relation maître / esclave, oui. Je ne crois pas avoir dit qu'Ethernet est simple, juste qu'il n'impose pas de distinction contrôleur de bus / périphérique de bus aux points d'extrémité.

— JustJeff

aussi, divulgation complète - mon opinion de CAN provient entièrement d'une exposition tangentielle; il s'agit d'un périphérique optionnel inutilisé sur plusieurs systèmes sur lesquels j'ai travaillé, mais après des centaines de passages dans la documentation, vous absorbez un peu les options inutilisées juste par osmose. Je travaille donc dans l'hypothèse que CAN est une architecture de type contrôleur / appareil contrôlé.

— JustJeff

Je pense que le bus a différentes significations dans différents contextes. D'un niveau schématique, toute interface avec plusieurs signaux peut être considérée comme un bus. Lorsque vous vous déplacez vers des niveaux supérieurs avec plus d'abstraction, le bus change de sens. Légèrement plus élevé, le bus signifie généralement qu'il y a ou peut y avoir plusieurs périphériques impliqués. Le multipoint RS485 est définitivement un bus, par exemple. Beaucoup plus haut, du point de vue d'un périphérique Linux, RS485 redevient une interface de communication et est rétrogradé en tant que bus ... jusqu'à ce que vous ajoutiez votre propre couche de protocole par-dessus pour la reconvertir en bus. A chaque niveau, il y a des significations différentes.

— darron

11

Il n'y a pas qu'une seule façon d'envoyer des données, il existe de nombreuses façons différentes de communiquer en fonction de la distance, du débit, de l'environnement, de l'application ...

La couche la plus basse est la couche physique , qui déplace réellement les bits.

SPI et I²C sont pour de courtes distances à l'intérieur d'un appareil, où il n'y a pas beaucoup de bruit qui pourrait perturber la transmission.
Pour une communication pas trop rapide sur des distances allant jusqu'à quelques dizaines de mètres, la communication série via RS-232 est un bon choix.
S'il y a plus de bruit ou si des signaux différentiels plus longs sont utilisés, par exemple dans RS-485. Pour une transmission de données plus rapide, il y a Ethernet, qui devient de plus en plus populaire.
Ensuite, il existe également diverses normes sans fil.

En plus de la couche physique, il y a plus de couches organisant la façon dont les données sont envoyées, pour détecter et corriger les erreurs de transmission, de routage dans un réseau et bien d'autres choses. Par exemple, le protocole Internet est une pile plutôt complexe de plusieurs couches, généralement au-dessus du protocole Ethernet.

— starblue
source

7

Un simple UART série peut être utilisé (une ligne Tx et une ligne Rx sans horloge discrète) et peut être facilement adapté pour traverser différents potentiels (même les circuits primaires et secondaires) avec des optoisolateurs ou des isolateurs magnétiques .

En ce qui concerne les protocoles, tout ce qui a des octets de commande définis et une sorte de schéma de somme de contrôle fonctionnera bien. Il n'y a vraiment pas de protocole standard couvrant tous les types de communications. I2C a des normes de signalisation (définissant l'adressage, les arrêts, les démarrages, etc.) mais le protocole de ce qui est réellement communiqué est uniquement au développeur.

PMBus , par exemple, est un protocole de communication d'alimentation qui utilise I2C comme support physique.

— Adam Lawrence
source

6

Il n'y a vraiment pas de protocole "général", ce que vous finissez par utiliser dépend fortement de l'application. Afin que nous puissions vous donner une meilleure réponse, nous devons mieux comprendre vos besoins. Vous mentionnez que vous aimeriez que des microcontrôleurs distincts se parlent en tant que sous-systèmes.

Quelques questions sur cette application:

Y aura-t-il plus de 2 microcontrôleurs dans ce projet?
Quelles sont vos exigences de vitesse et de débit? À quelle vitesse les informations doivent-elles arriver et à quelle fréquence envoyez-vous / recevez-vous des données?

Si vous avez répondu NON à la question 1:

S'il n'y a que 2 microcontrôleurs dans ce projet, vous pouvez certainement utiliser UART entre eux. S'ils ont tous les deux besoin d'initier la communication, utilisez le contrôle de flux, sinon cela devrait être trivial d'envoyer des données dans une direction. Pour la plupart, il devrait être "assez rapide" étant donné que vous sélectionnez l'un des débits en bauds les plus élevés. I2C et SPI ne conviennent généralement qu'à l'architecture maître / esclave.

Si vous avez répondu OUI (plus de 2 contrôleurs) à la question 1:

S'il y a plus de 2 micro-contrôleurs dans votre projet, lequel initie les communications? Sera-ce un seul contrôleur maître (c'est-à-dire une architecture maître-esclave)? Ou l'un des sous-systèmes pourrait-il parler à tout moment?
Y a-t-il un besoin pour l'un des sous-systèmes de se parler? par exemple: pour les appareils A, B et C: A peut envoyer à B et C, et B peut envoyer à la fois A et C, etc.

Alors maintenant, vous avez besoin de quelque chose de plus évolutif où vous pouvez déposer des périphériques adressables sur un bus commun. La réponse à ces questions de suivi vous aidera à choisir entre I2C et SPI (maître-esclave) ou quelque chose comme CAN (multi-maître).

Votre microcontrôleur a très probablement un périphérique UART, les autres (en particulier CAN) ne peuvent être disponibles que sur des puces plus haut de gamme. Dans les deux cas, il devrait y avoir beaucoup de documentation sur la façon d'utiliser ces périphériques pour déplacer des octets.

— Jon L
source

5

Comme @Jon l'a noté, un problème dans la sélection d'une interface de communication est de savoir si une entité sera toujours responsable de l'initiation des communications, ou si plusieurs entités peuvent être ainsi responsables. Une question connexe est de savoir si une entité sera toujours prête à recevoir des communications non sollicitées. SPI est fréquemment utilisé dans les applications où un côté sera toujours prêt à recevoir la communication. Quelque chose comme un registre à décalage 74HC595, par exemple, n'est jamais "occupé". Alors que SPI est bon pour la communication entre un microcontrôleur et le matériel que le micro est censé contrôler, il n'est vraiment pas bon pour la communication entre deux microcontrôleurs. Lorsque deux processeurs avec du matériel I2C l'utilisent pour communiquer, le logiciel peut prendre autant de temps qu'il le souhaite (dans des contraintes très généreuses) pour gérer ce qui se passe, sans provoquer de perte de données. Si un processeur devait prendre 100 microsecondes pour traiter chaque octet entrant, cela limiterait considérablement le débit, mais l'expéditeur ralentirait suffisamment pour que le récepteur continue. Le seul moyen qui peut généralement se produire avec SPI est de disposer d'un fil séparé pour la prise de contact.

I2C est vraiment un merveilleux protocole. Les plus grandes limitations qui l'empêchent d'être le protocole le plus parfait imaginable sont

Sa vitesse est quelque peu limitée; Le SPI peut aller beaucoup plus vite, et même les UART peuvent parfois aller un peu plus vite
(2) Bien qu'il soit très pratique que l'I2C n'ait besoin que de deux fils, les deux fils doivent être capables de communiquer avec un collecteur ouvert bidirectionnel. Cela rend difficile l'envoi d'I2C via des répéteurs.

Personnellement, j'aimerais que les fournisseurs de contrôleurs prennent en charge une variante à trois fils de SPI qui comprenait une négociation. Cependant, je ne connais aucun contrôleur qui le fasse.

— supercat
source

Drôle, vous devez le mentionner ... Je dois transformer une interface SPI en une interface non bidirectionnelle de type I2C (le premier octet est une adresse) pour permettre à beaucoup plus d'appareils de participer sur le bus que je n'ai de sélections de puces pour . Cela fonctionne si vos périphériques esclaves sont tous des FPGA. :) Moi aussi, j'aurais souhaité qu'il y ait quelque chose entre ces deux principales normes synchrones.

— darron

Oh, je suppose que je devrais préciser que les sorties activées sur les esclaves ne sont pas confirmées jusqu'à ce que leur octet d'adresse soit reçu et qu'elles restent actives jusqu'à ce que la sélection d'une seule puce soit désactivée ... donc c'est évidemment légèrement différent du SPI normal + niveau élevé protocole. Cependant, il est totalement compatible avec le SPI standard du point de vue de l'appareil maître. (comme un microprocesseur)

— darron

@darron: Cool. Je me demande ce qui devrait se passer pour que l'industrie commence à utiliser un bus de communication à trois fils standard ouvert où les fils sont activement conduits haut et bas? Je suppose qu'il y a un léger conflit entre éviter les tractions passives et permettre à n'importe quel appareil de signaler une interruption, bien que cela puisse être résolu en ajoutant une broche d'interruption qui pourrait être câblée au maître ou non à la convenance des esclaves (ma mise en œuvre actuelle de le protocole n'a qu'un seul esclave, il peut donc utiliser le fil de retour de données pour signaler de manière asynchrone quand il veut être réparé).

— supercat

@darron: Pour éviter d'avoir à utiliser une broche de sélection de puce, le maître signale le début de la commande en envoyant deux fronts montants sur le câble de données alors que l'horloge est basse; les esclaves peuvent indiquer si leur dernier octet de données était valide en émettant une valeur d'état lorsque l'horloge et les données sont toutes deux faibles (inactives); sinon, ils indiquent qu'ils veulent de l'attention lorsque l'horloge est basse et que les données sont hautes. Si je concevais un matériel maître pour ce protocole, j'ajouterais la possibilité d'envoyer 8 impulsions d'horloge où l'horloge miroir du fil de données, et dans le matériel esclave, incluent un compte asynchrone du nombre de

— fronts

@darron: ... un octet de données. S'il était supérieur ou égal à cinq, l'octet serait ignoré (l'esclave supposerait que le maître souhaitait recevoir un octet de données, mais n'avait rien à dire en réalité). Ce ne serait pas aussi important, cependant, que d'avoir l'esclave signaler le dernier octet lorsque l'horloge était faible (ce qui, si le périphérique esclave était un processeur, permettrait au maître de savoir que l'esclave n'était pas prêt et avait raté la dernière 'opportunité de transaction'.

— supercat

3

Dans aucun ordre particulier, les instances de couche physique les plus populaires pour 2 CPU dans la même boîte semblent être:

SPI en guirlande (tel qu'utilisé par JTAG)
sélectionner SPI fil par esclave
«RS-232 de niveau TTL» ou «communication série asynchrone démarrage-arrêt» (connexion directe de la broche UART TX d'un processeur à la broche UART RX d'un autre processeur)
I2C
Données 8 bits + stroboscope (comme le port parallèle du port imprimante IEEE 1284)
mémoire partagée (un seul processeur pilote le bus d'adresse / de données / de contrôle à la fois)

Ces instances de couche physique (ainsi que d'autres instances de couche physique pour 2 CPU dans des boîtiers séparés) fournissent généralement un flux d'octets au logiciel qui implémente les niveaux supérieurs du système de communication.

Les programmeurs intelligents écrivent le logiciel de telle manière que lorsque le gars du matériel décide de supprimer une instance de couche physique et de la remplacer par une instance de couche physique complètement différente, ils n'ont qu'à réécrire quelques fonctions pour alimenter leur flux de sortie d'octets au matériel et relire un flux d'octets à partir du matériel, et tous les éléments de protocole de niveau supérieur continuent de fonctionner sans changement.

Le protocole pour envoyer des informations d'un CPU à un autre CPU implique presque toujours d'interpréter le flux d'octets comme une série de paquets:

préambule
entête
(éventuellement échappé) données sérialisées
bande annonce

Certaines personnes semblent apprécier de créer des protocoles entièrement nouveaux, personnalisés et incompatibles en mélangeant et en faisant correspondre (2) l'un des nombreux types de structure d'en-tête avec (3a) l'un des nombreux types de données de sérialisation avec (3b) l'un des nombreux types de échapper à ces données sérialisées avec (4) l'un des nombreux types de bandes-annonces.

Certains des protocoles les plus simples pour encapsuler des données dans un paquet incluent:

Les protocoles légèrement plus compliqués pour encapsuler les données dans un paquet incluent:

Il existe une longue liste de protocoles sur

Vous aimerez peut-être lire "Protocol Design Folklore" de Radia Perlman qui décrit comment la conception du protocole peut mal tourner.

— davidcary
source

3

Pas de protocole «général» unique. Le choix peut (par exemple) dépendre de:

distance
débit requis
disponibilité de périphériques spéciaux
niveau de bruit
besoin d'isolement optique
criticité (taux de défaillance tolérable)
puissance CPU disponible aux deux extrémités
broches d'E / S disponibles aux deux extrémités

Dans de nombreux cas, vous devez dissocier la couche physique (niveaux de signal) de la couche de liaison de données (+/- la façon dont les données sont codées) (vérifiez le modèle OSI, couches inférieures de 2,4). Les couches phyiscales possibles sont par exemple:

simple 5V ou 3,3V ou même 1,8V TTL
l'un des éléments ci-dessus mais à collecteur ouvert au lieu de push-pull
signalisation de tension d'amor équilibrée (souvent utilisée avec les FPGA)
volatilité higer équilibrée (RS485, RS432)
tension plus élevée asymétrique (RS232)
équilibré couplé au trafic (diverses versions Ethernet, audio PDIF)
optique (Ethernet optique, toslink)

Vous pouvez utiliser une ligne pour transporter des données et des informations d'horloge, ou la diviser en plusieurs lignes. Ce dernier était populaire, mais de nos jours la plupart des nouveaux protocoles / rapides ont tendance à utiliser une seule ligne (ou une paire de lignes agissant comme une seule).

Il existe de nombreuses façons de coder les données et l'horloge sur une ligne. RS232 utilise traditionnellement NRZ, il y a l'encodage Machester, et les différents formats utilisés sur les disques durs avec des noms curieux ligne 2.7 RLL.

Pour résumer: il existe des millions de façons de communiquer entre les systèmes. Et je n'ai même pas mentionné de connecteurs ou d'aspects de niveau supérieur comme la détection et la récupération d'erreurs, l'encodage, la compression et le chiffrement des données ...

— Wouter van Ooijen
source