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?
18
Réponses:
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.
la source
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.
la source
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.
la source
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:
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:
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.
la source
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
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.
la source
Dans aucun ordre particulier, les instances de couche physique les plus populaires pour 2 CPU dans la même boîte semblent être:
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:
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.
la source
Pas de protocole «général» unique. Le choix peut (par exemple) dépendre de:
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:
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 ...
la source