Parlons Arduino > Vos projets
projet centrale "LaBox" wifi DCC++ Can
Dominique:
Un exemple d'interface can (uniquement le transceiver est nécessaire)
Les pins pour le Can sont GPIO5->CAN TX et GPIO16->CAN RX.
Le circuit SN65HVD232 (3.3V) est idéal mais le MCP2551 (avec adaptation 5v<->3,3v) est pas mal aussi (si je préfère une version traversante - non-CMS).
Thierry:
(Je remet mon message au bon endroit, je l'avais posté sur l'ancien fil...)
--- Citation de: Pyk35 le mars 01, 2020, 11:26:23 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 ;D
--- Fin de citation ---
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.
Dominique:
Voici un peu plus de détails de ce que j'ai en tête (et je m'entête >:()
Au départ il existe des applications gratuites sur smartphones : Withrottle (iOS) et Engine Driver (Android) sont des applications bien faites et assez simples Ce sont des postes de conduite pour le logiciel JMRI (jmri.org). Le but est de pouvoir utiliser les fonctionnalités les plus importantes, pour la commande directe de cette centrale.
Cahier des charges :
* connexion au serveur WiFi (ESP12 ou ESP32) en mode point d’accès (ne nécessite pas de box internet avec login et password, ce qui est plus pratique dans les expos).
* Choix des adresses des locos (courtes et longues selon NMRA) au clavier de Withrottle et mémorisé d’une fois sur l’autre.
* Possibilité de piloter 2 locos en même temps avec 1ou 2 smartphones
* La/les locos s’arrêtent automatiquement en cas d’appel téléphonique et lorsque l’application n’est plus en premier plan ou le smartphone mis en veille.
* Marche avant et arrière (avec passage par la vitesse 0)
* Fonctions des locos (Light et F1..F28) si supportées.
* Reconnaissance automatique de l’adresse DCC d’une loco posée seule sur les rails.
* Ecran Oled 4 lignes (petites) pour suivre le fonctionnement, et configurer quelque chose
* Interface Can pour agir sur les locos (ralentir, s'arrêter, repartir...) sous contrôle d'un bloc système ou d'un gestionnaire alimenté par une rétrosignalisation
* Réaliser une plateforme matérielle aussi simple et bon marché que possible permettant d'autres applications et possibilités par évolutions logicielles
* Une seule prise d'alimentation (un petit et un gros jack pour utiliser les alims qu'on a en stock)
Il y a déjà un certain nombre de choses faites (voire à refaire) :
* Le serveur Wifi (sur ESP8266) qui reçoit les commandes de Withrottle (ou Engine Driver qui est légèrement différent) et les transforme en commandes DCC++. Pour le moment je n'ai pas implémenté les commandes d'accessoires (ce serait possible avec les versions payantes des applications)
* Les communications I2C entre l'ESP et le Nano, ainsi que l'OLED
* L'adaptation de DCC++ pour prendre en compte les communications I2C
J'imagine un mini-gestionnaire de réseau embarqué s'occupant de la rétrosignalisation avec des satellites sur le Can : vers un réseau ultra simple et ouvert... mais pas facile a configurer !
A un moment j'ai ajouté un mode PWM, mais c'est dangereux car la tension d'alimentation du montage ne doit pas dépasser celle des locos présentes alors que le DCC nécessite une tension plus élevée (j'ai cramé une loco :'() et ça complique le matériel avec un régulateur de puissance supplémentaire.
Je vois que Thierry a aussi des idées donc ça va être interessant !
Qu'en pensez-vous ?
En particulier voyez-vous d'autres applications d'une plateforme de ce type ?
Pyk35:
Bonsoir,
On vous laisse une journée et vous avancez comme des fous!! ;D Bravo!
Je réagis donc :
* L’esp32 dispose de 3 UART donc on devrait arriver à dédier un UART pour le CAN, un pour la console et un pour une connexion directe USB. A contrôler en détail. Ça me peine un peu de voir le nano dans ce montage mais pourquoi pas.
* L’écran Oled, super idée. Résultat pro garantie.
* pour le double L298, pas de problème pour moi.
* Côté CAN, on pourrait embarquer un mode passerelle pour transmettre l’intégralité des trames selon les filtres retenus. On pourrait faire une page d’admin pour configurer la gateway can notamment pour donner les filtres. Un mode bridge CAN pourrait permettre de transmettre les infos venant CAN selon une messagerie au niveau selon les règles du gestionnaire intégré comme proposé.
* pour le gestionnaire CAN, il faudrait le déclarer sous forme json dans un fichier et ne pas chercher à le configurer en web. On ferait une page web pour un import/export de ce fichier json et chacun éditera son json dans un notepad++, json reste lisible.
* Pour la compatibilité avec les applications smartphone, ça serait un plus, peut-être en attendant de faire la notre ;). Je pensais que l’on pourrait stocker la configuration des locos dans l’esp ce qui permettrait à tous les smartphones de récupérer les locos de la console. C’est vrai que c’est le défaut de la multimauss de ROCO où il faut se palucher les locos dans chaque souris. Un stockage Json semble une bonne solution.
* côté wifi, que la centrale soit point d’accès, c’est très bien notamment en club ou expo par contre à la maison, ça serait gonflant car il faudrait quitter son wifi de la maison pour se connecter à la console et surtout, on perdrait la communication internet du smartphone. Il faudrait donc aussi pouvoir être client wifi.
++
Dominique:
Les ports Can sur ESP32 - VROOM32 (DEVKIT C entre autres) sont :
CanTx : GPIO5
CanRx : GPIO4
Ce ne sont pas des UART.
Ces ports sont gérés par un contrôleur Can interne du même type que le MCP2515 ou SJA 1000 décrit dans ce site. Il faut donc utiliser une bibliothèque Can conçue pour l’ESP 32 et ce contrôleur (il en existe plusieurs et voir les articles sur le site éditorial).
Ces 2 ports doivent être connectés à un transceiver Can externe comme le SN65HVD233 (en 3,3v).
Je n’ai pas encore testé le Can sur ESP32 mais ça ne saurait tarder :D
Navigation
[#] Page suivante
[*] Page précédente
Utiliser la version classique