Auteur Sujet: Nouveaux décodeurs!  (Lu 5099 fois)

laurentr

  • Hero Member
  • *****
  • Messages: 564
    • Voir le profil
Nouveaux décodeurs!
« le: avril 11, 2022, 08:28:58 pm »
Bonjour

Je travaille actuellement à la mise au point de nouveaux décodeurs embarques (fonction et moteur) pour nos modèles. ( y compris du N!)

Une grande partie est déjà bien avancée bien que des optimisations restent encore nécessaires. (les modules Labo permettront de finaliser prochainement certains tests avec les matériels adéquats)

Néanmoins devant la volatilité des disponibilités de composants une certaine portabilité est requise et déjà mise en œuvre!

On "oublie" le 328P/PB pour le moment bien qu'une version sous attiny-45-85  soit aussi au programme! (plus le 85!)

Actuellement 36 CPU sont (déjà) pleinement compatibles avec le code source de base tournant sur les familles AVR et ATTINY des séries 0,1 &2! Ce qui avec leurs brochages respectifs couvrira certaines indisponibilités et tailles de réalisations.

J'ai encore toutefois une gosse part à traiter et un petit coup de main sera naturellement bien venu pour boucler le tout!

Laurent



trimarco232

  • Sr. Member
  • ****
  • Messages: 267
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #1 le: avril 12, 2022, 02:24:32 pm »
Bonjour Laurent,
bon travail !
le portage de la biblio nmradcc ne doit plus poser trop de problèmes, depuis qui'ils utilisent la fonction micros pour la reconnaissance des bits dcc
je pense toutefois que cette méthode n'est pas assez avancée : elle convient bien pour les décodeurs fixes, mais pour les mobiles, on peut (peut-être) pondre quelque chose qui puisse un peu pallier une certaine mauvaise qualité du signal (sic)
en tous cas, à ta disposition, si je peux aider

JPM06

  • Newbie
  • *
  • Messages: 49
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #2 le: avril 12, 2022, 04:08:54 pm »
Bonjour Laurent,
Super. Peux-tu nous en dire plus sur ce projet? Y a-t-il un autre fil sur le sujet?
JP

laurentr

  • Hero Member
  • *****
  • Messages: 564
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #3 le: avril 12, 2022, 08:56:04 pm »
Bonsoir

Pour le moment il n'y a que ce fil pour en discuter, ce qui me semble centralisé et adapté.

Je finalise actuellement la partie LABO HARDWARE de ces nouveaux décodeurs.( hardware sur les séries de CPU ATMEL MICROCHIP séries AVR et ATTINY 0, 1 et 2)

Ci dessous un aperçu de l'un d'eux.

La partie code est finalisée à prêt de 90% (décodage signal DCC, pilotage des sorties pour fonctions, pilotage moteur via pont en H, ack, BEMF, compatibilité du mode analogique, etc.)

Utilisation de PLATEFORMIO sur VSCODE.

Pas d'utilisation de bibliothèque "standard" (dont la NMRA) coté DCC.  Sur la partie hard des librairies de SPENCE CONDE ( DXCORE) et MCUDude (MEGACOREX) sont utilisées mais avec un "fork" pour une compatibilité étendue. ( ca compile sans anomalie mais il faudra tester ensuite!)

Programmation des CPU via port UDPI puis modification des CV selon les modes usuels de lecture écriture.

Quelques ajustements sont encore requis sur des effets lumineux ( fading lampes, tubes néon, autres effets…) ( je pèche encore dessus!) et sur des optimisations hardware ( valeurs de composants et disponibilité, routage sur PCB finaux,...) ou intégrer éventuellement quelques idées novatrices aperçues ci où là (adresse de rame, de voiture,...)

De quoi bien s'occuper dans les semaines à venir.

Laurent




laurentr

  • Hero Member
  • *****
  • Messages: 564
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #4 le: avril 19, 2022, 08:35:40 pm »
Bonsoir

