Enfin lancé, enfin inscrit !

[sajuuk]

Bonjour à tous !

En quelques mots : Romain, fan de train après mon père, et mon grand père.
Aujourd'hui, je lance mon premier projet train à moi, et j'en profite pour m'inscrire ici après des années (et des années) de lecture attentive.

Je vais déjà faire mon mauvais élève : je ne souhaite pas baser mon projet sur un arduino, mais sur un Raspberry Pi.
Pourquoi ? Parce qu'un arduino sous DCC++ (ou autre) a besoin d'un ordi pour fonctionner.
Or, un RPi est un ordi, avec un arduino intégré 
Mon côté tatillon a eu raison de ma raison : ça m'oblige recréer cooooooomplètement un logiciel pour émettre du DCC directement depuis le Raspberry, sans intermédiaire.

S'il y en a que ça intéresse, je pourrai parler de ce projet de centrale 2 en 1 sur un fil.
En attendant, le reste est très proche du fonctionnement lu sur locoduino, d'où ma présence 

A bientôt !

[Tony04]

Pourquoi ? Parce qu'un arduino sous DCC++ (ou autre) a besoin d'un ordi pour fonctionner.

Pourquoi l'Arduino a-t-il besoin d'un ordinateur pour fonctionner ?
Par contre le gros soucis du RPi est son temps de démarrage, je pense que tu vas vite le découvrir.

Qu'en pense la communauté ?

Antoine

[sajuuk]

Je complète ma phrase : j'ai un peu pris des goûts de luxe, j'aime bien mon interface graphique sur un écran d'ordinateur, avec clavier et souris.
Jusqu'à présent, je n'ai vu que des configurations PC + Arduino pour ce résultat.
J'avais envie de regrouper tout ça.

Quant au temps de démarrage, je l'ai accepté d'entrée en choisissant d'utiliser un ordinateur et non une simple centrale 

[msport]

Une lecture rapide du site pendant quelques mois m'a permis de constater qu'un arduino en solo peut gérer des manettes, des boosters, des centrales autonomes, des TCO, des décodeurs, des sniffers, etc et cela avec DCC.
Pourquoi remplacer un ordi par un Raspberry, avec le plaisir de se palucher du Linux ... Les problèmes de Windows me suffisent.
Mais plutôt qu'un projet, nous aimerions voir une (des) réalisation(s).
Certes un Raspberry peut faire tourner JMRI à la place d'un PC (et ça été évoqué ici, pour autant faut-il réinventer DCC++ avec le lot de bugs qui ira avec ?

[sajuuk]

Oui, un arduino peut faire ça. Je ne l'ai pas découvert ici.
Mais les greffer sur DCC++, pour moi c'est impossible. Je n'y connais rien en C/C++, alors hors de question de modifier DCC++.

L'avantage que je retiens d'un raspberry, c'est de pouvoir le coder avec autre chose, en l'espèce le java, que je connais. En quelques jours j'ai réussi à créer un train DCC complet.
Et non, JMRI ne fait pas d'envoi direct depuis un raspberry.

[fcot2002]

Bonjour

mes collègues l'on dit, et je rajoute (même i je ne vois pas l'utilité de "regrouper")

moi je fonctionne avec une centrale DCC++ arduino, un JMRI sur un bel écran, et au milieu de tout ça un beau RPi 3B+

What else ?...

au pire tu regroupes les cartes dans une même boîte.......

[Jean-Luc]

Bonjour,

Générer un signal DCC avec du soft tournant sous Linux sachant que les instants de changement d'état du signal doivent être précis à +/- 3µs n'est pas possible. Les intervalles de temps d'appel de l'ordonnanceur varient, d'après ce que j'ai trouvé, 750µs et 6000µs.

Faut oublier, c'est pas fait pour du temps réel.

Sans parler de Java 

[sajuuk]

Pour répondre dans l'ordre :
Fcot 2002 : c'est vrai, j'aurais pu utiliser la version clé en main JMRI +arduino, ça m'aurait pris 5 minutes ...
M'en sentant capable et aimant coder, je me suis lancé.
Alors oui j'ai fait un choix difficile, mais j'avais envie.

Jean-Luc :
Ces temps sont hors de propos : le créneau est généré par le PWM du rpi. J'ai quand même vérifié avant de me lancer, puis sur oscillo, j'ai vu des créneaux parfaitement réguliers, y compris avec une période de 116microsecondes 
Donc le langage java ... Fait parfaitement l'affaire, et accessoirement, c'est le seul que je connaisse

[Jean-Luc]

