Communication entre plusieurs microcontrôleurs

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.

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.

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.

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.

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:

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.

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 :-)

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

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.

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.