[conseil] Comment faier communiquer 12 Arduinos et un Rasperry

Bonjour,

Je n'arrive pas à trouver d'information complète alors je me lance sur ce forum.

Je chercher à réaliser un projet à base de 12 Arduinos (nano) et 1 Rasperry. En gros je souhaite que chaque Arduino ait sa fonction, et qu'ils soient en communication avec un Rasperry (ou un ordinateur, mais à terme l'ensemble doit être autonome alors je pars tout de suite sur un Rasperry) pour recevoir des instructions et envoyer des messages. Chaque Arduino n'a pas besoin de communiquer avec les autres, il y aurait juste une connexion bi-latérale entre chaque Arduino et le Rasperry. Tous ces modules sont proches les uns des autres phyisiquement donc je peux avoir des connexions filaires. Et chaque Arduino fait un truc particulier donc je dois pouvoir les identifier.

Je suis relativement novice, et je me pose beaucoup de questions sur la meilleure façon de procéder pour établir les communications :

  • Connexion USB ? Les câbles sont un peu encombrants, les Hub USB chers, et je me demande si en cas de redémarrage (oui, le truc ne va pas resté allumé tout le temps), les ports assignés à chaque Arduino restent identiques : pas pratique pour intégrer le chemin du port (/dev/tty...) si ils changent potentiellement. En testant avec 2 Arduinos sur mon PC il semble qu'ils restent identiques, mais est-ce fiable dans le temps ? Et si je change le Rasperry ? Et j'ai cru voir qu'en production la communication via USB est à prendre avec prudence car reset possible ?

  • Connexion réseau (wifi ou ethernet) : du coup pas très utile vu la proximité des modules, ça oblige à mettre des shields et ça rend l'ensemble dépendant d'un point d'accès réseau qu'il faudrait en plus paramétrer pour la partie wifi (je vais dépendre d'une connexion réseau, bof).

  • Existe d'autres solutions ? Je suis un peu novice mais je sais souder si nécessaire (et j'ai le materiel pour).

Merci d'avance pour vos conseils, j'espère que mes questions sont claires, et bonne journée à tous ceux qui ont eu le courage de lire mon message jusqu'au bout :-)

Tu pourrais envisager des modules RF comme ceux-ci (15€ par paquets de 10) :

13 paires de modules pour des communications bilatérales avec le RPi, et un protocole de communication bien maîtrisé pour éviter les conflits et les pertes d’information.

Tu peux commencer par tester une comm simple entre 2 arduinos comme ceci. Ensuite insérer le RPi

Salut

En testant avec 2 Arduinos sur mon PC il semble qu'ils restent identiques

Sous Windows OUI. Avec une RASPBERRY ce n'est pas garanti. Le port de com peut changer.

Puisque tu envisages les câbles USB, j'en déduis que la distance est faible.

RS485 ? Nécessite une implémentation de protocole série.

En radio il y a aussi les NRF24L01, qui intègrent déjà la notion de réseau et de nœud (adresse). Très simple à mettre en oeuvre. Avantage : pas de câbles, 2.4GHz mais indépendant du WIFI, moins cher qu'un câble Ethernet.

@+

Si la distance est courte pourquoi pas l'I2C ? C'est bien pour cela qu'elle a été conçue. Chaque esclave aura une adresse propre (ce sera au programmeur de la définir). Les micro Atmel fonctionnent jusqu'à SCL = 400 kHz.

Et aucune pollution par ondes maléfiques.

Merci pour vos réponses, c'est interessant.

Je suis bien tentée par la communication radio, ne serait-ce que pour jouer à voir comment ça fonctionne.

Pour I2C, j'ai lu que c'était très sensible aux interférences, et dans mon projet il peut y avoir quelques servomoteurs, des ouvertures avec aimants et interrupteurs ITL... Est-ce que ça poserait problème ?

Je vais fouiller ces pistes en tout cas.

Merci

68tjs: Si la distance est courte pourquoi pas l'I2C ? C'est bien pour cela qu'elle a été conçue. Chaque esclave aura une adresse propre (ce sera au programmeur de la définir). Les micro Atmel fonctionnent jusqu'à SCL = 400 kHz.

Et aucune pollution par ondes maléfiques.

Oui, tout à fait d'accord, i2C est idéal pour ça et est bien implémenté dans Arduino. Je pourrais te fournir des programmes que j'ai développé et qui transforment les Arduino en Master ou en Slave i2C, j'ai développé ceci pour collecter les données d'appareils de mesure. J'en ai une version minimum que tu peux facilement ajuster à tes contingences. Pour ce qui est des perturbations, un câblage de qualité peut éviter ce genre de problème.

Cordialement jpbbricole

Je suis preneuse, merci beaucoup ! (Mais je vais quand même aussi jouer avec la radio, ça à l'air marrant et je pourrais en faire d'autres usages).