Reçus aujourd'hui une bonne partie des composants pour les nouveaux montages.

Les PCB sont en transit et seront la la semaine prochaine.

Encore un peu de patience donc pour tout assembler, tester, valider :)

Hâte d y être!

Laurent

laurentr

  • Hero Member
  • *****
  • Messages: 564
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #5 le: avril 21, 2022, 02:07:23 pm »
Bonjour

Commande passée le 11 et reçue ce jour! Rien à dire ça tourne bien de ce côté la!

La suite à présent va être fabuleuse! :)

Cela sera pour la semaine prochaine en revanche!

Ltr

laurentr

  • Hero Member
  • *****
  • Messages: 564
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #6 le: avril 21, 2022, 03:02:59 pm »
PCB à monter pour tests et validations...

Restera la partie H BRIDGE à traiter plus spécifiquement mais déjà au dessin pour des versions avancées...

Laurent

laurentr

  • Hero Member
  • *****
  • Messages: 564
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #7 le: avril 23, 2022, 06:07:24 pm »
Bonjour

Les montages ont’commence!

Un premier test très concluant a pu être fait!

C est donc en bonne voie!

Rm: les moyens mobilisés sont aussi plus important mais quand le résultat est la!…

Programmation des cpu via ATMEL-ICE EN UDPI
Succès avec un code blink sur un ATTINY1606 Monte sur son support

Prochaines étapes: monter un labo 2 complet et passer à la suite des tests

Router un « labo 3 » déjà dessiné et dédié aux ponts en H à composants discrets et intègres avec différents composants ( taille, brochage , … dispo…!)

Passionnant je vous dits! Passionnant!!

Laurent

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #8 le: avril 24, 2022, 02:25:45 pm »
Bravo Laurent,

Hâte de voir ce que ça donne  ;)

Cordialement,
Dominique

laurentr

  • Hero Member
  • *****
  • Messages: 564
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #9 le: avril 26, 2022, 02:45:28 pm »
Bonjour Dominique

Je vais te faire saliver un peu, un décodeur avec pilotage moteur et 6 sorties de fonctions en 10mmx30mm complètement compatible avec du N je pense déjà routé ;)

Mais pas de connecteur conventionnel dessus ... cependant pour intégrer à des PCB générique d engins (moteur) ca doit être bien faisable :)

Encore du travail d ici a pouvoir présente quelques chose d'assez abouti...

Laurent

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #10 le: avril 28, 2022, 11:20:43 am »
Ca devrait intéresser des constructeurs d'engins
Cordialement,
Dominique

laurentr

  • Hero Member
  • *****
  • Messages: 564
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #11 le: mai 04, 2022, 11:00:12 pm »
Bonsoir

Mes premiers tests sont extrêmement concluant.

Pour l’heure je dispose d une solution transposable sur 14 modèles de cpu et toutes leur déclinaisons de brochage. D autre cpu requièrent quelques ajustement sur l’encode source du fait des évolutions introduites dans les générations de composants.

La commande des fonctions F0 a F28 est pleinement opérationnelle en pilotant 8 sorties.
Plusieurs effets lumineux sont présents. ( fading, néon( mànque encore de pêche à mon goût dans la gestion des flashs,…)
Les fonctions railcom doivent encore être testées ainsi que les patries propres à la lecture écriture des cv jusque là juste survolées mais fonctionnelles.

Quelques innovations seront encore dévoilées prochainement. Celles si sont encore totalement indedites sur un décodeur DIY.

Le pilotage moteur est à tester intensément et avec des combinaisons de composants variées ainsi que les réglages PID pour la BEMF. Cela passera par la finalisation de la plaque LABO3.

Je dois encore regarder comment transformer mon modèle gérant 8 sorties de fonctions, un pilotage moteur avec mesure de la BEMF, l’émission railcom , le respect des plages d adresse normalisées vers un modèle dépourvu des certaines parties au profit de plus de sorties de fonctions

Un énorme travail cependant qui mobilise avec les autres travaux en cours de partage sur ce même forum beaucoup d energie!

Tout aide sera appréciée à sa juste valeur :)!


