Communication entre plusieurs microcontrôleurs

20

Je voudrais commencer à implémenter un système composé de N microcontrôleurs (N> = 2 MCU), mais je voudrais connaître les possibilités de les laisser communiquer entre eux.

Idéalement, les microcontrôleurs (N-1) sont placés à l'intérieur de la maison en tant que clients, tandis que le dernier (le "serveur") est connecté à un PC via USB. Le problème que j'ai en ce moment est de savoir comment connecter ces (N-1) microcontrôleurs au "serveur". Les MCU clients effectuent des tâches très simples, donc ce n'est peut-être pas une bonne solution d'utiliser des ARM pour effectuer des tâches aussi simples simplement parce qu'ils fournissent CAN / PHY-MAC .

La communication ne se fera pas plus d'une fois toutes les quelques minutes pour la plupart des appareils et à la demande pour d'autres. La vitesse n'est pas très critique (le message est court): 1 Mbit / s je pense que c'est beaucoup trop pour mes besoins.

Les MCU que j'envisage d'utiliser sont les suivants.

  • Atmel AVR Tiny / Mega
  • TI MSP430
  • ARM Cortex M3 / M4
  • (Peut-être Atmel AVR UC3 - 32 bits)

J'aimerais éviter les PIC si possible (choix personnel), tout simplement parce qu'il y a moins de possibilités de les programmer (tous ceux-ci ont des outils plus ou moins open source ainsi que certains outils officiels).

Je sais que certains ARM offrent une fonctionnalité CAN et je ne suis pas sûr des autres.

