Communication entre Arduino

Bonjour,

J'ai un projet pour lequel j'ai besoin de faire communiquer 7 Arduinos (Atmega 328) entre eux.

J'utilise déjà le réseau I2C a d'autre fin.

J'ai besoin d’échanger :
-1 Mot Esclave => Maitre
-4 Mots Maitre => Esclave

J'ai vue qu'il est possible d'utiliser le Réseau SPI, mai je comprend pas trop comment ça fonctionne.

Je sais qu'il faut 1 maitre et 6 esclaves dans mon cas que chaque esclave aura une broche des election associé et que la communication n'est possible que si cette broche est LOW...


C'est après que je ne sais pas trop comment faire.

Si quelqu'un pouvais prendre un moment pour me détailler le fonctionnement ou si vous avez des exemples...

En vous remerciant

Bonsoir,

à voir... mes recherches m'ont mené vers 2 documents :
- le "daisy chain" : il s'agit d'utiliser le protocole SPI mais le câblage est légèrement différent de celui que l'on trouve habituellement.
https://en.wikipedia.org/wiki/Serial..._configuration
https://learn.sparkfun.com/tutorials...erface-spi/all
attention : je ne sais pas si les Arduino supportent ce protocole.

- détourner le port série :
là on utilise plus les voies sda et scl maix tx et rx :
https://www.wintergroundfairlands.co...nnections.html
attention : le montage me semble quand même un peu foireux. Il faut bien veiller à ce que les masses et l'alimentation soient communes à tous les Arduino !

Salut,

Citation:

---

Envoyé par Doubytchou

J'ai un projet pour lequel j'ai besoin de faire communiquer 7 Arduinos (Atmega 328) entre eux.

---

Sur quelle distance ?
Parce que les bus SPI ou I2C, ou encore l'UART, ne sont absolument pas des bus de terrain, autrement dit ce sont des bus locaux qui sont sensés rester sur la carte électronique qui les gèrent. Ils n'ont aucun mécanisme d'immunité aux bruits ou à l'exposition aux perturbations environnantes. Un Bus SPI ou I2C dans un câble de 5m peut fonctionner parfaitement chez toi sur ton bureau et ne plus fonctionner dans ta cuisine.

Citation:

---

Envoyé par Doubytchou

Je sais qu'il faut 1 maitre et 6 esclaves dans mon cas que chaque esclave aura une broche des election associé et que la communication n'est possible que si cette broche est LOW...

---

Ce que tu décris c'est précisément le bus SPI.

Les Atmega ont 4 broches MOSI (Master Out, Slave In), MISO, (Master In, Slave Out), CLK (l'horloge qui synchronise les données de MOSI et MISO) et CS (Chip Seclect). La sortie CLK du maître va dans toutes les entrées CLK des esclaves. La sortie MOSI du maître va sur toutes les entrée MOSI des esclaves et toutes les sorties MISO des esclaves vont tous sur l'entrée MISO du maître. On pourrait penser qu'il y a un gros court circuit avec toutes ces sorties des esclaves qui vont vers l'entrée du maître mais non car c'est le maître qui décide avec qui il cause en activant la broche CS de l'esclave concerné. Les autres esclaves sont en quelques sortes déconnectés du bus même si ils y sont physiquement reliés (ils sont en haute impédance)

Pièce jointe 497243

Il faut que le maître ait 7 broches dédiées aux CS pour choisir à tour de rôle les 7 esclaves avec qui discuter. Le I2C a une adresse par esclave alors que le SPI active une broche de l'esclave concerné. Le bus SPI est plus encombrant en câblage mais bien plus rapide que I2C. Avec le SPI tu auras le protocole a construire, il n'y a pas de mécanisme comme ACK d'I2C par exemple, ni de Read/Write.


ps 1 : suivant le constructeur ce n'est pas MOSI/MISO mais SDI/SDO ça dépend des fabricants de micro.

ps 2 : si les 7 Arduino sont distant et pire encore installés en milieu pollué (industrie), mieux vaut implémenter un MODBUS/JBUS avec des liaisons RS485 sur l'UART. Ca c'est du vrai bus de terrain.

Plus rapide que moi Auteur :)