Laurent

 



bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 904
  • HO avec DCC++
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #12 le: mai 05, 2022, 12:34:48 am »
Quel type d'aide ? Si c'est pour partager l'apéro, ça je sais faire !

laurentr

  • Hero Member
  • *****
  • Messages: 564
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #13 le: mai 05, 2022, 12:25:47 pm »
Salut Christophe

Si pour toi l apéro c est écrire du code qui sera utilisé ensuite...  ;)

Ce devrait le faire!

Plus précisément je sais décrie les processus que je veux mettre en œuvre mais l écriture du code correspondant me pèse pas mal car c e n est pas du tout mon domaine...
Je cherche donc "un champion" en la matière!...

Ltr


laurentr

  • Hero Member
  • *****
  • Messages: 564
    • Voir le profil
Re : Nouveaux décodeurs!
« Réponse #14 le: septembre 28, 2022, 12:28:07 am »
Bonsoir

Je reprends un peu me travaux avec le retour des jours de pluie et les quelques progrès que j'ai pu faire depuis quelques temps.

Pour ceux qui ne connaissent pas cette très bonne bibliothèque pour traiter le signal DCC voici le lien qu'il vous faut:

https://github.com/aikopras

Plus spécifiquement la libraire
https://github.com/aikopras/AP_DCC_library

et le projet de décodeur:
https://github.com/aikopras/AP_DCC_Decoder_Core

Intéressons nous aussi a ce dont nous avons besoin "bloc par bloc".

Le décodage du signal DCC est confié à la librairie d AIKO PRA.: transcodage signal-instructions, écriture, lecture CV.

Il nous faut compléter notre base avec idéalement:
 une classe "LED" pour gérer nos effets lumineux
 pour une decodeur de loco en sus il faut
 une classe "MOTOR" pour traiter la partie pilotage moteur

 Afin de gérer la PWM SOFTWARE sur les sorties utilisée des CPU nous devons faire un travail de codage.

Comme nous voulons pouvoir utiliser n'importe quelle sortie du CPU pour gérer du PWM nous devons avoir recours a du "bit banging" et ne pas nous reposer uniquement sur les seules sorties capable de générer du PWM HARDWARE.

Cela peut entre autre reposer sur l'utilisation de solution pré packagées.

Par exemple celles de KHOI HUANG et de ses nombreuses librairies:

https://github.com/khoih-prog

principalement celle gérant les TIMER_ INTERRUPT et les SLOW_PWM pour différents CPU bien connus. ( AVR séries 0 1 2, ATMEGA, ATTINY série 0 1 2, ...) peuvent être d'une grande utilité.

Néanmoins je m'interroge sur la structuration et l'articulation de certaines des briques pour y parvenir.

Concentrons nous sur un décodeur de fonction embarqué pour gérer des éclairages dans une voiture voyageur.

Notre "PROGRAMME CORE" ( sur le TIMER B0 par défaut) traite le signal DCC, nous actualisons des variables dont les états sont ensuite consommés par la classe LED qui gère les différents types d'effets lumineux (ON/OFF, FADE, NEON START,...)
A défaut un "digitalWrite" sur la sortie à piloter donnera un résultat immédiat. La classe LED enrichie cette base de fonctionnement.

Jusque la nous allumons et éteignons nos leds en tout ou rien avec le "digitalWrite"

