La gestion des cantons par Arduino !!

Petit récapitulatif pour finir ce week-end.

Dans l'état du système aujourd'hui, voici la liste et le nombre de connexions utilisés sur l'Arduino Mega :

- Pour le pupitre, 6 fils (2 pour l'écran, 1 pour le bouton Valider, 3 pour les boutons de choix (potentiomètres))

- Pour la détection de présence (3 zones) des cantons, 6 fils (4 fils pour le choix d'un canton parmi 16 (4 bits), 1 fil pour la lecture de ce canton (il faudra 4 fils pour 64 cantons), et un fil pour validation)

- Pour la commande des locos, 5 fils pour commander le ou les TLC5940 (registres PWM) (1 TLC= 16 cantons commandés, on peut les chainer sans ajouter de fils supplémentaires, donc 4TLC= 64 cantons, toujours 5 fils)

- Pour l'allumage des Leds sur les feux (3 leds par canton), 3 fils pour commander les 74HC595, quelque soit leur nombre.

- Pour les leds du TCO, idem, 3 fils pour les 74HC595, quelque soit la quantité.

- Pour que le système sache si le circuit est en boucle ou linéaire, 1 fil branché sur 2 pins (1 en entrée, 1 en sortie)

Ce qui représente, en tout 25 fils sur mon système actuellement (16 cantons possible mais "que" 6 utilisés, 16 trains, 18 leds pour les feux et 24 leds pour le TCO)
Pour un réseau de 64 cantons, il faudra 28 fils pour commander jusqu'à 50 trains sur ces 64 cantons, soit 192 leds pour les feux, 256 leds pour le TCO.

J'ai réalisé des tests sur le temps d’exécution du programme : moins de 5 millisecondes en moyenne. (je n'utilise que 6 cantons, donc je pense que le temps va augmenter avec le nombre de cantons mais ne dépassera pas les 25 millisecondes)
Ce temps monte à environ 70 millisecondes lorsque je demande une modification de l'affichage de l'écran LCD.

Je pense que c'est un temps correct pour le "boulot" demandé !
A+

nicozea57 a écrit:

On se moque ?

Pas du tout,mais vouloir toujours faire mieux fini par compliquer le truc,et moi,moins c'est compliqué et plus ça m'arrange mais une fois fini ça devrait être sympa

Pour simplifier, voilà, je vous propose une architecture de mon système :



Les cartes cantons sont individuelles, donc on en place juste le nombre nécessaire, et les fils rouge, jaune et bleu correspondent au bus +12V, +5V et Masse des blocs cantons.
Je peaufinerai le schéma avec quelques détails dans la soirée...

Dites moi ce que vous en pensez !!

Je crois que j'ai cramé mon 2ème TLC5940 !!
Plus aucune possibilité de le contrôler...et il chauffe comme le premier....
En épluchant la notice, j'ai vu qu'il était limité à 120mA au total, pour les 16 sorties !!!
C'est un peu léger... Et le courant de référence ne doit pas être inférieur à 5mA !! Soit 5x16=80 mA.
On a donc une plage d'utilisation de 80mA à 120mA, c'est un peu juste non ??
Dès que j'en ai reçu de nouveau, je testerai avec un courant de référence de 6mA, de cette manière, même si les 16 sorties sont actives, je serai au max à 96mA fourni...
Ca devrait permettre de le conserver + de 2 jours en état de fonctionnement

J'ai enfin reçu mes encodeurs rotatifs, j'ai donc remplacé mes potentiomètres et modifié le code.
C'est pas mal, mais il y a un peu de rebonds... Il faut que je gère ça...SierraMike, une solution que tu aurais testée ??

Par contre, j'ai bien mis en évidence que l'envoi de données sur l'écran LCD est très gourmand en temps de programme !! Il va falloir que je cible vraiment mieux les données que je lui envoie pour limiter cela, car ça peut être perturbant si le programme ralentit de trop...(détection retardé, arrêt de locos en dehors de la zone, etc....)
Les millisecondes sont précieuses dans ces cas là !

nicozea57 a écrit:

Je crois que j'ai cramé mon 2ème TLC5940 !!

Ben zut, c'est pas de chance.
Effectivement, la datasheet mentionne un courant de sortie max de 120-130 mA. C'est souvent le cas avec les circuits intégrés, la limite totale est inférieure à N * la limite d'une sortie individuelle. C'est clair que si la résistance IREF-GND impose un courant de 20 mA, multiplié par 16 cela dépasse allègrement cette limite !

Peut-être que le TLC5940 n'est pas le meilleur choix pour distribuer la PWM. Ne faudrait-il pas mieux choisir des circuits logiques, registres à décalage ou modules GPIO via I2C avec de faibles courants de sortie de l'ordre du mA, mais suffisant pour saturer des transistors ? Cela rejoint finalement ton idée de ramener le courant à 6 mA.

Le TLC5940 est un registre à décalage ! Je pense qu'en limitant à 6mA, ça passera !

Là, j'en profite pour optimiser l'affichage du LCD très gourmand en temps..
Je suis en train d'écrire caractère par caractère dans la fonction Loop, à l'oeil, on ne voit quasiment pas de différence, par contre, le programme repasse sous les 10ms...

C'est plein d'embuches, tout ça...
Une fois le fonctionnement totalement validé et fiabilisé, c'est un travail qui vaudra de l'or !

Merci Dominique, j'espère !

Tu sais que tu n'est pas obligé d'écrire tout l'écran à chaque fois ? Tu peux juste rafraîchir un nombre à un endroit précis pour gagner du temps !

En fait tu te rapproches à la main d'un fonctionnement multi thread... ce que j'ai aussi fait de mon côté mais sans voir ton code je ne vois pas ta technique !

Pour l'encodeur rotatif je n'avais pas constaté de rebonds, plutôt quelques loupés en tournant trop vite mais rien de grave.

Oui, j'ai testé en ne modifiant que la partie du texte concerné, mais dès que tu dois envoyer + de 5 ou 6 caractères, tu passes de 3ms de temps de programme à une bonne quarantaine.
Maintenant, j'envoie un caractère à chaque "loop" et je reste en dessous de 10ms.

La technique est simple, j'ai une chaine de caractère dans laquelle je mets tout ce que je veux afficher, puis dans la fonction loop, j'envoie et je supprime les caractères un à un en le positionnant correctement sur l'écran !

T'as pas forcément besoin de le supprimer de la chaîne, manipuler une chaîne de caractères est toujours coûteux, tu peux à la place utiliser un entier index que tu incrémentes à chaque loop et retour à zéro si tu dépasses le max, et dans ton programme tu écris dans la chaîne (qu'on nommera le buffer) et la loop se contente d'écrire perpétuellement le buffer à l'écran