Salut à tous ;)

La bibliothèque SPI de l'EDI Arduino standard est prévue pour un Arduino fonctionnant en "maître".
Mais les AVR peuvent fonctionner en "esclave", il faudra alors taper dans les registres et les interruptions dans le programme "esclave". On trouve des exemples sur Internet (taper "two arduino spi communication" dans google).

Bonsoir à tous

Je trouve Vincent encore optimiste quand à la longueur possible des bus SPI, I2C et UART (en 5V). Ils ne sont prévus que pour rester dans un même appareil avec quelques dizaines de centimètres de longueur au maximum. Le SPI plus rapide est plus limité que l'I2C (règle de base de l'électronique, à technologie identique, plus c'est rapide, plus c'est court).

Pour communiquer entre plusieurs Arduino étant chacun un appareil distinct et avec un minimum d'investissement, il y a le RS485 ne nécessitant qu'un adaptateur de niveau à quelques cents en composant ou quelques € en modules prêt à l'emploi. Là les distances admissible sont beaucoup plus longues car cela travail sur une paire différentielle (comme l'Ethernet mais qui lui a 2 ou 4 paires). Attention de base les masses seront mises en commun donc uniquement possible avec des alimentations flottantes. Sinon il faut des adaptateurs de tension plus élaborés avec une séparation galvanique.

Bonne suite

Delias

Citation:

---

Envoyé par Vincent PETIT

Plus rapide que moi Auteur :)

---

j'ai évoqué une mise en chaîne des Arduino et dans ce cas tu n'utilises qu'une voie CS quel que soit le nombre d'esclaves.


Pour les adaptateurs de tensions évoqués par Delias, il y a les MAX232 (pour le RS232) et les MAX485 (pour le RS485). Sur le net on trouve beaucoup d'expériences qui mettent en jeu plusieurs Arduino et des modules équipés de MAX485.

Citation:

---

Envoyé par Auteur

Bonsoir,

à voir... mes recherches m'ont mené vers 2 documents :
- le "daisy chain" : il s'agit d'utiliser le protocole SPI mais le câblage est légèrement différent de celui que l'on trouve habituellement.
https://en.wikipedia.org/wiki/Serial..._configuration
https://learn.sparkfun.com/tutorials...erface-spi/all
attention : je ne sais pas si les Arduino supportent ce protocole.

- détourner le port série :
là on utilise plus les voies sda et scl maix tx et rx :
https://www.wintergroundfairlands.co...nnections.html
attention : le montage me semble quand même un peu foireux. Il faut bien veiller à ce que les masses et l'alimentation soient communes à tous les Arduino !

---

Bonjour Merci pour votre réponse
J'avais vu ces documents...
Pour être plus explicite sur le projet, je vais faire 6 régulateurs de températures indépendants (Chaque PCB aura sa sonde, son Atmega, son afficheur, ses dispositifs de pilotage de puissance) l’idée est de chainer une communication pour réaliser un système central de "supervision", pour géré depuis un seul point les consignes des régulateurs ainsi que voir les températures.
Du coup pour les distance je pense être entre 10 et 15 cm max

Ce qui me gène avec le chainage est le fait que si 1 des "Arduino" s’arrête, la communication générale s’arrête.

Après pour les structure de branchement j'ai réussis à trouver pas mal d'infos par contre c'est au niveau programmation du SPI que je pêche un peu.
Comment envoyer et récupérer une info vers l'esclave et inversement...

Les régulateurs seront localisés au même endroit j'avais l’idée de développer mes PCB pour avoir d'un coté des duponts mals de l'autre des duponts femelles ce qui me permet de les brancher les un aux autres très facilement en réduisant au max les distances;

