Communication de valeurs entre arduino

International Français
1

Bonjour,

Je dois envoyer des valeurs de type "int" entre 3 arduinos (1 arduino Mega "maitre - emetteur/receveur" + 1 arduino nano "esclave - emetteur/receveur" + 1 arduino nano "escalve - receveur").

Ma question est la suivante :

  • Quel est le meilleur moyen de les faire communiquer entre eux (Rx/Tx, I2C, etc ...) ?
    mon projet a besoin d'impulsions précises, c'est à dire que lorsqu'un arduino esclave envoi sa donnée, cela déclenche instantanément et sans risque d'erreur, ni d'omission, une réponse de l'arduino maitre.

Si vous pouvez m'aider, pouvez vous me donner un exemple de code maitre/esclave avec la solution qui pour vous est la plus adéquate. L'esclave aurait un compteur comme celui ci-dessous par exemple, et devrait en envoyer sa valeur au maitre. Le maitre, lui, pourrait modifier la valeur maximale de la boucle de comptage.

int compteur=0;
int valeurMax=999;

void setup(){
}

void loop(){
compteur ++;
if(compteur>valeurMax){
compteur=0;
}
}

Merci d'avance pour votre aide.

2

C'est pas assez précis tout ça.
Maître pour faire quoi ? pour prendre la parole ?
Quels sont les types de relations possibles entre le maître les les esclaves ?
Qui parle à qui ?

3

C'est pas assez précis tout ça.
Maître pour faire quoi ? pour prendre la parole ?
Comme je l'ai dit pour recevoir des valeurs provenant des arduinos nano et pour en envoyer à l'un des 2.

Quels sont les types de relations possibles entre le maître les les esclaves ?
Juste une communication de valeurs. L'exemple du compteur est très ressemblant à mon projet. L'arduino Mega doit recevoir les valeurs de comptage de l'arduino nano et doit en même temps être capable d'en modifier les bornes.

Qui parle à qui ?
1 arduino mega : réception de valeurs des 2 nano et envoi à 1 nano
1 arduino nano : émission/reception vers l'arduino mega
1 arduino nano : émission vers arduino mega

4

Tu a décris les messages, mais pas comment le "dialogue" s'organise.
Tu dis "maître pour recevoir...", ça ne suffit pas pour définir un comportement de maître. Y'a un nano qui reçoit aussi, et tu le déclares esclave.
Un maître donne des ordres. Les esclaves obéissent.
C'est ce rapport "social" qu'il faut décrire. Comment se passent les conversations.

5

Merci de ton intérêt Biggil.

Je ne m'y connais pas assez pour te répondre Biggil. J'ai décrit le fonctionnement comme je me l'imagine mais je suis novice et beaucoup de mes termes ou de mes formulations doivent être erronés.
Le principal est que je puisse utiliser un système de communication simple et efficace pour échanger des valeurs de type INT entre 3 arduinos.
Lequel me recommanderiez vous ?

6

Comment marche ton système ?
Y-a-t-il un cycle ? C-à-d des échanges qui se reproduisent régulièrement dans le temps ?

Ou bien n'importe qui peut prendre la parole ( = émettre une trame vers un récepteur ) n'importe quand ?

Ou bien seulement les nano (les esclaves ?) peuvent "prendre la parole" ?

Quand le maître parle, est-ce pour 1 nano en particulier ou pour les 2 ?

Ne me dis pas que tu ne t'y connais pas assez, c'est pas une question de connaissances mais de logique, de raisonnement. Ce système, avec 3 arduinos, qui l'a concçu ? Si c'est toi tu devrais savoir comment tu veux l'organiser, non ? Je parle d'organisation, toi tu as décris la scène (des acteurs, des messages) mais tu n'as pas parlé du scénario. Y'en a forcément un.

7