Pour ce projet précis je vais donc commencer par explorer I2C. Qu'est-ce que tu entends par un câblage de qualité ? Tout est dans la qualité du cable ?

laucel: Je suis preneuse, merci beaucoup ! (Mais je vais quand même aussi jouer avec la radio, ça à l'air marrant et je pourrais en faire d'autres usages).

Pour ce projet précis je vais donc commencer par explorer I2C. Qu'est-ce que tu entends par un câblage de qualité ? Tout est dans la qualité du cable ?

Si c'est un milieu perturbé, un bon petit câble blindé avec une bonne masse (GND) peut faire l'affaire. On peut même "transporter" l'alimentation 5V. pour les Arduino par le bus i2C, donc le blindage sera connecté au GND des Arduino. Dans mon système, c'est un Mega qui "alimente" les Arduino slave. Je ne connais pas suffisamment le RPI pour assurer cette partie mais en te basant sur le programme du Mega tu pourras extrapoler, le programme est assez simple. Je te prépare un topo, j'attend du matériel, j'avais déjà prévu faire une maquette réelle de ce bus avec un Mega et 6 Pro Mini. Je t'envoie ça au début de la semaine prochaine

Bonne soirée Cordialement jpbbricole

Je suis bien tentée par la communication radio, ne serait-ce que pour jouer à voir comment ça fonctionne.

Pour I2C, j'ai lu que c'était très sensible aux interférences, et dans mon projet il peut y avoir quelques servomoteurs, des ouvertures avec aimants et interrupteurs ITL... Est-ce que ça poserait problème ?

Effectivement, dans mes propositions je n'avais pas pensé à l'I2C. Par contre, l'I2C est prévu normalement pour des communications sur des distances très courtes, normalement sur la même carte. Mais on fait bien communiquer des modules I2C avec des câbles DUPONT courts, n'est-ce pas. Pour un maquettage ça passe.

Si la communication passe par des câbles, il faut soigner deux points : - la fréquence est élevée mais pas trop. Ce n'est pas du 1Wire à qq dizaines de KHz. D'autres personnes sauront mieux répondre que moi en ce qui concerne le type de câble à employer (68tjs ?) - la connectique doit être irréprochable, les faux-contacts sont interdits, sous peine de voir le logiciel bloquer en attendant des réponses qui ne viennent pas

Si les distances sont vraiment courtes, pourquoi ne pas utiliser un seul gros processeur du genre STM32 ou ESP32, avec des expanders pour augmenter le nombre d'I/O, quitte à utiliser le multi-threading pour que chaque tâche soit bien séparée ?

Mais pour pouvoir répondre, il manque des infos. Quelle est la finalité du montage ?

@+

hbachetti: Par contre, l'I2C est prévu normalement pour des communications sur des distances très courtes, normalement sur la même carte.

Pas tout à fait, c'est plutôt à l'intérieure des appareils comme chaîne HI-FI, téléviseurs, domotique..., et il existe des amplis de bus qui permettraient d'aller jusqu'à 50m. Un peu de lecture.

Cordialement jpbbricole

je n'ai pas immédiatement le temps de développer mais dire que l'I2C travaille avec des collecteurs ouverts revient à dire que l'I2C travaille avec des transistors en montage collecteur commun.

Dans ce type de montage l'impédance équivalente vue de la l'émission est équivalente à celle de la résistance effective de collecteur. On est donc dans des liaisons à forte impédance qui sont sensibles à la capacité de la charge.

La capacité de la liaison est égale à la somme des capacités d'entrée des différents modules récepteurs, PLUS celle apportée par le ou les câbles de liaison. Le schéma équivalent est celui de la charge d'un circuit RC (voir un peu de doc). Pour avoir une bonne transmission il faut que la valeur de la constante de temps (produit de la résistance par la capacité) soit faible devant celle de la période des signaux. Ce n'est donc pas une question de parasitage mais de déformation des signaux.

Pour y remédier on lit souvent qu'il faut baisser la valeur de la résistance R, celle que certains appellent poule-eupe :) et que moi j'appelle résistance de charge des transistors parce que elle ne fixe pas un potentiel mais sa présence est indispensable pour avoir un montage collecteur commun.

On peut aussi faire des liaisons les plus courtes possibles pour diminuer la capacité aportée par les fils, on peut faire un câblage intelligent en cherchant à optimiser la longueur totale de fillasse.

On peut aussi baisser la fréquence de fonctionnement de l'I2C. Jusqu'à présent j'ai parlé de baisser la valeur du produit RC en agissant soit sur la résistance équivalente (toutes les résistances sur les différents modules se retrouvent en parallèle) soit sur la capacité des fils mais si cela devient impossible il est possible de baisser la fréquence de l'I2C. L'important ce n'est pas la valeur du produit RC, l'important c'est la valeur relative entre la période des signaux et le produit RC. La bibliothèque Wire permet de le faire même la fonction qui permet de le faire n'est pas documentée. On peut utiliser d'autres fréquences que les fréquences recommandées que sont 100 kHz et 400 kHz.