Je viens d'essayer ta méthode, les temps de scrutation ne changent pas d'1 yota...

Ah zut ... Cela dit, ça simplifie pas ton programme et la manière de coder ?

Vous pensez vraiment qu'on est à 30 ms près ?
On serait dans les 300 - 500 ms, je comprendrais bien le risque d'avoir une loco qui dépasse la zone d'arrêt, mais franchement, tant qu'on est sous les 100 ms, je ne vois pas trop l'enjeu...

Sur la totalité du programme, si je laisse 50ms par ci, + 40 ms par là, à la fin j'y arriverai aux 300 ou 500 ms !
Donc, tout ce qui peut être optimisé permet d'éviter de futurs problèmes !!

SierraMike : Non, dans les 2 cas, 4 lignes pour chaque ligne de l'écran ! C'est un peu plus simple avec un compteur entier, mais le résultat est identique.
Par contre, j'ai remarqué que chaque appel de la fonction "lcd.setCursor" demande environ 2 ms, et donc si tu places ton curseur trop souvent, ça peut grimper vite ! (oui, 2 ms c'est rien, mais là on ne parle que de 10 lignes de code, le programme entier dépasse les 2000 lignes !!)

Hello Michael,

Le problème de chaleur produite par le TLC5940 semble courant selon les forums du web et plusieurs personnes signalent l'arrêt de fonctionnement après un fort échauffement.

