LOCODUINO
Parlons Arduino => Composants => Discussion démarrée par: savignyexpress le septembre 14, 2015, 10:48:05 am
-
Bonjour à tous,
Dans le cadre des réflexions sur mon nouveau réseau N, j'évalue les possibilités de cet IC de microchip qui permet d'ajouter des entrées-sorties numériques: http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf). Au prix de CHF 2.- pour 16 E/S supplémentaires, c'est tout à fait intéressant.
Dans un autre projet, j'avais utilisé des registres à décalage 74HC595 pour ajouter des sorties, mais ce circuit me semble plus souple car il permet la configuration individuelle de chaque pin en sortie, en entrée avec pull-up intégrée si nécessaire.
Si j'utilise ce circuit, ce sera avec l'interface I2C car le SPI est déjà utilisé par la programmation in situ du microcontrôleur. Avec un Arduino et son bootloader, on doit pouvoir travailler en SPI. Les longueurs de bus seront d'au plus 20-30 cm si sur une autre plaque et, dans ce dernier cas, les liaisons se feront avec du câble Ethernet afin de bénéficier du blindage.
Avez-vous de l'expérience avec ce composant ?
Merci d'avance pour vos contributions.
Meilleures salutations.
Marc-Henri
-
Salut Marc-Henri,
J'ai utilisé ce matériel avec le bus I2C (voir forum Loco Revue http://forum.e-train.fr/viewtopic.php?f=63&t=77541 (http://forum.e-train.fr/viewtopic.php?f=63&t=77541)).
Oui, c'est moi groumfit ...
J'ai testé : ça fonctionne, c'est vrai. Mais l'I2C n'est pas protégé contre les parasites et je vais tester le CAN, nettement plus prometteur et plus costaud.
Il y a d'ailleurs plein de recherches sur ce (long) post.
Depuis, j'ai trouvé. Tu pourras voir mes articles préparés sur Locoduino (SGDD).
Je pense que tu auras des questions à me poser ;)
-
Bonjour
Le bus I2C est fait pour connecter des circuits sur une courte distance, il est tout a fait indiqué ici. Sur un premier réseau j'utilisais des PCF8574 circuits I2C du même genre que les MCP23017 mais sur 8 bits. Je vais les réutiliser pour commander les, nombreux, feux de mes signaux lumineux, si je n'avais pas déjà ces circuits je mettrais volontiers des MCP23017. Pour les signaux mécaniques j'utilise un PCA9685 toujours sur le bus I2C, en fait c'est un module Adafruit car le PCA9685 est en CMS.
J'utilise aussi deux bus I2C pour relier toutes les cartes électroniques de mon réseau à un ordinateur, toutes ces cartes étant regroupées en un seul endroit sous le réseau.
Il y a des bibliothèques Arduino chez Adafruit pour le MCP23017 et le PCA9685.
Pierre
-
Bonjour Denis et Pierre,
Merci pour vos retours d'information.
La question du blindage de l'I2C me paraît très pertinente.
Je me suis trouvé confronté à un problème similaire avec une chaîne de registres à décalage perturbés par les pointes de courant de moteurs d'aiguilles Minitrix qu'ils commandaient via des relais. Le problème s'est résolu en reliant les cartes avec du câble Ethernet transportant data, l'horloge série, l'impulsion de chargement en sortie et la masse.
Je me demande s'il est vraiment nécessaire de placer ces circuits dans des boîtiers blindés ainsi que Denis l'évoque dans son post sur le forum LR. Mon projet étant en analogique, sans DCC, mais avec des moteurs d'aiguille et peut-être tout de même des alimentations traction en PWM, il faudra voir s'il y a des perturbations.
Bonne fin de semaine et meilleures salutations.
Marc-Henri
-
Bonjour Marc-Henri,
Je rejoins l'avis de Pierre : j'étais un peu catastrophiste sur le forum LR.
Sur de petites distances, on peut très bien utiliser un bus I2C. Il a le grand mérite d'exister directement sur l'Arduino et d'être ultra simple à gérer.
Mais, évidemment, si le fil passe à côté de la voie, au moment où la loco passe, tu as une gerbe d'étincelles. Ou à côté d''un moteur d'aiguille.
Donc, suivant les usages et en prenant un minimum de précautions, ça doit marcher sans problème.
Disons que, sur Locoduino, on a un faible pour le bus CAN. Je suis en train d'apprendre à m'en servir. C'est un peu moins évident, c'est sûr.
Bonnes lectures ;)
-
Bonjour Denis,
Dans mon projet, le bus I2C sera local à une carte (cas de modules d'extension d'entrées-sorties) ou éventuellement plusieurs cartes espacées de 10-20 cm (cas d'un microcontrôleur séparé). Je ferai aussi en sorte de bien séparer les circuits de puissance.
Bonne journée et meilleures salutations.
-
Bonjour,
Voici mon expérience en matière d'expansion des E/S sur Arduino (Uno).
Premier montage: Commande de 48 aiguillages par servos à mouvements lents
(par servo, 4 points de courses réglés individuellement et mémorisés en EEPROM, de façon à passer, dans chaque sens, par une position de course extrême, avec un bon forçage mécanique, puis placement dans une position de repos avec effort et conso réduits)
C'est une sorte de TCO, sans retour optique toutefois, les positions d'interrupteurs en tenant lieu. Ce retour aurait été possible, mais boff.
J'ai eu, au départ, de grosses difficultés avec ce montage comportant sur un bus I2C :
- 2 cartes d'expansion 16 voies d'E/S Sx1509 de Sparkfun (pour une bonne vingtaine d'interrupteurs),
- 3 cartes PWM Adafruit 16-Channel 12-bit PWM/Servo Driver - I2C interface - PCA9685 (pour alimenter 48 servos d'aiguillages)
- et un afficheur 2 lignes à LCD sur I2C.
- étape 1 : bus I2C comportant quelques mètres à l'extérieur du boîtier (cartes PWM à proximité des servos) ; perturbations immédiates et irréversibles du bus dès débit sur les alimentations analogiques (mais néanmoins hachées) des locos, sous seulement 6V -> solution à écarter impérativement
- étape 2: j'ai compris que les plus grosses perturbations étaient liées à l'écran LCD piloté par I2C; j'ai essayé plusieurs modèles, tous fautifs -> écran LCD piloté par I2C à écarter : il faut piloter l'écran en direct par des E/S tout ou rien; dommage, je n'ai pas compris pourquoi, mais c'est comme ça.
- étape 3: pour être sûr du résultat, comme je voulais passer l'alimentation des locos d'analogique continu à DCC, j'ai voulu mettre toutes les chances de réussite de mon côté et j'ai donc retenu toutes les précautions de blindage possibles :
. circuit I2C uniquement à l'intérieur des boîtiers (3 boîtiers Teko ou équivalents empilés), liaisons entre cartes par câble blindé et mise à la masse du blindage à une seule extrêmité du câble; longueur totale d'environ 60cm;
. boîtiers plastiques, mais blindés de l'intérieur avec un film d'aluminium auto collant (j'avais un rouleau de film prévu pour faire les joints entre rouleaux d'isolants thermiques domotiques - à placer sous les toits) : la continuité électrique entre bandes collées avec recouvrement (il en faut plusieurs pour couvrir toutes les surfaces) est très bonne et le blindage est solide et bien continu;
. isolement opto-galvanique + porte logique de remise en forme pour les sorties PWM (pilotage des servos); 12 câbles de liaisons vers les servos soigneusement blindés, avec mise à la masse du blindage côté boîtiers (cela représente une longueur cumulée considérable d'une trentaine de m);
. alimentations séparées pour, d'une part la partie Arduino et circuits logiques intérieurs aux boîtiers, d'autre part les circuits extérieurs aux boîtiers (puissance et pilotage des servos); un régulateur de tensions déporté au plus près des servos, pour chaque groupe de 4 servos.
Résultat : plus de problème de perturbations du bus I2C , ni même de vibrations résiduelles des servos au repos, même après être passé en DCC pour l'alimentation et le pilotage des locos du circuit (8 actuellement)
Conclusion pour ce montage :
Outre le circuit I2C trop long, la perturbation venait surtout de l'afficheur LCD piloté en I2C.
Dans un deuxième temps, j'ai pris les précautions maximales en terme de blindage. Non seulement le bus I2C n'est plus perturbé, mais il me semble que le fonctionnement des servos est plus net (plus de vibrations résiduelles au repos, avec les consignes de butées bien réglées).
Le montage permet de piloter 48 aiguillages dans un environnement de locos pilotées en DCC. On pourrait augmenter ce nombre car le nombre de cartes PWM pouvant être couplées est bien supérieur (...et il reste de la place dans les boîtiers).
Remarque : L'environnement d'un circuit ferroviaire est plutôt bruité électromagnétiquement, et les précautions de blindage ne sont certainement pas un luxe. Elles ne sont pas si difficiles que cela à mettre en oeuvre, avec les quelques 'astuces' indiquées. J'ai rétrospectivement un doute sur la nécessité impérative du découplage opto-galvanique des signaux PWM de pilotage des servos, mais c'est fait et ça ne peut nuire.
Deuxième montage: Commande individuelle de 8 locomotives en DCC, par encodeurs rotatifs et boutons-poussoirs
Un montage comportant 4 cartes d'expansion 16 voies d'E/S Sx1509 de Sparkfun (pour gérer des boutons de contacts tout ou rien et des encodeurs rotatifs [2 contacts TOR]); il y a 8 fois un encodeur + 4 contacts, soit 48 contacts ce qui permet de piloter en direct huit locomotives; il y a quelques autres contacts supplémentaires pour la programmation du couplage de locos entre elles et diverses fonctions.
Tenant compte de l'expérience précédente l'écran LCD 4 lignes est piloté directement en tout ou rien. Le montage comporte aussi le circuit LM18200 (cité sur Locoduino) pour mettre en forme les signaux DCC. A la différence du précédent montage, pour ne pas risquer de détériorer les fronts du signal DCC, je n'ai pas placé d'isolement opto-galvanique sur le signal de pilotage DCC (isolement entre bas niveau et puissance'). Bas niveau et puissance sont toutefois placés dans deux boîtiers distincts, alimentations comprises.
Les mêmes précautions de blindage que ci-dessus ont été prises pour les deux boîtiers superposés abritant le montage.
Résultat : Le montage fonctionne parfaitement, sans perturbations, et permet de piloter simultanément en DCC 8 locomotives, chacune ayant sa vitesse contrôlée par son propre encodeur rotatif. Affichage sur LCD des vitesses (cible et actuelle) des locos, témoin d'allumage des feux, etc...
Complément sur la carte d'expansion 16 voies d'E/S Sx1509 de Sparkfun:
La version que j'ai utilisée a été stoppée récemment et remplacée par un nouveau modèle (non testé) encore plus petit ce qui peut être intéressant.
On peut programmer chaque carte en entrée, en sortie, avec pull-up ou non, et avec ou sans traitement anti-rebond (plusieurs options).
Pour les entrées, on peut aussi programmer individuellement, pour chaque entrée, une interruption, sur montée, sur descente ou sur changement au choix. L'interruption est valable pour toute les entrées d'une carte, et doit être raccordée à une entrée Arduino sur laquelle on a défini une interruption.
Ensuite, il faut par I2C récupérer un mot d'état de la carte qui indique l'entrée ayant déclenché l'interruption puis lire l'état, si nécessaire (déjà traité anti-rebond, si on a choisi cette option). Ce processus est très réactif et très rapide. Pas besoin de polling permanent des E/S.
De la sorte, j'ai même pu traiter au travers de telles cartes les encodeurs rotatifs. Bien sûr, il faut modifier la bibliothèque de base fournie avec les encodeurs (notamment parce que le programme d'interruption ne peut, par construction, contenir de lecture I2C faisant elle-même appel à des interruptions), mais ça se fait assez facilement, et ça marche très bien.
Sur l'ancien modèle, compte tenu des possibilités de paramétrage des adresses, on pouvait utiliser 4 cartes sur le même bus, soit 4x16 E/S.
Pour le modèle de carte PWM, le nombre de cartes pouvant être mises en parallèle est encore bien plus grand.
Remarque d'ordre général concernant ces montages comportant beaucoup d'entrées-sorties:
J'ai été frappé par le temps d'assemblage de tels circuits. Pour garder la possibilité de démonter les différents circuits imprimés en cas de besoin, j'ai mis des connecteurs là où c'était indispensable. Cela fini par faire beaucoup de perçages, de soudures, de soudage de câbles sur connecteurs; bien de ces opérations sont assez délicates et fastidieuses, mais inévitables.
Photos et autres renseignements disponibles en cas de besoin.
-
Merci Jac56 pour ton retour d'expérience.
-
Voici un lien pour des compléments plus illustrés sur ces montages.
http://www.forum-train.fr/forum/viewtopic.php?p=265089#p265089
Il m'est aussi revenue une observation faite sur la carte d'expansion Sx1509.
Cette carte, par défaut, fonctionne en 3.3V, avec possibilité, par straps, de la faire fonctionner en 5V.
Sur le montage 1, je l'ai alimentée avec la sortie 3.3V de l'Arduino. RAS.
Sur le montage 2, je l'ai alimentée par un régulateur 3.3V séparé. En passant de 2 à 4 cartes, on n'est jamais assez prudent. Hé bien, le bus I2C ne fonctionnait plus! J'ai compris que cela venait de cette tension, insuffisante : en réalité, cette sortie Arduino délivre plutôt du 3.7V. Pourquoi? C'est comme ça, mais non documenté. Une fois le régulateur ajusté à cette valeur, miracle, tout remarche bien. Sur les circuits imprimés des alimentations, je ménage toujours les pistes nécessaires à l'ajout d'un pont de résistances en cas de besoin d'ajuster la tension de sortie. Heureuse précaution! Le bus I2C, partagé entre les différents modules sous 5V et 3.3V, était pourtant bien alimenté en 5V par l'Arduino. Cette configuration n'aurait pas dû perturber. Hé bien, si.
Conclusion:
- Ces observations sont transposables à d'autres modules de ce type.
- Cette tension de 3.3V diminue peut être la consommation des circuits, mais dans nos montages, ce n'est en général pas critique, et cette mixité peut être source de complications. La preuve. J'aurais dû choisir l'option 5V.
- Il est possible que cela ait joué dans le mauvais comportement des divers écrans LCD-I2C que j'ai testés infructueusement. L'enfer est dans les détails. Il faudrait refaire des tests.
Cordialement
-
Locoduino vient de faire une belle recrue ! Bravo. Belle démo.
Je note en particulier l'inadaptation du bus I2C, certes apparemment facile à gérer, mais qui est sensible à tout. Le bus CAN sera meilleur, sans problème.
Il équipe l'Airbus, la Zoé, la Toyota Prius, ...
Je ne suis pas convaincu non plus par ces multiplicateurs de ports qui, finalement, allongent le câblage. :(
Mais, ce qui est très intéressant, c'est de tester et de décortiquer les dysfonctionnements. Ce que tu as fait.
Merci. :D
-
Je ne crois pas qu'il faille 'jeter' trop vite le bus I2C. A l'intérieur d'un boîtier, difficile de trouver plus simple et plus efficace (je crois que c'est, notamment, le bus interne entre modules des téléphones portables). Beaucoup de modules intéressants fonctionnent avec cet interface.
Les expandeurs d'E/S (pilotés par I2C) sont très utiles: sinon comment prendre en compte plus de 53 contacts pour le module DCC que j'ai décrit, sachant que d'autres contacts supplémentaires doivent nécessairement être utilisés sur l'Arduino (écran LCD en direct, interruptions, pilote DCC, alarme DCC, ...). Même en prenant un plus gros modèle d'Arduino, le compte n'y sera pas. Et de plus, le fonctionnement avec l'I2C est très réactif et efficace (tout est gérable sur interruption, l'anti-rebond est intégré): je cite la gestion d'encodeurs rotatifs (2 contacts à gérer en tenant compte de l'ordre d'apparition des impulsions sur l'un et l'autre). Qui dit mieux ? D'accord, il faut adapter la bibliothèque pour encodeurs, mais ça fait partie de la maîtrise à acquérir...
Les précautions de blindage que j'indique sont assez simples à mettre en œuvre, et ont leur utilité, même sans I2C.
Dans le cas des entrées par boutons, cela ne fait aucun câblage supplémentaire. Tout est dans le boîtier et ne peut être que là, par construction.
Je suis d'accord, inversement, que pour les sorties PWM, on peut faire autrement, avec un bus CAN, soit en utilisant les sorties PWM d'un arduino (mais il y n'y en a pas beaucoup...), soit en utilisant dans le boîtier distant, un module expandeur PWM (un ou plus). J'aurais pu faire cela pour mon TCO : cela aurait drastiquement réduit le nombre de câbles, c'est très vrai !
Mais j'avais déjà fini mon TCO quand les articles réellement utilisables sur le CAN sont parus... (et ils n'étaient que sur le forum).
Les articles présentant en détail la solution CAN ont commencé à paraître seulement en novembre de cette année...
C'est le grand mérite de Locoduino de mettre à la portée de tous des techniques difficiles d'accès au non initié comme le CAN, technique dont l'intérêt d'ailleurs dépasse largement le contexte du modélisme ferroviaire (cf. les applications industrielles citées qui invitent à l'appliquer à bien d'autres domaines encore).
On ne saurait trop remercier pour cela les excellents auteurs qui animent le site Locoduino avec un talent pédagogique remarquable.
-
Tu nous enverras ton RIB, pour le chèque ... ;D ;D ;D
Ces remerciements nous font vraiment plaisir.
Ce que j'aime bien aussi, avec Locoduino, c'est que plusieurs points de vue peuvent s'exprimer.
Il y a ceux qui aimeraient bien un Arduino avec 200 entrées et plein de fils pour centraliser tout et d'autres qui sont pour une décentralisation extrême via le CAN.
Pour ton info, j'ai pris un Arduino DUE et je lui ai branché ... 4 fils : +5V, GND, Can0 Rx et Can0 TX.
J'ai encore de la marge !
J'arrête là car c'est un fil sur les composants.
-
J'explore ce sujet pour la première fois et là je dis "chapeau" pour la qualité et somme d'expériences exprimées par jac56. Merci aussi à Marc-Henri qui aborde toujours des sujets intéressants. Et Denis qui voit tout !
J'ai découvert l'I2C avec l'Arduino en réalisant un drône qui intégre un ATmega328 et plusieurs périphériques accéléromètres, gyroscopes, baromètre et GPS, tous connectés et I2C mais disposés très près du processeur. On trouve maintenant des cartes dites "IMU 9DOF" (9 degrés de liberté). Tous ces capteurs doivent être exploités très rapidement et l'I2C convient parfaitement.
Quand je suis passé au modélisme, j'ai utilisé l'I2C sans problème mais mon réseau était petit et les câbles courts (moins d'un mètre). Je n'ai pas souvenir de parasites.
C'est Jean-Luc qui m'a présenté le CAN pour la première fois et le fait qu'il permette des échanges de messages sans hiérarchie est très pratique pour interconnecter des modules intelligents entre eux comme un réseau local.
Mais cela n'enlève pas l'intérêt de l'I2C pour ajouter des périphériques au processeur.
Je n'ai pas remarqué qu'un écran LCD pouvait générer des parasites.
Je vais regarder ça.
Amicalement