En ce moment, j'ai trouvé ces possibilités:

  1. GPIO simple pour envoyer des données (disons> 16 bits à HIGH pour indiquer le début du message,> 16 bits à LOW pour indiquer la fin du message). Cependant, il doit être à une fréquence standard << (fréquence_client, fréquence_server) pour pouvoir détecter tous les bits. Besoin d'un seul câble par MCU client.
  2. RS-232 : Je pense que c'est de loin le protocole de communication le plus utilisé, mais je ne sais pas à quel point il évolue. J'envisage jusqu'à 64 MCU clients en ce moment (probablement plus tard)
  3. USB: AFAIK, c'est principalement comme RS-232, mais je ne pense pas qu'il évolue très bien dans ce cas (bien que l'USB supporte de nombreux appareils - 255 si je me souviens bien - cela peut être trop compliqué pour cette application)
  4. RJ45 / Ethernet: c'est ce que j'aimerais vraiment utiliser, car il permet une transmission sur de longues distances sans problème (au moins avec un câble blindé> Cat 6 ). Le problème est le coût (PHY, MAC, transformateur, ...). Je ne sais pas si vous pouvez vraiment bien le souder à la maison. De cette façon, je n'aurais pas besoin d'un MCU client
  5. Sans fil / ZigBee : les modules sont très chers, mais c'est peut-être le chemin à parcourir pour éviter les "spaghettis" derrière le bureau
  6. Modules / émetteurs-récepteurs RF: je parle de ceux dans la bande 300 MHz - 1 GHz, ils devraient donc être difficiles à souder à la maison. Les modules sont tous intégrés, mais ils sont tout aussi chers que le ZigBee (au moins les modules RF de Mouser, de Sparkfun semblent être moins chers).
  7. POUVEZ? Il semble être très robuste. Même si je ne prévois pas de l'utiliser dans des applications automobiles, cela peut être une bonne alternative.
  8. I²C / SPI / UART ? Encore une fois - mieux vaut éviter les "spaghettis" avec les câbles si possible
  9. Les API ne sont pas vraiment une option. Les performances se dégradent assez rapidement à mesure que la longueur augmente et dépend de la charge capacitive du réseau électrique. Je pense que le prix est à peu près identique à Ethernet.

De plus, quel protocole serait "meilleur" en cas de transmissions simultanées (supposons le cas rare où au même instant deux appareils commencent à transmettre: quel protocole fournit le meilleur "système de gestion des conflits" / "système de gestion des collisions"?

Pour résumer : j'aimerais savoir quelle peut être la meilleure solution pour un système client distribué qui fait une communication de données très légère, compte tenu de la flexibilité (nombre maximum d'appareils, système de gestion des conflits / collisions, ...), du prix , facile à faire à la maison (soudure), ... Je voudrais éviter de dépenser 20 $ pour le module de communication, mais en même temps, avoir 30 fils derrière le bureau serait nul.

La solution que j'imagine actuellement serait de faire une communication de base entre des MCU proches par GPIO ou RS-232 ( pas cher !) Et d'utiliser Ethernet / ZigBee / Wi-Fi sur un MCU par "zone" pour communiquer avec le serveur ( cher , mais c'est toujours beaucoup moins cher qu'un module Ethernet par MCU client).

Au lieu de câbles, il peut également être possible d'utiliser des fibres optiques / fibres optiques. Bien que des conversions supplémentaires soient nécessaires, et je ne sais pas si ce serait la meilleure solution dans ce cas. J'aimerais entendre des détails supplémentaires à leur sujet.

user51166
la source
2
Il existe des PIC avec fonctionnalité CAN et des outils officiels gratuits pour les programmer avec de la documentation.
AndrejaKo
@AndrejaKo PIC n'a pas vraiment de compilateur open source comme les AVR ou au moins les MSP430. Il est vrai qu'ils fournissent souvent plus de fonctionnalités que les MCU que j'ai énumérés ci-dessus pour le même prix. Je n'aime pas vraiment ces grandes différences entre les familles 12/16/18/24/32 et que certaines d'entre elles n'ont pas du tout de compilateur gratuit (je pense que c'est PIC18).
user51166
2
En fait, PIC18 a un compilateur gratuit et les autres aussi. Le principal avantage des autres familles est qu'elles travaillent avec GCC. Dans le camp open source, il y a le compilateur Small device C qui devrait prendre en charge les périphériques PIC 16 et PIC 18.
AndrejaKo
2
Si vous n'êtes pas encore familiarisé avec l'un des uC que vous avez mentionnés, sachez qu'il est beaucoup plus difficile de commencer avec ARM qu'avec, par exemple, les PIC ou l'AVR, surtout si vous souhaitez opter pour l'open source. Avec ARM, les fournisseurs ne conçoivent pas le noyau et ne fournissent généralement pas non plus d'IDE, ce qui peut rendre le tout un peu plus complexe. C'est bien d'avoir par exemple Microchip fournir et supporter tout dans le cas des PIC.
Oli Glaser
@OliGlaser Eh bien ... même s'il est vrai que les outils open source pour ARM peuvent être un peu difficiles à utiliser (j'ai essayé une carte de découverte STM32 et cela n'a pas très bien fonctionné), de nombreux fournisseurs proposent un IDE qui est - avec ses avantages et inconvénients - basés sur éclipse et limités gratuitement: LPCXpresso (NXP) et Code Composer Studio (TI) par exemple (pas open-source, mais ils sont pris en charge au moins). Les AVR sont en revanche plutôt bien pris en charge du côté open source, ainsi que dans ATMEL STUDIO 6. Aucune expérience avec PIC que ce soit. Codé uniquement AVR (assembleur) et ARM (C, sur le NDS).
user51166

Réponses:

22

CAN semble le plus applicable dans ce cas. Les distances à l'intérieur d'une maison peuvent être gérées par CAN à 500 kbits / s, ce qui ressemble à beaucoup de bande passante pour vos besoins. Le dernier nœud peut être une interface USB vers CAN standard. Cela permet aux logiciels de l'ordinateur d'envoyer des messages CAN et de voir tous les messages sur le bus. Le reste est un logiciel si vous voulez le présenter au monde extérieur comme un serveur TCP ou quelque chose.

CAN est le seul moyen de communication que vous avez mentionné qui est en fait un bus, sauf pour rouler le vôtre avec des lignes d'E / S. Tous les autres sont point à point, y compris Ethernet. Ethernet peut être conçu pour ressembler logiquement à un bus avec des commutateurs, mais les connexions individuelles sont toujours point à point et obtenir la topologie de bus logique sera coûteux. La surcharge du micrologiciel sur chaque processeur est également considérablement plus élevée que CAN.

La bonne partie de CAN est que les couches de protocole les plus basses sont gérées dans le matériel. Par exemple, plusieurs nœuds peuvent essayer de transmettre en même temps, mais le matériel se charge de détecter et de gérer les collisions. Le matériel prend en charge l'envoi et la réception de paquets entiers, y compris la génération et la validation de la somme de contrôle CRC.

Vos raisons pour éviter les PIC n'ont aucun sens. Il existe de nombreux modèles de programmeurs pour créer le vôtre. L'un est mon LProg , avec le schéma disponible en bas de cette page. Cependant, la construction de la vôtre ne sera pas rentable à moins que vous ne valorisiez votre temps à quelques sous / heure. C'est aussi bien plus qu'un simple programmeur. Vous aurez besoin de quelque chose qui facilite le débogage. Les Microchip PicKit 2 ou 3 sont des programmeurs et débogueurs à très faible coût. Bien que je n'aie aucune expérience personnelle avec eux, j'entends parler des autres qui les utilisent régulièrement.

Ajoutée:

Je vois quelques recommandations pour RS-485, mais ce n'est pas une bonne idée par rapport à CAN. RS-485 est une norme uniquement électrique. Il s'agit d'un bus différentiel, il permet donc plusieurs nœuds et a une bonne immunité au bruit. Cependant, CAN a tout cela aussi, et bien plus encore. CAN est également généralement implémenté en tant que bus différentiel. Certains soutiennent que RS-485 est simple à interfacer électriquement. C'est vrai, mais CAN aussi. Quoi qu'il en soit, une seule puce le fait. Dans le cas de CAN, le MCP2551 est un bon exemple.

CAN et RS-485 ont donc à peu près les mêmes avantages électriquement. Le gros avantage de CAN est au-dessus de cette couche. Avec RS-485, il n'y a rien au-dessus de cette couche. Tu es seul. Il est possible de concevoir un protocole qui traite de l'arbitrage des bus, de la vérification des paquets, des délais d'attente, des tentatives, etc., mais pour bien faire les choses, c'est beaucoup plus délicat que la plupart des gens ne le pensent.

Le protocole CAN définit les paquets, les sommes de contrôle, la gestion des collisions, les tentatives, etc. Non seulement il est déjà là et pensé et testé, mais le très gros avantage est qu'il est implémenté directement en silicium sur de nombreux microcontrôleurs. Le micrologiciel s'interface avec le périphérique CAN au niveau de l'envoi et de la réception des paquets. Pour l'envoi, le matériel effectue la détection de collision, l'interruption, la nouvelle tentative et la génération de la somme de contrôle CRC. Pour la réception, il effectue la détection des paquets, l'ajustement de l'horloge et la validation de la somme de contrôle CRC. Oui, le périphérique CAN nécessitera plus de micrologiciel pour piloter qu'un UART, comme cela est souvent utilisé avec RS-485, mais cela prend beaucoup moins de code dans l'ensemble, car le silicium gère une grande partie des détails du protocole de bas niveau.

En bref, le RS-485 est d'une époque révolue et n'a plus de sens pour les nouveaux systèmes aujourd'hui. Le principal problème semble être que les personnes qui ont utilisé RS-485 dans le passé s'y sont accrochées et pensent que CAN est "compliqué" d'une manière ou d'une autre. Les faibles niveaux de CAN sont compliqués, tout comme toute mise en œuvre RS-485 compétente. Notez que plusieurs protocoles bien connus basés sur RS-485 ont été remplacés par des versions plus récentes basées sur CAN. NMEA2000 est un exemple d'une telle norme CAN plus récente. Il existe une autre norme automobile J-J1708 (basée sur RS-485) qui est à peu près obsolète maintenant avec les OBD-II et J-1939 basés sur CAN.

Olin Lathrop
la source
la construction de ma propre carte personnalisée est utile lors de l'intégration du MCU avec le matériel qui l'entoure. À des fins de développement, je conviens qu'un kit de développement est une meilleure solution. Ma raison pour éviter les PIC est leur manque de compilateurs open source (il y en a gratuitement, mais pas pour PIC18 par exemple) plutôt qu'un manque de schémas accessibles au public, bien qu'ils fournissent des fonctionnalités supplémentaires que vous ne trouverez peut-être pas dans d'autres MCU (Ethernet, POUVEZ, ...). Et I2C est un bus AFAIK.
user51166
@ user51166 - Il existe des compilateurs PIC18 gratuits fournis par microchip. Consultez la page produit des compilateurs MPLAB XC . Il répertorie également les compilateurs pour les uC 16 bits et 32 ​​bits.
PetPaulsen
@ user51166 Il y a aussi le compilateur C18 gratuit .
AndrejaKo
@PetPaulsen Strange. Je suis presque sûr d'avoir vu il y a un mois une page répertoriant tous les compilateurs téléchargeables gratuitement (PIC16 / 24/32), à l'exception du PIC18 qui n'était pas dû à un problème de licence. Cela a probablement été résolu avec la transition MPLAB C Compiler -> MPLAB XC Compiler bien que je ne sois pas sûr. De plus, ils offrent "seulement" une édition gratuite qui n'optimise pas votre code, pas un compilateur entièrement open source. C'est toujours mieux que rien;)
user51166
@user: Je pense que tous les compilateurs Microchip ont des versions gratuites qui ne diffèrent que des versions complètes en ce que certaines optimisations sont désactivées. L'assembleur, le bibliothécaire, l'éditeur de liens et le simulateur sont tous inclus dans le package MPLAB gratuit. Il n'y a vraiment aucun problème ici.
Olin Lathrop
6

Je recommanderais un contrôleur avec CAN car cette fonctionnalité est destinée exactement à la mise en réseau du contrôleur.

RS232 peut être implémenté facilement mais cela deviendra très difficile si vous essayez d'implémenter la communication sur plus de 2 nœuds (car il n'est pas construit à cet effet).

Ethernet peut également être une option intéressante car vous avez mentionné certaines interconnexions hôtes et clients, ce qui est naturel pour la mise en œuvre Ethernet.

JeeShen Lee
la source
Quels sont les avantages de CAN over Ethernet par exemple? Moins cher probablement, mais à part ça, quoi d'autre?
user51166
@ user51166 - CAN n'est pas seulement moins cher mais beaucoup moins cher. C'est non seulement plus facile, mais beaucoup plus facile.
Rocketmagnet
@Rocketmagnet: veuillez expliquer un peu plus. Dans la plupart des cas, vous avez quand même besoin d'un circuit intégré intégré (bien que les PIC et ARM et autres? Intègrent souvent la fonction CAN, ils sont un peu chers). D'un point de vue matériel, je ne vois pas comment cela peut être beaucoup moins cher puisque les circuits intégrés peuvent être trouvés pour 0,5-1,0 $ la pièce. Je suppose que vous voulez dire plus facile d'un point de vue logiciel, non? CAN a une distance maximale de ~ 500 mètres, ce qui est sûrement suffisant dans mon cas, mais - juste pour information - y aurait-il des alternatives similaires pour des distances plus longues (fibre optique peut-être)?
user51166
4

RS-485 utilisant plusieurs fils pourrait bien fonctionner ici, s'il y a une possibilité de câbler la même ligne à tous les appareils.

Si, par exemple, il est utilisé avec un câble réseau traditionnel de catégorie 5e, vous pouvez avoir deux paires pour travailler pour la transmission de données dans les deux sens (en utilisant un module duplex intégral), avoir une paire ou peut-être même un seul fil comme masse commune et le reste à négocier quel appareil va transmettre à quel moment. C'est un peu plus compliqué que RS-232, mais les modules sont moins chers que CAN et Ethernet et la limite de câble est de 1200 m. L'inconvénient est que vous devrez créer votre propre protocole de résolution des conflits. Peut-être que l'appareil qui veut transmettre vérifie un fil dédié et regarde s'il est haut. Si ce n'est pas le cas, amenez-le haut et commencez à communiquer et s'il l'est, attendez une période de temps aléatoire. Je ne sais toujours pas dans quelle mesure cela fonctionnerait sur de longues distances.

AndrejaKo
la source
Ne vous inquiétez pas des trop longues distances, je ne prévois pas de dépasser les 100m pour le moment.
user51166
Pourquoi BTW n'accepte aujourd'hui pas stackexchange @ <username>? Chaque fois que j'en mets un, il est complètement supprimé (pas seulement le symbole @) ...
user51166
@ user51166 - Le créateur de la réponse est automatiquement averti, donc le "\ @ - noise" est automatiquement supprimé. (Mon \ @ user51166 n'a pas été supprimé, car vous n'êtes pas le créateur de cette réponse)
PetPaulsen
La chose intéressante est que je n'ai reçu aucune notification pour aucun des commentaires ici.
AndrejaKo
4

Je choisirais un bus RS-485 fonctionnant avec les données d' encodage de Manchester .

RS-485 car:

  • Est bon marché
  • Est facile à mettre en œuvre
  • Est utilise la puissance lo
  • Permet de longues distances (jusqu'à 1200 mètres)
  • Débits de données élevés (jusqu'à 10 Mbps)
  • Immunité élevée aux interférences
  • Il existe des émetteurs-récepteurs qui permettent jusqu'à 256 appareils sur le même bus
  • Faible nombre de pièces

Encodage Manchester car:

  • Est facile à mettre en œuvre
  • Est auto-synchronisable

Pour l'intégrité des données, le message peut inclure une longueur et un champ CRC.

Exemple de fonction CRC:

unsigned char crc_calc(unsigned char buffer[], unsigned short size)
{
  unsigned long i;
  unsigned char crc;

  crc = CRC_INIT;

  for (i=0;i<size * 8;i++)
  {
    crc = (crc << 1) | (crc >> (7));

    if (buffer[i/8] & (0x80 >> (i%8)))
    {
      crc ^= CRC_POLY;
    }
  }

  return crc;
}

CRC_INITet CRC_POLYsont des valeurs arbitraires utilisées pour calculer le CRC.

Exemple de message avec longueur et champs CRC:

Exemple de message

Bruno Ferreira
la source
Une suggestion pour de si bons émetteurs-récepteurs, peut-être bon marché?
user51166
De plus, comme @AndrejaKo l'a suggéré, le RS-485 ne semble pas offrir de protocole de résolution des conflits.
user51166
Le choix des émetteurs-récepteurs dépend de la tension que vous avez l'intention d'utiliser. La résolution des conflits doit être effectuée dans un logiciel avec vérification CRC, surveillance de ligne ou les deux.
Bruno Ferreira
Si vous avez un maître, vous pouvez également implémenter une sorte d'adressage ou une transmission au tour par tour.
Bruno Ferreira
Pas vraiment un maître. Juste le "serveur" qui agit comme une interface avec le PC via USB. Les clients doivent cependant lui envoyer des messages automatiquement ...
user51166
3

Permettez-moi de comparer votre choix préféré, Ethernet, avec mon choix préféré, CAN.

Composants requis:

  • Ethernet: connecteur RJ45, magnétique, puce Phy (sauf si intégré dans MCU). Besoin également de commutateurs et d'un câble entre le commutateur et chaque nœud. Chaque PCB a besoin de quelques condensateurs et résistances de terminaison, peut-être aussi des ferrites. Nécessite une bonne conception de PCB.
  • CAN: puce émetteur-récepteur (bon marché), n'importe quel connecteur, un câble bon marché peut sauter d'un nœud à l'autre dans une boucle autour du site. Besoin d'un seul condensateur pour l'émetteur-récepteur et d'une résistance de terminaison à chaque extrémité du bus.

Vous parlez de microcontrôleurs à 1 $. Le coût du bus est bien plus important que celui du MCU. Vous devrez additionner le coût total de chaque solution pour savoir laquelle est réellement la moins chère. Additionnez le coût du MCU, des connecteurs, des émetteurs-récepteurs, des composants passifs, des PCB, des câbles, etc.

Rocketmagnet
la source
0

LPC11C24 de NXP a également un émetteur-récepteur CAN intégré, et CANOpen pris en charge dans la ROM (sans ronger votre mémoire de données 32 K). La carte LPCXpresso 11c24 coûte 20 EUR (a fourni de l'espace pour le connecteur DB9), donc vous n'avez vraiment qu'à ajouter des fils :-)

Drazen Cika
la source
0

Republier d'une autre question similaire. Communication simple à faible coût entre deux microcontrôleurs

TLDR : Pas particulièrement bon marché mais fiable dans certains cas d'utilisation.

En regardant hors des sentiers battus, il pourrait y avoir d'autres solutions ici, comme la puce suivante que j'ai rencontrée récemment. Bien sûr, tout dépend de ce que vous voulez faire. Quelque chose comme UART me vient à l'esprit si vous avez les deux MCU sur la même carte ou même si vous prévoyez de les protéger ESD manuellement s'ils sont séparés.

Solution maître et périphérique pour les applications IO-Link

L6360   Master
L6362A  Device

entrez la description de l'image ici

Quand envisageriez-vous une solution comme celle-ci:

  1. Les puces frontalières sont entièrement protégées, ce qui serait important si vous avez chaque MCU sur une carte distincte et traitant des broches exposées, par exemple une borne à vis.
    • Polarité inversée
    • Surcharge avec fonction de coupure
    • Surchauffe
    • Sous-tension et surtension
    • Fil ouvert GND et VCC
  2. Interopérabilité. Si quelqu'un d'autre va concevoir l'autre côté, tout ce qu'il doit savoir, c'est de canaliser les données via IO-Link.
  3. Régulateur intégré Vcc(in) 7~30v, Vdd(out) 3.3/5v

Cela me semblait intéressant, alors j'ai pensé que je le mettrais là-bas.

Mehrad
la source
-3

Cela dépend de l'échelle de votre application et de vos microcontrôleurs. Vous avez mentionné Atmel tiny / mega, ils sont assez petits. Dans leur cas, I2C / SPI / UART ont l'avantage d'être implémentés dans le matériel et donc faciles à utiliser.

vsz
la source
3
OK, mais comment cela résout-il le problème du PO? IIC est un bus, mais vraiment pas adapté du tout pour de longues distances comme à travers une maison. Il s'agit d'une impédance asymétrique et relativement élevée. SPI est un bus, mais contrôlé par un seul maître avec une ligne de sélection esclave distincte pour chaque appareil. Vous pouvez implémenter chaque ligne en tant que paire différentielle avec les pilotes de ligne et le récepteur, mais vous avez toujours le problème de sélection maître à esclave point à point. L'UART est strictement point à point. Il n'est pas clair comment vous comptez les utiliser dans la situation du PO.
Olin Lathrop