Ces temps sont hors de propos : le créneau est généré par le PWM du rpi. J'ai quand même vérifié avant de me lancer, puis sur oscillo, j'ai vu des créneaux parfaitement réguliers, y compris avec une période de 116microsecondes 
Donc le langage java ... Fait parfaitement l'affaire, et accessoirement, c'est le seul que je connaisse

Ok, tu as réglé une PWM avec un temps de cycle de 116 µs, c'est le hardware qui fait le boulot.

Mais as tu noté que dans DCC++ il y a une interruption à chaque cycle de la PWM, c'est à dire toutes 116µs pour une rafale de bits à 1. La routine d'interruption reprogramme la PWM, TOP et OCR selon la valeur du prochaine bit et elle a 58 µs pour le faire.

Il faut donc garantir sous Linux qu'il s'écoule moins de 58 µs entre l'interruption du timer et la fin de la reprogrammation, passage dans le noyau, réordonnancement (si il veut bien donner la main à ton process) et changement de contexte compris.

Je te souhaite bon courage 

[sajuuk]

J'avoue que j'ai un peu triché : la seule bibliothèque que j'ai trouvée qui gère le PWM en java, c'est une bibliothèque en C wrappée en java ...
Je me suis arrangé pour que le bloc qui émet un train de donnée n'utilise que les méthodes issues du C.

Après, je ne comprends toujours pas le problème avec l'ordonnanceur : toute la constitution du train de données est dans le même thread :
Pour l'instant, tout est dans le même, mais à terme, je compte lui dédier un thread, pour exploiter le processeur multi coeurs.
Pour le reste, java n'est pas vraiment plus lent à exécuter que du C/C++, ce n'est pas du python 

Mais c'est une bonne remarque, je testerai à l'oscillo les successions de bits.

[msport]

Bonjour,
je crains que ce projet ne s'enferme dans une architecture à l'américaine (type console) :
La force de DCC++ est d'avoir clairement séparé la partie élaboration des commandes (manettes, TCO, etc) de la partie puissance (base station / booster).
Ce qui permet une totale liberté d'extension et de sources de pilotage.
On constate sur ce forum que l'époque de la bibliothèque CmdrArduino qui centralisait tout est terminée.
Et pour le programmeur lambda que je suis, qui admire bouche bée les grandes envolées de la programmation objet (mais qui n'y consacre pas toutes ses nuits), le DCC++ avec l'arduino me permet de réaliser les projets qui m'intéressent avec un minimum d'efforts et d'investissements.

Je constate par ailleurs que les réfractaires à Linux pourront trouver leur bonheur avec Windows ioT sur Raspberry :
https://www.clubic.com/raspberry-pi/article-853247-1-windows-iot-core-raspberry-pi.html

Mais toute créativité doit pouvoir s'exprimer, et Locoduino est l'endroit idéal pour qu'elle s'exerce dans le modélisme ferroviaire.

Bon, je retourne à mes ATTiny ...

[sajuuk]

C'est tout à fait vrai, mais cette fois le problème vient de moi :
Je ne connais ni le langage arduino, ni le C ou C++. Donc pas possible d'étendre un système existant ...
Second problème, je n'y connais rien non plus en communication entre deux programmes. Si je fais un programme TCO, puis un programme de gestion du DCC, je ne saurais pas les faire communiquer, même s'ils tournent sur le même ordi.

Après, mon gestionnaire actuel de paquets DCC est simplet, il ne devrait pas y avoir besoin de revenir dessus trop souvent.
J'ai séparé mon programme en trois grandes parties :
- une interface graphique, pour commander l'ensemble,
- un traducteur, qui interprète les actions de l'utilisateur pour les convertir en 0 et en 1,
- un gestionnaire de GPIO, qui envoie les 0 et 1 sur les broches PWM.

Je trouve que ça enlève des intermédiaires par rapport à ce qui se fait avec DCC++ : Il nécessite un ordinateur séparé, incluant un traducteur vers des commandes textes, pour commander l'arduino qui traduit à nouveau ce texte en signal DCC.

Peut-être qu'effectivement je me retrouverai bloqué à un moment où à un autre. Mais bon, j'avais envie de coder, au moins un prototype 
Rien ne m'empêchera de racheter un arduino plus tard pour passer sur JMRI + DCC++ 

[Pierre59]

Bonjour

Pour produire le signal DCC j'ai utilisé, et j'utilise encore, un boitier "Sprog" connecté à l'ordinateur, ou à un mini-ordinateur, en USB. J'ai un bout de programme en Java qui fabrique les trames DCC et les envoie au Sprog.

Pierre

[sajuuk]

Merci beaucoup, je ne connaissais pas le SPROG.
Je vais regarder comment ça marche 

[Thierry]

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 !!