As-tu prévu un radiateur pour dissiper la chaleur produite par le TLC5940 ? On en trouve même pour les boîtiers PDIP.

La datasheet indique les résistances thermiques pour les boîtiers HTSSOP et VWFN, tout 2 dotés d'une surface de conduction avec le circuit imprimé permettant de dissiper la chaleur sur la carte. Pas d'info en revanche sur le boîtier PDIP qui est dépourvu d'une telle surface ce qui laisse supposer des valeurs plus élevées des résistances thermiques et donc un échauffement plus important.

J'ai lu avec intérêt les échanges sur le pilotage de l'afficheur LCD. Est-ce qu'une tâche dédiée ou une routine d'interruption pourrait parcourir le buffer contenant la chaîne à afficher ?

Bonne suite...

Essayes le TPIC6B595, registre à décalage avec sortie MOS capable de 150mA par sortie.

Pour ton écran à pilotage I2C tu utilise quelle fréquence 100KHz ou 400KHz ?

Je n'ai rien trouvé non plus concernant un support-radiateur pour le TLC5940.
Par contre, ce que j'avais remarqué, c'est que, lors de son fonctionnement "normal", il ne chauffait pas du tout, et en faisant un essai (mais je ne sais plus lequel), il s'est mis à ne plus fonctionner, et quand j'ai vérifié, il était très chaud...
Bref, on verra avec 6mA...

Cleon: Il ne fait pas de PWM le TPIC6B595 !? C'est un simple registre à décalage TOR comme le 74HC595 (avec + de mA en sortie...), je crois
Pour la fréquence, je ne sais pas !

Pour le LCD, une routine d'interruption ne me convient pas trop, car je ne veux pas laisser le circuit sans surveillance trop longtemps... En plus, les interruptions bloquent les fonctions millis() et micros(), donc, plus aucune possibilité de contrôler le temps, et j'en ai beaucoup des contrôles de temps !!
L'interruption est d'ailleurs très souvent utilisée pour les encodeurs rotatifs, mais je ne veux pas en mettre, car trop risqué à mon gout !!
Je préfère pour le moment le gérer caractère par caractère dans le Loop, car, franchement, à l’œil, c'est pas très perceptible ! Et ça gène absolument pas le reste du programme.

Bonjour Michael,

Voici quelques réflexions au sujet du multi-tâches dans une application Arduino.

J'ai bien compris que tu souhaites éviter les routines d'interruption. Je fais de même dans mes applications Atmega / Attiny (je ne passe pas par des Arduino). J'ignore comment tu as structuré ton application, mais passé un certain niveau de complexité, il faut envisager une découpe en plusieurs tâches se déroulant en quasi parallélisme.

Il y a plusieurs approches et peut-être en connais-tu déjà quelques unes. J'ai utilisé ce principe dans certains de mes projets.

Machines d'états quasi parallèles
Ce principe est décrit en détail dans l'excellent article de nos amis de Locoduino: http://www.locoduino.org/spip.php?article6. Tu peux librement appeler les fonctions milis pour gérer le temps dans les fonctions qui réalisent les machines d'états.

Mon premier projet ferroviaire, le TCO de mon 1er réseau, comporte 2 machines d'états parallèle, une principale pour le TCO, une 2ème pour la commande des aiguilles. Voir: https://le-forum-du-n.1fr1.net/t8788-tco-du-reseau-savignyexpress

Séquencement ScheduleTable
Toujours sur Locoduino: http://www.locoduino.org/spip.php?article116, une librairie pour coordonner plusieurs tâches à programmer également comme des machines d'états.