Rappel pour le cas où : la période est l'inverse de la fréquence, la période est un temps.

ça sent l’escape Room ce projet :) - je me trompe ?

68tjs: je n'ai pas immédiatement le temps de développer mais dire que l'I2C travaille avec des collecteurs ouverts

C'est déjà pas mal :) Dire que je pratique pas mal de l'i2c en ignorant tout ça... J’apprécie tes théories, mais je trouve que tu compliques une chose qui est, au demeurant, et surtout grâce aux composants (modules) disponibles, assez simple à développer pour le néophyte.

Cordialement jpbbricole

J-M-L: ça sent l’escape Room ce projet :) - je me trompe ?

Pas compris!!!

Cordialement jpbbricole

jpbbricole:
Pas compris!!!

Cordialement
jpbbricole

Je m’adressais à Laucel (j’essayais de deviner son projet d’application)

Si l’environnement n’est pas perturbé et l’alimentation pas un soucis je regarderais la partie radio - c’est simple à mettre en œuvre avec les librairies RF24, sinon du RS485 si plus de quelques dizaines de cm et perturbations électromagnétiques

jpbbricole:
J’apprécie tes théories, mais je trouve que tu compliques une chose qui est, au demeurant, et surtout grâce aux composants (modules) disponibles, assez simple à développer pour le néophyte.

Il y a deux façon de répondre : soit en répondant strictement en donnant une solution toute faite adaptée à un cas particulier, soit en expliquant dans le but de rendre le demandeur autonome afin que dans un cas similaire il n’ait plus besoin de poser de question.

Les deux publics correspondants à ces deux façons de répondre sont présent sur ce forum.
Tu répond au premier, moi je m’adresse au second.

L’avantage de l’explication c’est que le jour où vous aurez un problème Avec une approche « toute bête sur De l’I2C Sans se poser trop de question » et en Priant que ça tombe en marche, c’est que vous aurez des outils pour explorer les problèmes potentiels.

L’inconvénient bien entendu c’est que pour comprendre ce que 68tjs a dit, il faut quand même un minimum de bagage électronique théorique et ça c’est pas donné à tout le monde sur ce forum.

Bref, Il y en a pour tout les goûts et c’est tant mieux

Tant que nous n'aurons pas une idée plus précise du projet, inutile d'aller plus loin. Le problème de la majorité des demandes est que le fonctionnel n'est pas mis en avant par le demandeur ou la demandeuse ("Je suis bien tentée", "Je suis preneuse"). Les gens s'embarquent souvent dans une solution technique d'entrée de jeu, alors qu'en posant la question de manière fonctionnelle dès le départ, la direction suivie et conseillée par nous serait probablement différente, plus rationnelle, moins sujette à problèmes, et moins complexe. Je suis le premier à me faire avoir je l'avoue. Je réponds, mais je me dis ensuite "tu as tort, tu ferais mieux de poser des question d'abord".

@+

clairement. Si les éléments sont si proches, on peut se poser la question de savoir si un seul "arduino" ne pourrait pas faire tout le job.

68tjs:
je n’ai pas immédiatement le temps de développer mais dire que l’I2C travaille avec des collecteurs ouverts revient à dire que l’I2C travaille avec des transistors en montage collecteur commun.


Rappel pour le cas où : la période est l’inverse de la fréquence, la période est un temps.

J-M-L:
L’avantage de l’explication c’est que le jour où vous aurez un problème Avec une approche « toute bête sur De l’I2C Sans se poser trop de question » et en Priant que ça tombe en marche, c’est que vous aurez des outils pour explorer les problèmes potentiels.

Si on peut appeler ça une explication, ça tient plutôt de la thèse (montage collecteur commun… 'impédance équivalente vue de la l’émission est équivalente à celle de la résistance effective de collecteur… Le schéma équivalent est celui de la charge d’un circuit RC (voir un peu de doc)… etc. etc., je doute fort que ce genre lithanie technique, dont je doute qu’un grand nombre de membres de ce forum soient capables d’en tirer une substance quelconque, soit d’une aide quelconque a une personne qui se qualifie de “relativement novice”, ça pousserai plutôt à la fuite, a abandonner le projet, le bus i2C en particilier.
Ce genre “d’explications” étaient utiles il y a 20 à 30 ans en arrière, le concept de l’Arduino a été développer pour simplifier et populariser l’usage des microcontrôleurs donc, logiquement un forun consacré à cette “bête” devrai tendre vers le même but!
Mais je vais cesser de râler et me contenter de lire et même de rire de ces “explications”

laucel, pardon pour ce HS

Cordialement
jpbbricole