Pour produire des effets lumineux on va alors rafraichir périodiquement un état HAUT puis BAS sur une broche ce qui constitue un "PWM SOFTWARE" (autrement appelé bit banging").
Nous pouvons ainsi gérer visuellement une intensité lumineuse donnée à nos leds.

Le recours à une programmation objet et la definition d une classe "LED" facilite la mise en oeuvre.

Je pense utile de dédier un autre TIMER de type B ( par exemple le B1) pour les calculs d'actualisation de ces variables pour générer ensuite le PWM.

J'envisage de faire appel à la librairie de KHOI TimerInterrupt du type de processeur à utiliser coté HARDWARE pour générer une interruption à intervalle de temps régulier (ex 20 millisecondes). durant cette étape les valeurs de pilotage du PWM sont actualisées ( le LEVEL qui indique l intensité lumineuse attendue en sortie).

On a alors plus qu'a consommer un "LEVEL" à transformer en PWM SOFT.

La question que je me pose est de savoir si le PWM est géré dans le "handler" (que l on appelle dans la loop principale du programme  ou non? Les paramètres de LEVEL sont rafraichis par les valeurs poussées post interruptions dans des variables qui actualisent l'état des sorties )
Comme on peut le voir dans les exemples qui sont fournis pour illustrer les utilisations de ces librairies et donc m'assurer que l'on tourne sur le TIMER hard sélectionné ou bien s il faut revenir sur le "PROGRAMME CORE" et donc le timer B0 initial. ( qui a en charge le traitement du DCC rappelons le)

Formuler autrement cela revient à identifier:
qui porte la charge de la génération du PWM soft ( exclusivement le trimer B1?) ou la boucle du programme principale dans une fonction qui y est placée (qui tourne avec le TIMER B0.)

mon approche est elle correcte? J ai encore un petit peu de mal à mesurer la pertinence/validité de cette structuration.
Est ce bien l'optimal à mettre en œuvre ainsi?

Pour illustrer le BIT BANGING voici l exemple de code utilisable:
_TMP_PWM_LVL est la valeur calculée de l intensité lumineuse, rafraichie par lors des ISR, et dont la valeur va de 0 à 100 ( ce qui correspond au niveau de PWM à générer)

turn_on() et turn_off() pilotent directement le port de sortie de la pin concernée (mais à titre de demo un digitalWrite ou digitalfastwrite peut y etre substitué.*)
(*: par efficacité et optimisation des timings d'exécution la commande native du port est préférée)
pwminterval est la fréquence avec laquelle nous allons travailler. Disons 50hz ce qui devrait réduire assez bien le scintillement.
invert est la pour indiquer si le montage est a anode ou cathode commune pour le driving des leds.

noter que de manière autonome ce code (complété dans son environnement fonctionne très bien et produit le résultat attendu.

Maintenant où le placer idéalement:

dans une fonction et appeler celle ci dans la boucle principale?  avec le timer B1 et l ISR comme "handler"...?



// Below the code for PWM:
uint32_t PWM_Interval = micros() - last_pwm_time;       

///brightnessLevel = _TMP_PWM_LVL;

if(_TMP_PWM_LVL > 0 && _TMP_PWM_LVL < 100)   
{
pwmOnTime = pwmInterval / 100 * _TMP_PWM_LVL;
pwmOffTime = pwmInterval - pwmOnTime;

if (OutIsOn)
{
if (PWM_Interval > pwmOnTime)
{       
// pwmOnTime is over: LED has been on long enough
last_pwm_time = micros();
if (_invert)
{
turn_on();
}
else
{
turn_off();
}
OutIsOn = false;
}
}
else
{
if (PWM_Interval > pwmOffTime)
{     
// pwmOffTime is over: LED has been off long enough
last_pwm_time = micros();
if(_invert)
{
turn_off();
}
else
{
turn_on();
}
OutIsOn = true;
}
}
}

if (_TMP_PWM_LVL == 100)
{
if(_invert)
{
turn_off();
}
else
{
turn_on();   
}
}

if (_TMP_PWM_LVL == 0)
{
if (_invert)
{
turn_on();
}
else
{
turn_off();
}
}