Protothreads
Ce principe, mis en oeuvre dans l'environnement Arduino, est décrit à cette adresse: http://harteware.blogspot.ch/2010/11/protothread-powerfull-library.html. Il s'agit également de fonctions implantant chaque tâche quasi parallèle, mais il n'est pas nécessaire de gérer une machine d'états. Si tu testes une condition, par exemple l'afficheur LCD est-il prêt à recevoir une donnée, et que ce n'est pas le cas, tu sors immédiatement de la fonction et cela ne bloque pas le reste de l'application. À la prochaine itération, la fonction reprend où on l'avait laissée et on teste à nouveau la condition. Cela se répète jusqu'à ce que la condition devienne vraie.

J'ai utilisé avec succès cette technique dans 2 projets:

• Le contrôle de mes 2 PN avec un Attiny 2313. Cf. mon post sur ce sujet: https://le-forum-du-n.1fr1.net/t12790-pn-actionne-par-servo-moteurs-electronique. Je peux ainsi assurer le séquencement des commandes de servos actionnant les barrières tout en faisant clignoter les signaux lumineux des 2 PN, celui avec barrières et celui qui en est dépourvu.
  
• La gestion d'itinéraires de la gare du réseau de Jappy. Cf mon blog: https://savignyexpress.wordpress.com/
  

Merci pour toutes ces choses super intéressantes !! (enfin pour des programmeurs comme nous )

Pour ma part, le programme tourne en continu, et en fonction de ce qui se passe sur les cantons, j'appelle les fonctions nécessaires, les unes derrière les autres.
Je n'ai pas gérer le problème de temps pour le moment car, j'arrive quasiment tout le temps à rester sous la barre des 10ms.
C'est pour ça que pendant les tests je surveille le temps que mets le programme à s’exécuter, car si jamais je vois que ça commence à être trop long, il faudra que je passe par du séquencement avec priorité !

Mes tests actuels se limitent à mes 6 cantons, mais je pense qu'en passant à une plus grande quantité, le temps du programme augmentera proportionnellement et donc, il va falloir y songer !

Je vais certainement passer par une ou plusieurs variable de priorité laissant certaines tâches "au repos" tant que d'autres ne sont pas finies. Ce sera le plus simple je pense...
Je ne manquerai pas d'en faire référence dès que j'y serai confronté !
A+

Petite vidéo (mal filmée) pour vous montrer l'effet que j'ai ajouté dans l'affichage, grâce à la gestion caractère par caractère...
Sur la ligne 4, j'affiche un caractère tous les 5 appels de la fonction Loop(), pour que ce soit un peu moins rapide (5*4=20ms par caractère), j'affiche d'abord une série de 20 tirets pour effacer l'ancien texte, et ensuite j'affiche le nouveau...

Bon, toujours pas reçu mes TLC5940, ni mon module Bluetooth... Chômage technique...

Alors, j'essaye (sans pouvoir tester) d'avancer sur l'option "New Generation" du système :

Oui, oui, option intéressante pour les plus jeunes, enfin...., les moins vieux !!!  
Voici une image de l'écran provisoire, qui reprendra tous les éléments du pupitre:

Voilà, qu'en pensez-vous ?

Perso tant qu'à rentrer dans le monde des objets connectés il me semble qu'une tablette serait plus interessante

Plus grand écran donc plus de possibilités d'affichage futur (TCO par exemple)
Bon je ne sais pas si les 2 sont compatibles,

C'est compatible pour tablettes. Par contre je travaille avec Android pour le moment. Donc pas Apple...
Pour ce qui est affichage du tco, c'est pas évident car chacun aura un tracé différent. ..

Je réfléchis aussi à une option gare automatisée  (cachée ou non) avec configuration depuis le pupitre...

Bien sur mais à voir certains développeurs sur ce Forum ça pourrait en intéresser quelques'uns de pouvoir adapter à leur besoin