Citation:

---

Envoyé par Vincent PETIT

Salut,

Sur quelle distance ?
Parce que les bus SPI ou I2C, ou encore l'UART, ne sont absolument pas des bus de terrain, autrement dit ce sont des bus locaux qui sont sensés rester sur la carte électronique qui les gèrent. Ils n'ont aucun mécanisme d'immunité aux bruits ou à l'exposition aux perturbations environnantes. Un Bus SPI ou I2C dans un câble de 5m peut fonctionner parfaitement chez toi sur ton bureau et ne plus fonctionner dans ta cuisine.


Ce que tu décris c'est précisément le bus SPI.

Les Atmega ont 4 broches MOSI (Master Out, Slave In), MISO, (Master In, Slave Out), CLK (l'horloge qui synchronise les données de MOSI et MISO) et CS (Chip Seclect). La sortie CLK du maître va dans toutes les entrées CLK des esclaves. La sortie MOSI du maître va sur toutes les entrée MOSI des esclaves et toutes les sorties MISO des esclaves vont tous sur l'entrée MISO du maître. On pourrait penser qu'il y a un gros court circuit avec toutes ces sorties des esclaves qui vont vers l'entrée du maître mais non car c'est le maître qui décide avec qui il cause en activant la broche CS de l'esclave concerné. Les autres esclaves sont en quelques sortes déconnectés du bus même si ils y sont physiquement reliés (ils sont en haute impédance)

Pièce jointe 497243

Il faut que le maître ait 7 broches dédiées aux CS pour choisir à tour de rôle les 7 esclaves avec qui discuter. Le I2C a une adresse par esclave alors que le SPI active une broche de l'esclave concerné. Le bus SPI est plus encombrant en câblage mais bien plus rapide que I2C. Avec le SPI tu auras le protocole a construire, il n'y a pas de mécanisme comme ACK d'I2C par exemple, ni de Read/Write.


ps 1 : suivant le constructeur ce n'est pas MOSI/MISO mais SDI/SDO ça dépend des fabricants de micro.

ps 2 : si les 7 Arduino sont distant et pire encore installés en milieu pollué (industrie), mieux vaut implémenter un MODBUS/JBUS avec des liaisons RS485 sur l'UART. Ça c'est du vrai bus de terrain.

---

Bonjour Merci pour votre réponse,

Comme un peu mieux décrit dans ma précédente réponse la structure sera des modules branchés les uns aux autres sans longueur de fil j'estime en distance max entre le maitre et le dernier esclave 15cm max. du coup je pense que la distance ne devrais pas être un problème.

Mon problème est que chaque régulateur possédé son écran en I2C (Type OLED 0.96') du coup je ne peu chainer tout mes régulateurs car il y aurai des conflits d'adresses avec les 6 écrans des différents régulateurs. De plus si je ne me trompe pas avec l'ATMEGA328 je n'ai qu'un seul I2C

Pour la partie Hardware je n'ai pas de gros problème c'est assez explicite, par contre je me pose énormément de questions quant à la programmation, pour laquelle je n'ai pas vraiment trouver de réponse pour la communication inter Arduino en lecture/écriture.

J'ai l'habitude de programmer des automate industrielle mais la tout est plus ou moins prémâché...

En vous remerciant

Bonjour Doubytchou

Citation:

---

Envoyé par Doubytchou

J'utilise déjà le réseau I2C a d'autre fin.

---

Pourquoi ne pas continuer avec i2C?, pour moi c'est la solution idéale.
Il "suffit" de transformer un Arduino en esclave i2C. je peut te fournir des exemples pour le maître et les esclaves.

Cordialement
jpbbricole

Citation:

---

Envoyé par jpbbricole

Bonjour Doubytchou

Pourquoi ne pas continuer avec i2C?, pour moi c'est la solution idéale.
Il "suffit" de transformer un Arduino en esclave i2C. je peut te fournir des exemples pour le maître et les esclaves.

Cordialement
jpbbricole

---

Bonjour,

Ben je me suis longuement posé la question...
Mon problème ici, chaque µc est couplé avec un écran Oled0.96' en I2C donc si j’agrandis mon réseau pour y inclure tous mes modules je vais me retrouver avec 1 µC maitre I2C, 6 µC Esclave I2C et 6 écrans esclave I2C. Si je ne me trompe pas les écrans peuvent avoir max 2 adresses différentes.

De plus est ce qu'un µC esclave I2C peut écrire sur un écran? Pour moi ça n'est pas possible car il ne peut pas être maitre pour son écran et esclave pour le µC Maitre...

Ou alors si pour vous c'est plus simple de communiquer entre les µC en I2C plutôt qu'en SPI, je peu peut être inverser et mettre mes ecrans en SPI comme ca chaque µC communique avec son ecran en SPI et le reseau general est en I2C...


Merci

Bonjour Doubytchou

Citation:

---

Envoyé par Doubytchou

Si je ne me trompe pas les écrans peuvent avoir max 2 adresses différentes.

---

Pour résoudre le problème des adresses i2C identiques, il y a ce genre de modules à base de TCA9448.

Citation:

---

Envoyé par Doubytchou

De plus est ce qu'un µC esclave I2C peut écrire sur un écran? Pour moi ça n'est pas possible car il ne peut pas être maitre pour son écran et esclave pour le µC Maitre...

---

En conjonction avec le mudule ci-dessus, le master commande tout les affichages, en allant questionner les slaves, quelle valeur(s) il ont à afficher et sur quel écran. Le câblage est très simple, un simple bus 4 fils (GND VCC SDA SCL, je polarise le bus i2C avec 1.5 kOhms) pour alimenter les slaves ainsi que leur affichage. Je te prépare une paire de programme (master et slave) pour illustrer ceci.

Cordialement
jpbbricole

Bonsoir Doubytchou

Comme promis, voici quels programme j'utilise pour faire communiquer des Arduino en i2C.

Côté Module Master (MS) il faut:
Installer le programme ARDDEV_BusI2C_ms_Master.ino dans le MM (chez moi, un Mega)
Connecter SDA et SCL sur le bus i2C. J'ai 2 résistances de polarisation du bus de 1.5k.
Connecter un bouton poussoir contre GND sur la pin 7 du MS (INPUT_PULLUP) donc actif à 0 ou GND.
Ce bouton sert à passer d'un MS à l'autre et ce pour sélectionner les données de quel MS on affiche.
Dans la démo, il y a un affichage LCD i2C 20x4 à l'adresse 0x27 (à adapter)

Côté Module Slave (MS)
Installer le programme ARDDEV_BusI2C_ms_Slave.ino dans le MS (chez moi, un Nano)
Connecter SDA (A4) et SCL (A5) sur le bus i2C.
Pour la démo, un potentiomètre sur A0, un bouton poussoir sur 10, une LED sur 11.
Une fois le programme téléchargé, attribuer une adresse au MS par l'envoi, via le moniteur de l'IDE Arduino, de la commande:
(Les commandes ne sont pas sensibles majuscule ou minuscule.)
i2Cadresse=41
Cette adresse doit se trouver, dans le MM, dans le tableau modSlaveAddress[MSnombre].
L'adresse du MS est sauvegardée, de façon permanente, en EEPROM.
Après un reset du MS, pour prendre en compte la modification, la LED d'activité(LED_BUILTIN) doit flasher périodiquement, preuve que le MM interroge ce MS.

Essayer les commandes
Led=1
LED=0
qui doivent allumer et éteindre la LED (11)

Côté MM, avec le cas de l'adresse du MS = 41, pseudo du MS = MSA1 (tableau modSlavePseudo[]) on peut envoyer les mêmes commandes ainsi:
MSA1>Led=1
MSA1>LED=0

Toutes les commandes d'un MS (tableau cmdFunctionSyntax[]) peuvent être "envoyées" pour exécution, depuis le MM.

Cordialement
jpbbricole

Bonjour,

Merci beaucoup pour cet exemple.
Je vais mettre en place cette exemple pour essayé de comprendre les différentes interactions.

Merci pour la suggestion du TCA9548A, je vais essayé de comprendre le fonctionnement car cela peut être très intéressant a connaitre.

Bonjour

Citation:

---

Envoyé par Doubytchou

Ce qui me gène avec le chainage est le fait que si 1 des "Arduino" s’arrête, la communication générale s’arrête.

---

S'arrête pour quelle raison?
Car l'I2C et le SPI sont aussi tributaire du bon fonctionnement de tout les périphériques branchés dessus. Enfin c'est un poil plus subtile.

- Panne d'alimentation d'un des Arduino; quelque soit le bus I2C, SPI ou SPI chaîné le bus sera interrompu. (Car l'AVR sans alimentation tire les lignes du bus à 0.) Cela est solutionnable uniquement avec les bus type RS485. Les drivers de bus comme le MAX485 étant prévus pour ne pas déranger le bus en cas d'absence d'alimentation.
- Retrait de l'un des modules; les deux autres bus ne sont pas prévu en Hot Plug. Il faut obligatoirement tout éteindre avant l'ajout ou le retrait d'un des modules. Et dans ce cas le chaîné peut aussi se reconfigurer.
- Plantage du programme Arduino, il y a le Watchdog la contre, mais même sans le chaînage est géré maternellement dans l'AVR, la partie SPI aura de bonne chance de continuer à fonctionner.

Je ne vois pas trop l’intérêt des 7 Arduino côte à côte, un seul (au pire un Mega) n'est pas capable de gérer 6 régulations de température? En avoir plusieurs c'est judicieux que quand ils sont à des emplacements différents.

Bonne suite

Delias

Citation:

---

Envoyé par Delias

Je ne vois pas trop l’intérêt des 7 Arduino côte à côte, un seul (au pire un Mega) n'est pas capable de gérer 6 régulations de température? En avoir plusieurs c'est judicieux que quand ils sont à des emplacements différents.

---

Je pense que les Arduino sont simplement présents pour l'affichage local de la température.

Citation:

---

Envoyé par Delias

Bonjour

Je ne vois pas trop l’intérêt des 7 Arduino côte à côte, un seul (au pire un Mega) n'est pas capable de gérer 6 régulations de température? En avoir plusieurs c'est judicieux que quand ils sont à des emplacements différents.

Bonne suite

Delias

---

Bonjour,

Merci pour ces éclaircissement,
7 Arduino qui seront en réalité des cartes électronique que j'ai développer avec une puce atmega 328.
Ce projet et pour un ami qui possède une brasserie et qui a un besoin de régulation des brassins.
Je suis d’accord avec vous même un nano pourrait faire ces 6 régulations.
J'ai pris le partie de mettre un µc par cuve:
- pour pouvoir utiliser un afficheur par cuve
- ça me permet aussi d'avoir une régulation autonome par cuve avec écran et bouton de réglage
- de cette manière il est bien plus intuitif pour l'utilisateur de faire ses réglages cuve a cuve (dans le cas sans système central qui est le cas aujourd'hui)
- pour la continuité de service, comme ça si un atmega, un régulateur ou autre venais à être défaillant cela n'impacterai qu'une seule cuve et pas les 6 ce qui au cout d'un brassin n'est pas négligeable.

Bonjour Doubytchou

Pour de grandes distances en bus i2C, il y a le 82B715PN: I2C Bus Extender
Il permet d'aller jusqu'à 25 mètres (j'en ai même vu qui disaient 40m.)

Cordialement
jpbbricole