316
Vos projets / Re : projet centrale wifi DCC++ Can
« le: mars 23, 2020, 09:25:27 am »
Non, la broche 32, c'est le Dir. PWM est à relier à la broche du troisième argument, la EnablePin.
L'Arduino pour le train miniature
Nouvelles:
Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
317
Vos projets / Re : Re : projet centrale wifi DCC++ Can
« le: mars 23, 2020, 08:57:10 am »J'ai essayé : DCCpp::beginMain(UNDEFINED_PIN, 32, UNDEFINED_PIN, A6); et DCCpp::beginMain(UNDEFINED_PIN, 32, UNDEFINED_PIN, 34);
Désolé d'apprendre que ça ne marche pas tout de suite. Mais de mon côté je viens de faire l'essai sur un coin de table (je travaille en théorie...).
De l'un de mes cartons de déménagement (celui qui aurait dû avoir lieu samedi...), j'ai ressorti un ESP32 tout neuf, et j'ai pris mon exemple 'Autotest' avec ta config 32/34 et ça a marché du premier coup. Il faut juste renommer la variable 'time' en 'timeValue', parce que time est un mot réservé de l'ESP32... Et avec l'oscillo j'ai bien un signal DCC sur la broche 32.
Je n'ai pas changé les valeurs de reconnaissance de court circuit, je ne suis pas sûr de savoir faire ça, alors j'ai laissé dans l'état. Mais si quelqu'un me donne les valeurs, je les intègre dans une nouvelle version avec la correction de 'time' en plus.
318
Vos projets / Re : projet centrale wifi DCC++ Can
« le: mars 22, 2020, 05:58:28 pm »
C'est comme tu veux Christophe, vu que l'ESP32 peut faire fonctionner quasiment toutes ses broches sous interruption. Pour mes tests j'ai utilisé
DCCpp::beginMain(UNDEFINED_PIN, 22, UNDEFINED_PIN, A0);
Mais comme le dis Dominique, les broches 22 et 23 sont aussi utilisées pour la communication I2C... Donc une autre peut faire l'affaire. Le troisième argument, je le laisse indéfini dans mon cas, je n'ai pas de bouton pour désactiver physiquement le DCC, mais s'il devait y en avoir un, ce serait avec cette broche.
DCCpp::beginMain(UNDEFINED_PIN, 22, UNDEFINED_PIN, A0);
Mais comme le dis Dominique, les broches 22 et 23 sont aussi utilisées pour la communication I2C... Donc une autre peut faire l'affaire. Le troisième argument, je le laisse indéfini dans mon cas, je n'ai pas de bouton pour désactiver physiquement le DCC, mais s'il devait y en avoir un, ce serait avec cette broche.
319
Vos projets / Re : projet centrale wifi DCC++ Can
« le: mars 22, 2020, 02:53:53 pm »
Bonjour à tous.
Je vous informe que la brique essentielle que vous attendiez tous est enfin disponible ! J'ai poussé la version 1.4.0 de DCCpp qui intégre l'ESP32, mais aussi d'autres nouveautés comme le pilotage à une seule interruption en AVR, la possibilité de fixer par code le seuil de reconnaissance de lecture de CV, etc...
Je n'ai pas testé toutes les parties annexes : turnout, sensor, outputs... Par contre le pilotage par liaison série fonctionne bien.
La preuve en image, que ça marche sur mon banc de test + locodrome, le tout validé par Monia, toujours très intéressée par ce qui bouge tout seul :
Je vous informe que la brique essentielle que vous attendiez tous est enfin disponible ! J'ai poussé la version 1.4.0 de DCCpp qui intégre l'ESP32, mais aussi d'autres nouveautés comme le pilotage à une seule interruption en AVR, la possibilité de fixer par code le seuil de reconnaissance de lecture de CV, etc...
Je n'ai pas testé toutes les parties annexes : turnout, sensor, outputs... Par contre le pilotage par liaison série fonctionne bien.
La preuve en image, que ça marche sur mon banc de test + locodrome, le tout validé par Monia, toujours très intéressée par ce qui bouge tout seul :
320
Vos projets / Re : projet centrale wifi DCC++ Can
« le: mars 19, 2020, 11:34:34 am »
Pour ce qui est de la performance, deux threads, c'est à dire deux coeurs qui marchent simultanément, c'est équivalent à deux Nano (à la vitesse d'un coeur ESP...) complètement séparés. La seule contrainte serait le partage de données qui obligerait un thread à attendre l'autre. Mais si on répartit les choses logiquement, c'est à dire un thread pour DCCpp avec ses propres données, et un autre pour la communication vers l'extérieur, ou même un gestionnaire, ça peut tout à fait fonctionner. A moins qu'il n'y ait quelque chose que je ne vois pas.
A noter que ces jours ci je travaille, mais je vais très probablement me remettre à l'ESP ce week end...
A noter que ces jours ci je travaille, mais je vais très probablement me remettre à l'ESP ce week end...
321
Vos projets / Re : projet centrale wifi DCC++ Can
« le: mars 17, 2020, 08:54:00 am »
L'exemple est sympa et parlant. La difficulté de la gestion multi-tâche réside essentiellement par les synchronisations qu'il faut généralement mettre en place pour éviter les conflits d’accès et/ou d'écriture sur les mêmes données. Les langages C et C++ prévoient des mécanismes type mutex, sémaphore ou lock pour justement contourner ces problèmes. Je ne sais pas ce qui est vraiment disponible pour l'ESP32, et en particulier si c'est utilisable avec un Arduino IDE...
322
Débuter / Re : Re : Communication via USB avec un moniteur série non IDE
« le: mars 16, 2020, 09:09:21 am »C'est pourtant du texte tout simple, sans accent. Par exemple "?" ou bien "iti".
Faut-il que je lui envoie en UTF-8 aussi? Comment? Les CR / LF à la fin aussi en UTF-8?
Comme je l'ai expliqué dans l'article sur les chaines de caractères, les processeurs et donc les liaisons série ne savent pas ce qui transite sur leurs fils. Ils voient passer des bits, et donc des octets, rien d'autre. C'est celui qui écrit sur le bus, et celui qui lit qui interprètent. Le fait qu'il y ait des accents ou de la ponctuation n'intervient pas...
Comme la liaison série ne sait pas ce qu'elle transporte, il est tout à fait possible d'y passer des caractères accentués par exemple en utilisant une table ASCII étendu de code 850 qui regroupe presque la totalité des caractères francophones. En pratique, cela signifie envoyer un octet de valeur 130 pour un 'é', recevoir ce même 130 de l'autre côté et l'interpréter comme un 'é' ! Sur un clavier Windows Français, dans n'importe quelle application acceptant du texte, vous pouvez d'ailleurs presser la touche Alt et taper 130 sur le clavier numérique. Vous verrez apparaître ce fameux 'é'.
Tout ça pour dire que peu importe ce qui passe pour une liaison série, le moniteur de Arduino IDE devrait au moins afficher des caractères cabalistiques si quelque chose passait... Ce qui me fait penser que le problème vient plus certainement du protocole, voire de la liaison physique. Même si la vitesse est mauvaise, même si les paramètres de transmission ne sont pas bons, des 'trucs' devraient quand même passer. Attention aussi à l'usage de Serail.print() qui doit être suivi par un Serial.println() sinon rien ne sera affiché sur le moniteur !
323
Vos projets / Re : projet centrale wifi DCC++ Can
« le: mars 10, 2020, 03:16:58 pm »
Et puis cette centrale s'adresse à toutes les échelles, et dans les grandes échelles la tension peut monter à 20v...
324
Vos projets / Re : projet centrale wifi DCC++ Can
« le: mars 10, 2020, 10:03:39 am »
Parfait. Penser à juste pouvoir régler la fréquence du PWM pour s'adapter à divers types de moteur.
325
Vos projets / Re : projet centrale wifi DCC++ Can
« le: mars 10, 2020, 09:34:18 am »
J'aime beaucoup ce projet qui fait écho à mes multiples projets personnels, de DCCpp à DcDccNanoController en passant par les récents développements de DCCpp en ESP32.
Cette partie est à finaliser. En tenant de faire une version à diffuser, j'ai évidemment voulu re-tester, et bien sûr, rien ne marche... Donc ça va venir, mais peut être pas aussi vite que je l'aurais voulu.
Pour ce qui est du cahier des charges, je voudrais ajouter deux points:
- La centrale doit aussi être capable de faire de l'analogique sur du courant pulsé en PWM. Tous les utilisateurs de DCC ont sur leur étagères des vieilles locos issus de leur histoire ou de leur achats compulsifs qui ne sont pas -encore- digitalisées et qu'ils voudront malgré tout faire tourner. Il ne faut pas les oublier.
- Pour répondre à l'interrogation de Dominique au sujet de la capacité mémoire de l'ESP32, il faut savoir que la dépense mémoire est bien plus importante à programme équivalent sur un ESP que sur un Avr. C'est lié à l'architecture et aussi au fond de routines qu'il faut inclure à côté du programme utilisateur pour le faire tourner... Ça ne va clairement pas dans le bon sens ... Malgré tout, je pense que la limite ne sera pas atteinte avant longtemps: mon programme de test DCCpp ne prend que 25% de la mémoire. Et puis au pire, rien n'empêche d'avoir une architecture distribuée, avec un ESP8266 (moins cher...) qui gère les communications Bluetooth, Wifi, CAN et autres, et qui envoie via SPI/I2C/Serial les ordres reçus au DCCpp présent sur l'ESP32 ... Ça serai aussi certainement salvateur pour les timings DCC qui ne seraient plus perturbés par tout ce qu'il faut faire autour.
Cette partie est à finaliser. En tenant de faire une version à diffuser, j'ai évidemment voulu re-tester, et bien sûr, rien ne marche... Donc ça va venir, mais peut être pas aussi vite que je l'aurais voulu.
Pour ce qui est du cahier des charges, je voudrais ajouter deux points:
- La centrale doit aussi être capable de faire de l'analogique sur du courant pulsé en PWM. Tous les utilisateurs de DCC ont sur leur étagères des vieilles locos issus de leur histoire ou de leur achats compulsifs qui ne sont pas -encore- digitalisées et qu'ils voudront malgré tout faire tourner. Il ne faut pas les oublier.
- Pour répondre à l'interrogation de Dominique au sujet de la capacité mémoire de l'ESP32, il faut savoir que la dépense mémoire est bien plus importante à programme équivalent sur un ESP que sur un Avr. C'est lié à l'architecture et aussi au fond de routines qu'il faut inclure à côté du programme utilisateur pour le faire tourner... Ça ne va clairement pas dans le bon sens ... Malgré tout, je pense que la limite ne sera pas atteinte avant longtemps: mon programme de test DCCpp ne prend que 25% de la mémoire. Et puis au pire, rien n'empêche d'avoir une architecture distribuée, avec un ESP8266 (moins cher...) qui gère les communications Bluetooth, Wifi, CAN et autres, et qui envoie via SPI/I2C/Serial les ordres reçus au DCCpp présent sur l'ESP32 ... Ça serai aussi certainement salvateur pour les timings DCC qui ne seraient plus perturbés par tout ce qu'il faut faire autour.
326
Vos projets / Re : projet centrale wifi DCC++ Can
« le: mars 03, 2020, 11:25:16 am »
(Je remet mon message au bon endroit, je l'avais posté sur l'ancien fil...)
A mon avis, le format de cette messagerie n'a d'intérêt que par son aspect bas niveau qui permet de faire exactement ce que l'on veut en respectant la norme DCC au plus près, mais c'est rebutant si l'on cherche des commandes un peu plus simples.
Il y a deux gros nœuds gordiens à trancher dans tout ça:
Les registres : piloter une locomotive suppose de lui dédier un registre pour les ordres continus comme la vitesse, et éventuellement un autre pour les fonctions (c'est un choix si l'on veut éviter de perdre l'info après une grosse coupure d'alimentation...), mais connaître ou affecter en dynamique des registres selon les engins pilotés à l'instant T est relativement compliqué pour quelqu'un qui ne connait pas le fonctionnement de DCC++ et sa liste de registres limitée en taille.
Les fonctions : activer ou désactiver une fonction particulière relève du chemin de croix pour celui qui ne maîtrise pas le binaire sur le bout des doigts (je rappelle qu'il y a 10 catégories de gens, ceux qui comprennent le binaire et les autres...). Il faut différencier les messages selon les fonctions, se rappeler des fonctions actives ou non pour ne pas toucher aux autres en construisant ce message, et stocker tout ça pour chaque locomotive ou engin piloté...
J'ai pour projet à moyen terme d'ajouter à DCCpp un gestionnaire de locomotives qui permettra de définir au fur et à mesure quelles sont celles qui sont pilotées, avec leurs fonctions associées. C'est ce gestionnaire qui affectera les registres, et contiendra un exemplaire (une instance) pour chaque loco de la classe FunctionsState déjà présente dans DCCpp. Ce type d'architecture devrait permettre de définir une interface texte bien plus simple, du genre "L4 S=-60" qui signifierai 'met la loco 4 à 60 en sens inverse' ou "L3 F17=1" 'active la fonction 17 de la loco 3'... Je pense que la gestion de ces locos par un JMRI ou un 'throttle' s'en trouverai grandement facilitée.
Autre sujet: la version DCCpp qui marche sur ESP32 est réalisée et fonctionnelle. Elle n'est juste pas à disposition parce que j'ai voulu me lancer dans de grands chantiers avec du Wifi, du Bluetooth et un programme Android... Je vais revenir un peu en arrière et pousser la version ESP32 d'ici peu (tout est relatif, hein..), sans ces connecteurs sans fil.
Vraiment simple en effet comme messagerie! On peut la coder sur n’importe quel langage, même depuis un autre Arduino/esp voire pire, en php ou en basic
A mon avis, le format de cette messagerie n'a d'intérêt que par son aspect bas niveau qui permet de faire exactement ce que l'on veut en respectant la norme DCC au plus près, mais c'est rebutant si l'on cherche des commandes un peu plus simples.
Il y a deux gros nœuds gordiens à trancher dans tout ça:
Les registres : piloter une locomotive suppose de lui dédier un registre pour les ordres continus comme la vitesse, et éventuellement un autre pour les fonctions (c'est un choix si l'on veut éviter de perdre l'info après une grosse coupure d'alimentation...), mais connaître ou affecter en dynamique des registres selon les engins pilotés à l'instant T est relativement compliqué pour quelqu'un qui ne connait pas le fonctionnement de DCC++ et sa liste de registres limitée en taille.
Les fonctions : activer ou désactiver une fonction particulière relève du chemin de croix pour celui qui ne maîtrise pas le binaire sur le bout des doigts (je rappelle qu'il y a 10 catégories de gens, ceux qui comprennent le binaire et les autres...). Il faut différencier les messages selon les fonctions, se rappeler des fonctions actives ou non pour ne pas toucher aux autres en construisant ce message, et stocker tout ça pour chaque locomotive ou engin piloté...
J'ai pour projet à moyen terme d'ajouter à DCCpp un gestionnaire de locomotives qui permettra de définir au fur et à mesure quelles sont celles qui sont pilotées, avec leurs fonctions associées. C'est ce gestionnaire qui affectera les registres, et contiendra un exemplaire (une instance) pour chaque loco de la classe FunctionsState déjà présente dans DCCpp. Ce type d'architecture devrait permettre de définir une interface texte bien plus simple, du genre "L4 S=-60" qui signifierai 'met la loco 4 à 60 en sens inverse' ou "L3 F17=1" 'active la fonction 17 de la loco 3'... Je pense que la gestion de ces locos par un JMRI ou un 'throttle' s'en trouverai grandement facilitée.
Autre sujet: la version DCCpp qui marche sur ESP32 est réalisée et fonctionnelle. Elle n'est juste pas à disposition parce que j'ai voulu me lancer dans de grands chantiers avec du Wifi, du Bluetooth et un programme Android... Je vais revenir un peu en arrière et pousser la version ESP32 d'ici peu (tout est relatif, hein..), sans ces connecteurs sans fil.
327
Présentez vous ! / Re : Re : Enfin lancé, enfin inscrit !
« le: mars 03, 2020, 11:14:44 am »Vraiment simple en effet comme messagerie! On peut la coder sur n’importe quel langage, même depuis un autre Arduino/esp voire pire, en php ou en basic
A mon avis, le format de cette messagerie n'a d'intérêt que par son aspect bas niveau qui permet de faire exactement ce que l'on veut en respectant la norme DCC au plus près, mais c'est rebutant si l'on cherche des commandes un peu plus simples.
Il y a deux gros nœuds gordiens à trancher dans tout ça:
Les registres : piloter une locomotive suppose de lui dédier un registre pour les ordres continus comme la vitesse, et éventuellement un autre pour les fonctions (c'est un choix si l'on veut éviter de perdre l'info après une grosse coupure d'alimentation...), mais connaître ou affecter en dynamique des registres selon les engins pilotés à l'instant T est relativement compliqué pour quelqu'un qui ne connait pas le fonctionnement de DCC++ et sa liste de registres limitée en taille.
Les fonctions : activer ou désactiver une fonction particulière relève du chemin de croix pour celui qui ne maîtrise pas le binaire sur le bout des doigts (je rappelle qu'il y a 10 catégories de gens, ceux qui comprennent le binaire et les autres...). Il faut différencier les messages selon les fonctions, se rappeler des fonctions actives ou non pour ne pas toucher aux autres en construisant ce message, et stocker tout ça pour chaque locomotive ou engin piloté...
J'ai pour projet à moyen terme d'ajouter à DCCpp un gestionnaire de locomotives qui permettra de définir au fur et à mesure quelles sont celles qui sont pilotées, avec leurs fonctions associées. C'est ce gestionnaire qui affectera les registres, et contiendra un exemplaire (une instance) pour chaque loco de la classe FunctionsState déjà présente dans DCCpp. Ce type d'architecture devrait permettre de définir une interface texte bien plus simple, du genre "L4 S=-60" qui signifierai 'met la loco 4 à 60 en sens inverse' ou "L3 F17=1" 'active la fonction 17 de la loco 3'... Je pense que la gestion de ces locos par un JMRI ou un 'throttle' s'en trouverai grandement facilitée.
Autre sujet: la version DCCpp qui marche sur ESP32 est réalisée et fonctionnelle. Elle n'est juste pas à disposition parce que j'ai voulu me lancer dans de grands chantiers avec du Wifi, du Bluetooth et un programme Android... Je vais revenir un peu en arrière et pousser la version ESP32 d'ici peu (tout est relatif, hein..), sans ces connecteurs sans fil.
328
Présentez vous ! / Re : Enfin lancé, enfin inscrit !
« le: février 21, 2020, 09:56:23 am »
Juste pour éclaircir le débat, un SProg n'est ni plus ni moins qu'un microcontroleur dédié au DCC et à la programmation des décodeurs, et qui peut aussi servir de petite centrale. Ça ressemble furieusement à un Nano chargé de DCC++ ou DCCpp !!
329
Le logiciel DCC++ / Re : DCC++ Connecter à la BaseStation un contrôleur par liaison série directe (RX-TX)
« le: février 18, 2020, 09:17:07 am »
Pour 'spoiler' un peu la lecture de cet article conseillé par Dominique, il faut comprendre comme point de départ que DCCpp n'est pas un programme Arduino, c'est une bibliothèque. Le but a été de transformer DCC++ pour le faire passer d'un sketch Arduino complexe à un bibliothèque paramétrable depuis le fichier ino.
Donc une fois installé comme bibliothèque via le 'gestionnaire de bibliothèques' de l'IDE (tapez DCCpp en haut à droite...), il suffit de prendre l'un de ses exemples, comme SerialDCC effectivement, de vérifier que les bonnes habilitations ont été faites dans DCCpp.h (les #define USE_TEXTCOMMAND par exemple), de régler les broches à piloter dans le fichier ino et de compiler. Mais tout ça est expliqué en détail dans l'article et plus grossièrement dans la doc en anglais.
Donc une fois installé comme bibliothèque via le 'gestionnaire de bibliothèques' de l'IDE (tapez DCCpp en haut à droite...), il suffit de prendre l'un de ses exemples, comme SerialDCC effectivement, de vérifier que les bonnes habilitations ont été faites dans DCCpp.h (les #define USE_TEXTCOMMAND par exemple), de régler les broches à piloter dans le fichier ino et de compiler. Mais tout ça est expliqué en détail dans l'article et plus grossièrement dans la doc en anglais.
330
Présentez vous ! / Re : Marc, Débutant très motivé
« le: février 10, 2020, 04:58:53 pm »
Bonjour Marc, et bienvenue parmi nous.
Il ne faut pas hésiter à parcourir les articles du site éditorial à propos du DCC. Les articles sont nombreux et permettent de bien entrer dans le sujet.
Il ne faut pas hésiter à parcourir les articles du site éditorial à propos du DCC. Les articles sont nombreux et permettent de bien entrer dans le sujet.