Plusieurs Arduino en rs232
Bonjour les gars.
S'il vous plait j'ai une petite question.
Je veux brancher 10 arduinos 1 maître et 9 esclaves en rs 232 de sorte à ce que j'envois un message sur le Tx du maître et que juste l'arduino esclave concerné execute une action... ma question est :
Si je shunt tout les RX des 9 arduinos escalves ensemble, y aura t 'il un soucis ?
Et merci d'avance
à ma connaissance le protocole RS232 ne supporte pas le multiadressage
il faut envisager le RS485 pour du multipoint
Dernière modification par penthode ; 10/02/2019 à 15h16.
[b]le bon sens est un fardeau, car il faut s'entendre avec ceux qui ne l'ont pas [/b]
Merci pour votre réponse.
Non ..au fait je compte gerer ça de manière sift mais ma question tourne autour des niveaux logique du rs232.. je sais que c'est en ttl pour l'arduino mais y aura t'il une shute au niveau des potentiels logique quand plusieurs RX sont shuntés ensemble ?
le rs 232 , c'est +/- 12 volts
il existe des circuits RS/TTL dont le très classique
[b]le bon sens est un fardeau, car il faut s'entendre avec ceux qui ne l'ont pas [/b]
Bonjour,
Tu peux utiliser des modules HC12 sans fil pour communiquer entre le maître et les esclaves selon le principe suivant:
Le maître envoi une trame qui commence avec l'adresse de l'esclave destination (exemple pour l'esclave 1: STX 01 ...).
Tous les esclaves reçoivent la trame, mais seul l'esclave 1 en tient compte et répond au maître en mettant son adresse dans la trame.
Le maître attend la trame contenant l'adresse de l'esclave1.
Ajout au post#5: j'avais réalisé selon ce principe un enregistreur de T° avec comme maître un PC et 4 PIC comme esclaves.
Ce qui permet de relever la T° de 4 pièces d'habitation sans câblage.
Note au modérateur: Je trouve le délai de 5 mn pour modifier un post trop faible et ne vois pas l'avantage que cela procure.
Bonjour,
Électriquement on peut parfaitement connecter un TX à plusieurs RX cela sera au "protocole" de prendre en charge les esclaves.
Ce qui sort de l'arduino n'est pas à proprement parler de la RS232 mais cela y ressemble beaucoup, pour la charge représentée par les entrées RX c'est peanuts car ce sont des entrées CMOS avec éventuellement un pull up.
Un truc inspiré de l'I²C fonctionnera très bien (bien sur sans les nack).
Donc une adresse suivie de datas, l'esclave qui se reconnait les enregistre, mais tous écoutent.
JR
l'électronique c'est pas du vaudou!
Bonsoir
Quand on parle d'Arduino, il faut préciser si l'on se limite au « langage », ou si l'on se réfère à une carte en particulier (en précisant laquelle).
Si tu parles de cartes Arduino animées par un micro-contrôleur ATmega (328P, 2560 ou 32U4), alors leur interface USART présente un mode fonctionnement particulier appelé MPCM (pour Multi-processor Communication Mode) qui permet de filtrer matériellement des trames identifiées par une adresse, de sorte que lorsqu'une carte maître envoie une trame à un ensemble des cartes esclaves, seule la carte destinataire la reçoit effectivement.
Le mode MPCM est décrit dans la datasheet des micro-contrôleurs cités.
Oui, ça marche.
Tu peux mettre les TX des esclaves en entrée par defaut et passer celle du destinataire en sortie pour envoyer un ACK si tu veux ...
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
Pour la réponse des esclaves au maître, ce mode de fonctionnement (i.e. plusieurs sorties TX reliées ensemble, une seule activée à la fois) présente un risque pour des liaisons directes 5V entre micro-contrôleurs (possibilité d'activations simultanées suite à une erreur de transmission ou à un dysfonctionnement logiciel), et n'est pas applicable dans le cas de liaisons RS232 (12V) puisqu'il n'est a priori pas prévu que les sorties des émetteurs puissent passer à haute impédance (pour rappel, RS232 n'est pas un bus).Envoyé par Seb.26
Pour pouvoir « relier » ensemble plusieurs TX (ce qui n'est pas la question posée, je le rappelle), il faudrait ajouter des circuits au niveau du RX commun afin d'éviter les courts-circuits. On pourrait par exemple réaliser un ET logique entre tous les TX reçus par le maître (en partant du principe qu'un seul esclave transmet à la fois et qu'aucun n'émet de break sur sa ligne), ou bien encore laisser le maître ne sélectionner que la ligne TX qu'il souhaite « écouter », par exemple à l'aide de l'entrée ¬EN (Not Enable) du convertisseur MAX3232 (ce qui suppose que chaque ligne soit dédiée à un esclave préalablement identifié).
Dernière modification par PA5CAL ; 11/02/2019 à 10h01.
Bojour
si le but c'est de faire du broadcast alors, comme son nom l'indique, les auditeurs ne sont pas censés répondre sauf bien sur si c'est le "telephone sonne".
C'est une pratique très courante et prévue par bon nombre de bus.
JR
l'électronique c'est pas du vaudou!
Merci beaucoup les gars pour toute ces pertinantes réponses.
Oui effectivement comme le décrit la dernière réponse, mon but est de broadcaster une trame avec un identifiant et que juste l'arduino concernée execute une action specifique. Il y aura une veingtaine donc la communication sera toujour unidirectionnelle de maître vers esclaves.
Et vu que théoriquement je pensai que ça deverai marcher mais j'ai voulu quand même prendre votre avis car je ne l'ai jamais réalisé et peut être un parmi vous l'a déjà fait.
Donc si tout leq Rx des arduinos sont des entrée CMOS avec d'eventuelle résistance de pullup je ne pense pas que cela me causera problème...
Si j'ai bien saisi....
Je ferai un test avec 10 arduino et je reviendrai vers vous.
Merci encore !
Attention.
Sur bon nombre de modèles Arduino, les broches RX et TX sont reliée à l'interface USB de la carte au travers de résistances de 1kΩ.
Dans ce cas de figure, si les liaisons réalisées sont directes (niveaux 5V), alors le branchement d'un nombre important d'entrées RX de cartes esclaves sur la sortie TX de la carte maître risque d'être problématique. En effet, avec dix cartes, la sortie TX devrait alors tirer un courant de 10×5V/1kΩ=50mA à l'état bas, alors que le maximum absolu est fixé à 40mA, et que la limite conseillée est de seulement 20mA.
Perso je trouve ça risqué de ne pas avoir de ACK suite à une commande ...
... donc perso :
> si tu es en UART TTL, tu fais une bidouille comme decrite dans mon post #9
> si tu es en RS232, tu fais une boucle (chaque Tx va sur le Rx du module suivant et comme ça tout le monde peut parler à tout le monde)
Après, tout dépend si c'est pour fermer les portes d'un sous-marin avant plongée ou pour faire clignoter des LED derrière ta TV ...
Dernière modification par Seb.26 ; 12/02/2019 à 08h26.
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
Comme je l'ai indiqué au post #10, cela risque de provoquer des courts-circuits si deux esclaves « parlent » en même temps, ce qui, statistiquement, arrivera fatalement un jour.
De plus, le branchement présenterait le problème que j'ai évoqué au post #13. Au mieux, les transmissions risquent d'être perdues ou fortement altérées. Au pire, les sorties TX des cartes esclaves risquent d'être détruites.
Le problème d'une boucle, c'est que tous les esclaves doivent propager les messages qui ne les concernent pas, et que si l'un d'eux est défaillant ou si une liaison est perturbée, alors des messages peuvent être perdus ou altérés. Avec 10 esclaves en boucle, on multiplie par 5 le risque de perdre un échange données+ACK entre le maître et un esclave particulier.
Voici un exemple de montage permettant de brancher dix Arduinos esclaves (RX1 à RX10) à un Arduino maître (partie gauche) dans le cas de figure que j'ai indiqué au post #13 (cartes Uno ou Nano, par exemple). En bleu, une partie optionnelle, à rajouter si l'on souhaite que les esclaves retournent une réponse au maître. Le circuit doit être déconnecté de l'Arduino durant la programmation des cartes.
Dernière modification par PA5CAL ; 12/02/2019 à 17h10.
... Si c'est bien codé (donc avec << header ; len ; cmd ; data ; crc >> par exemple ) le risque est nettement plus faible que le risque de panne d'un des chip d'une solution hard ... et si vraiment on est parano il suffit d'utiliser des sorties isolées ...
Enfin bref ... y'a pas que le hard qui marche bien dans la vie, hein !!
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
Définitivement non.
Le risque est 5 fois plus élevé si l'on s'en tient aux seuls problèmes de perturbation des liaisons. Si l'on considère les problèmes matériels et logiciels, alors le risque n'est pas plus faible, il est 10 fois plus élevé.
Même si c'est bien codé, rien ne peut garantir que les liaisons soient toujours parfaites (e.g. faux contacts, parasites induits sur câbles par l'environnement, ...), ni que les micro-contrôleurs tournent toujours parfaitement (e.g. problème d'alimentation, interruption par l'interface de communication intégré, niveau de bruit trop élevé sur mes circuits numériques, ...).
En fait, rien ne garantit que le logiciel soit toujours exécuté comme prévu (on a d'ailleurs déjà vu des Arduinos s'auto-déprogrammer par suite d'erreurs de saut causés par des problèmes électriques). Par conséquent, si une situation logicielle est susceptible de provoquer la destruction matérielle du circuit, statistiquement on a l'assurance que cela arrivera un jour, et ce n'est pas en compliquant le programme (et en alourdissant la charge de travail du micro-contrôleur) qu'on pourra y échapper.
Par ailleurs, en plus de rajouter du matériel, utiliser des sorties isolées ne règle pas le problème de court-circuit, puisqu'on le retrouve à la sortie des dispositifs d'isolement. D'une manière ou d'une autre, il faut au minimum que le circuit ne puissent pas griller quand deux esclaves « parlent » en même temps. Il faut donc prévoir une fonction adaptée.
D'une part, aucun protocole ne corrigera la panne d'un nœud dans un réseau en boucle. Si un seul Arduino esclave ou si une seule liaison ne fonctionne plus comme prévu, alors c'est l'ensemble du système de communication qui est hors service.
D'autre part, un petit Arduino a certainement d'autres choses à faire de plus utile qu'à dérouler les protocoles d'un nœud de réseau pour servir d'autres Arduinos qui n'ont rien à voir avec la tâche qu'on lui a assignée. C'est la raison pour laquelle dans le petit monde Arduino on délègue les fonctions de communication, et notamment de réseau, à des circuits spécifiques disposant de plus de ressources.
Mais sans matériel qui marche, il n'y a pas de logiciel.Enfin bref ... y'a pas que le hard qui marche bien dans la vie, hein !!
Or, à l'usage, le matériel rencontre inévitablement des dysfonctionnements, la plupart du temps juste de façon passagère. La conception du système peut faire en sorte de réduire la probabilité de leur survenue et tenter de corriger matériellement ou logiciellement ses conséquences, mais le logiciel ne pourra jamais faire ce que le matériel sous-jacent ne permet pas.
En l'occurrence, le logiciel ne peut garantir que des sorties numériques entrent en court-circuit si la conception matérielle l'autorise, et il ne peut pas non plus faire tourner une boucle de communication qui a été interrompue.
Une bonne conception matérielle est donc un préalable incontournable à la conception d'un système informatisé.
Dernière modification par PA5CAL ; 13/02/2019 à 11h46.
Re bonjour les ami.
Très interessant tout ce qui a été mentionné dans ce post.
Je voulais juste partager avec vous ce qui s'est passé.
Bref.... ça fonctionne à merveille !!!
Mais juste je precise... j'ai chunté tout les Rx des arduino recepteurs avec le Tx de l'arduino emettrice.
J'envois d'abord un code idientifiant de l'aduino que je souhaite adresser suivi des données à executer... tout le reste est geré dans le code... moi j'avais peur que ça stresse la Tx... mais ca va
Merciiii à vous tous
De quel modèle sont les Arduinos récepteurs ? (Si l'émetteur est stressé, il ne va pas le dire, et on ne va pas forcément s'en apercevoir tout suite -- l'agonie peut être lente).