Communiquer des valeurs binaires n'est pas simple. Le problème est que le message est composé de deux octets et que le récepteur n'est en aucun cas certain que le message est complet. Il y a aussi un risque de récupérer deux octets provenant de messages différents (le dernier octet d'un message et le premier du suivant).
En outre selon la longueur des câbles et la vitesse de transmission il peut se produire des erreurs.
Si l'on veut communiquer sérieusement entre deux µcontrôleurs il faut gérer les erreurs de transmission et les time-outs.

Le scénario demandé par biggil est indispensable mais il manque aussi pas mal d'informations, en particulier la longueur des câbles, et la vitesse de transmission visée.
Et aussi pourquoi cette architecture ? est-elle vraiment justifiée ? quel est le but final ? j'entends par là quelle est la teneur des échanges ? transmettre des nombre oui, mais s'agit-il de données provenant d'un capteur, d'un clavier, etc. ?

8

Voici le schéma de mon projet, c'est un prototype. Les éléments sont à une distance maximale (longueur de câble) de 50 cm. Et j'ai choisi arbitrairement une vitesse de communication de 9600 bauds.

Dans le principe, un utilisateur demande via une interface tactile, que des moteurs pas à pas tournent un certain nombre de tours (4 tours par exemple). L'arduino Mega reçoit cette information et l'envoi à l'arduino Nano 1 pour qu'il fasse tourner les moteurs pas à pas de 4 tours. Une fois que les moteurs ont fini leur travail, l'arduino Nano 1 signale à l'arduino Mega que les moteurs ont fini leur job. Suite à cette information reçue, L'arduino Mega demande à l'arduino Nano 2 la valeur qu'il a pu mesurer avec le codeur rotatif (un nombre de pas du codeur pour être exact). Ensuite grâce à cette nouvelle information, l'arduino Mega calcule et ajuste le nombre de rotation des moteurs (4,5 tours si besoin, par exemple). L'arduino Mega renvoi alors un nouvel ordre de rotation à l'arduino Nano 1 et ainsi de suite ...

https://drive.google.com/file/d/1MBb20sktvKYNQwBk3s8otHnGrHYtZbh2/view?usp=sharing

9

Le but final de ce prototype est de remplacer les arduinos Nano par un servovariateur de type industriel et l'arduino Mega par un arduino Mega de type lui aussi industriel. le tout communicant via RS485 sur une distance maximale de 5m et avec une vitesse de transmission la plus adéquate possible.

Je vous remercie encore pour l'intérêt que vous portez à mon projet et vos réponses.

10

le tout communicant via RS485

C'est nouveau. En tous cas par rapport à la question d'origine :

  • Quel est le meilleur moyen de les faire communiquer entre eux (Rx/Tx, I2C, etc ...) ?

Cela change pas mal de choses, et on ne voit pas bien ce que vient faire l'I2C ici.

Le RS485 implique du hardware (module RS485).
Ensuite pourquoi développer du logiciel esclave sur NANO si c'est pour ensuite remplacer par un servovariateur industriel ?
Il va falloir étudier très sérieusement la spécification du servovariateur.

11

vincent59hp:
L'arduino Mega reçoit cette information

Ca veut dire que la situation "normale" pour le Mega est d'attendre une instruction.

et l'envoi à Nano 1 pour qu'il fasse tourner les moteurs pas à pas de 4 tours. Une fois que les moteurs ont fini leur travail, Nano 1 signale à Mega que les moteurs ont fini leur job. Suite à cette information reçue,

Que fait le Mega pendant ce temps ? Peut-il se permettre de "bloquer" en attente de la réponse ? Ou bien doit-il continuer à assurer d'autres tâches ? Si oui, que se passe-t-il si une nouvelle instruction arrive alors que la précédente est en cours de réalisation ?

Le Mega demande à Nano 2 la valeur qu'il a pu mesurer avec le codeur rotatif. Ensuite grâce à cette nouvelle information, l'arduino Mega calcule et ajuste le nombre de rotation des moteurs). Le Mega renvoi alors un nouvel ordre de rotation à l'arduino Nano 1 et ainsi de suite ...

ainsi de suite ? Ca s'arrête comment ? A quel moment le Mega revient-il en attente de nouvelle instruction ?

12

Biggil :

Ca veut dire que la situation "normale" pour le Mega est d'attendre une instruction.

Oui, au début, il attend une instruction de départ et un appui de bouton poussoir. Je ne les ai pas mis sur mon schéma car je pensais qu'il était inutile de le surcharger mais suite à tes questions, je me rends compte qu'ils ont leur importance. Voici le lien du schéma corrigé : Schéma prototype.PNG - Google Drive

Que fait le Mega pendant ce temps ? Peut-il se permettre de "bloquer" en attente de la réponse ? Ou bien doit-il continuer à assurer d'autres tâches ? Si oui, que se passe-t-il si une nouvelle instruction arrive alors que la précédente est en cours de réalisation ?

Il doit effectivement assurer la surveillance des boutons poussoirs, surtout celui d'arrêt. Le Mega doit surveiller en permanence l'état de ce bouton poussoir lorsque le cycle est en "marche".
Nb : Le bouton poussoir est appuyé par une personne, on peut estimer le temps d'appui égal à environ une seconde.

ainsi de suite ? Ca s'arrête comment ? A quel moment le Mega revient-il en attente de nouvelle instruction ?

Le bouton poussoir d'arrêt stoppe le cycle et le Mega passe en attente d'instructions de l'écran tactile et du bouton marche.

Hbachetti :

Le RS485 implique du hardware (module RS485).

Oui, j'aurais du partir dans ce sens tout de suite et me concentrer directement sur le but final qui est une utilisation du RS485. Lorsque j'ai posé ma première question, je pensais avoir une réponse toute bête, du type "prends tel type de communication, utilise tel fonction pour envoyer ta valeur à l'autre arduino et c'est réglé". Je vois maintenant que ma première question est beaucoup plus complexe et implique un fonctionnement clair et une hiérarchie bien établie entre les divers acteurs.

Ensuite pourquoi développer du logiciel esclave sur NANO si c'est pour ensuite remplacer par un servovariateur industriel ?

L'achat d'un servovariateur de type industriel n'a pas le même coût qu'un arduino Nano. Je veux d'abord arriver à développer toute la structure du programme (gestion écran tactile, gestion entrées/sorties, gestion calcule d'ajustement du nombre de rotations, etc ...) pour ensuite n'avoir plus qu'à me concentrer sur l'aspect communication avec le servovariateur.

13

Tu peux parfaitement développer le logiciel principal en simulant la partie servovariateur, avec un bout de code sur la MEGA, y compris en envoyant les valeurs de simulation sur le port série.
Car pour simuler un servovariateur RS485 avec une NANO il va falloir connaître parfaitement ce servovariateur, et d'abord le choisir.