RailCom: Générateur de CutOut avec booster

[laurentr]

Bonjour

J'arrive un peu après la bataille... désolé

Toutefois je vous présente le "petit dernier".

BOOSTER RAILCOM(Able) avec toute la circuiterie qui va autours! Elle est ici très réduite du fit des apports des composants natifs du CPU. (Events, CCL, AC, Timer B, ...)

Le cœur est un CPU à 32 broches AVR type ATmega 4808 (celui du Nanoevery) ou un AVR Dx ( idéalement les DB et DD).

(On peut avec certains TINY de la série 2 arriver à quelque chose de très similaire, sinon il faut re ajouter des composants externes)

Le hard  reprend les signaux DCC d une centrale n'émettant pas de CUTOUT sur sa sortie signal. Entrée sur les plots C D E normalisés.
La conversion de puissance est confiée à un L6203
La protection est fixé à 4A
Alim DC DC locale pour alimenter le montage depuis l'entrée puissance.
De nombreuses leds sont ici présentes pour faciliter le décodage/troubleshooting des I/O.

J'ai passé un peu de temps à sélectionner les répartitions des pins au mieux de capacités/restrictions des CPU 32 broches.
L idée était d utiliser le plus possible tous leurs composants internes pour piloter l'ensemble du montage.

Fortement inspiré des montages BOOSTER CDE de PACO et du DCC BOSTER d'OPEN DCC est ici une évolution vers un CPU plus contemporain.

Que du classique...

Cote code je pars de la librairie d'AIKO PRAS ( AP DCC LIBRARY) qui doit être complétée pour ce montage.
Comme elle permet lors de l'assemblage d'identifier le bit 1 de fin de trame on sait alors partir de ce point pour générer le cutout et piloter les différents I/O.

A noter que le composant COMPARATEUR AC0 est utilisé pour la protection et que son déclanchement coupera le fonctionnement du montage ( AC0 OUT est mixé dans les CCL LUT dont es tables de vérités sont adaptées)

Ltr

[laurentr]

Bonjour

Quelques compléments également sur la proposition que j'ai dessinée:
C'est bien un BOOSTER à part entière. Compatible avec les entrées CDE. (j'ignore juste le "level" de ces signaux (5V?,16V?)
Il reçoit en entrée un signal DCC "pure" sans CUTOUT qu'il va ou non générer (configuration via CV)

On peut aussi par CV lui préciser le nombre de bits de préambule. à utiliser.

Ce montage reprend plusieurs recommandations importantes:
1//Opto isolation entre l'entrée et l'étage d'amplification/sortie

2//Il dispose d une liaison inter BOOSTER qui est une "masse commune". ( un "0" commun pour aligner les mesures des tensions sur une même base: on compte les étages à partir du même référentiel "0" comme avec l'altitude avec le niveau de la mer) ce qui permet de mettre plusieurs boosters sur un même réseau si nécessaire.( en parallèle sur des sections indépendantes: coupure des 2 rails entres sections)

3//Il intègre aussi les recommandations de "security gap" qu'indique le site OPEN DCC dans le pilotage du pont H:
https://www.opendcc.de/info/railcom/railcom_f.shtml

Ceci sécurise notamment en cas de passage d'un booster vers un autre ce que pour le moment n'est pas repris (encore) dans le montage de lebelge2 ni LABOX.

J ai pris par principe que le pole C porte la "phase" du signal et traite la sortie J du booster via le IN1 du pont, respectivement le plot D traite le signal K via le IN2 du pont du L6203.
Il serait très simple de permuter logiciellement le cas par les tables de vérités de CCL LUT du CPU qui sont utilisés ici.

Par ailleurs les entrées provenant des signaux C et D passent par une unité CCL LUT sur une porte XOR ce qui filtre le porteur avant injection vers le TIMER B et les autres CCL LUT
Ainsi tous les consommateurs des signaux C & D appliqueront le même traitement vers les mêmes sorties.

Ma recommandation est de n'utiliser (pour la traction à minima) que des boosters identiques et de laisser la sortie de la centrale sans usage ou aux seuls accessoires si elle est suffisante pour l'ensemble du réseau.

On peut sur une version "labox remaniée" mettre les sorties qui alimentent le pont H à destination des "inputs" des boosters externes (plots CDE) sinon je ne vois pas comment celle ci gèrera le cas de multiple boosters ( sauf à en interdire en usage?)

Le hardware reprend notamment:
A//le filtre sur la sortie du pont (BOOSTER OPEN DCC)
B//Entrées CDE
C//indicateurs (leds) visuels des états des principaux I/O
D//une réserve locale d'énergie (condensateurs en entrée du montage)
E//un convertisseur DC-DC local (max 600mA)

Des pistes de compléments:
// i) régulateur de tension de sortie (via PWM sur un MOS en entrée de montage)
// ii) sélection ( via dip switchs) de seuils multiples pour déclanchement de la protection (ici calée au max = 4A)
// iii)une interface CAN nécessite d'utiliser des CPUs à 48 broches type AVR DB ou ATMEGA4809  pour libérer un port SPI (ici le SPI0 alors sur le port E - PE0 à PE3) afin d ajouter un transceiver CAN, possible donc mais pas immédiat.

Ltr

[laurentr]

Bonjour

Nous avons collectivement discuté des apports de RAILCOM.
Les récents projets exposés par Christophe et Marcel notamment avec l'identificateur RAILCOM ou les satellites autonomes de Christophe nous apporte une plus value importante à l'utilisation de cette technologie.

Toutefois LA BOX Locoduino comme d'autres centrales n'est nativement pas capable de générer "correctement" le "cutout" railcom.

De quoi est il question: c est la fenêtre de temps durant laquelle la transmission des informations du décodeur vers la centrale est permise par interruption des émissions de trames DCC de la centrale vers les consommateurs (décodeurs de locos...)

Aussi plusieurs solutions ont été évoquées.
Parmi celles ci figure l'utilisation de BOOSTER DCC offrant la capacité de générer le CUTOUT.

Pour cela il y a comme toujours les solutions commerciales et celles auxquelles nous sommes attachées en DIY (esprit Locoduino!)

Dans les solutions en DIY citons celles les plus connues que sont:
A//le BOOSTER CDE de PACO CANADA (technologie PIC)
https://usuaris.tinet.cat/fmco/railcom_en.html#booster

B//le BOOSTER OPEN DCC ( ATTINY2313):
https://www.opendcc.de/french/Amplification/booster2_f.shtml

Les sites présentant ces réalisations décrivent les mécanismes et préconisent aussi des "optimums" (gap de sécurité par exemple en cas de boosters multiples)

Ayant moi même réalisé des montages du BOOSTER de PACO je voulais aussi m'approprié une solution plus contemporaine à base d'AVR/ATTINY inspirée aussi de la réalisation d'OPEN DCC que je juge plus complète.

Pour cela il fallait comprendre les mécanismes, chercher & trouver des réponses, optimiser le tout.

Plusieurs pistes étaient possibles.

J'ai retenu l'option de réduire le nombre total de composants à implanter et de bénéficier du même coup des apports des CPU de type AVR récents.
Ceux ci sont particulièrement bien adaptés à l'usage visé.

Inspiré de la partie HARD du BOOSTER OPEN DCC je suis finalement arrivé sur l'utilisation des AVR 32 broches de type AVR4808 ( AVRx série 0, celle du NANOEVERY) , AVR Dx ( DA DB DD,...) ( AVRx série 1) qui offrent sans fioriture ce dont nous avons besoins:
1//des TIMERS de type B
2//des CCL "GLUE LOGIC" configurables (assimilable à des portes logiques "sur mesure")
3//la possibilité de liaisonner les éléments via "EVENT"
4//un comparateur (pour la gestion de seuil en cas de cout circuit)

Ces CPU étant compatibles avec ces données en entrée la seconde étape a été de chercher le MAPINGS des différents I/O à placer pour correspondre à la couverture des besoins.

Plusieurs essais ont été requis pour arriver à une solution transposable sur plusieurs CPU: ATMEGA4808, AVDxxDA32, AVRxxDB32, AVRxxDD32
Leurs fonctionnements internes étant très similaires seul diffèrent quelques éléments "cosmétiques" de paramétrages.

Les librairies MEGACOREX ( AVR4808) et DXCORE ( AVR Dx) sont mises à contribution et facilitent la mise en œuvre du code.

L'utilisation de ATMEL START m'a beaucoup aidé pour visualiser les interactions entre les éléments et trouver une combinaison avec l'ensemble des besoins et contraintes à couvrir.

Des lors il restait à vérifier la couverture et dessiner ensuite.
Le code étant dans un second temps l'étape complémentaire à assurer.

Il est encore possible d'utiliser certaines ressources non encore utilisées sur ces CPU.
Parmi les piste possibles en réflexion:
i//gestion de la tension de sortie DCC sur les plots J/K via ajustement du niveau de PWM en entrée.(configuration par CV) via la broche PF4
i//gestion de seuils de déclanchement de protection différenciés (sélection mécanique par DIP SWITCH)

Voila les bases posées.
Ltr

[laurentr]

Les mêmes "config" sous AVR Dx.

Ici un AVR DB (un peu plus doté que le l AVR DD qui tient plus lui de l'ATMEGA4808 question ressources hardware)

[laurentr]

Voici a quoi va ressembler la partie d initialisation des I/O utilisés par la circuiterie interne avec la confiuration ad hoc pour piloter le BOOSTER.

On va inclure ceci:

Code: [Sélectionner]


#include <Event.h>
#include <Logic.h>
#include <Comparator.h>


Puis en exploiter les éléments

Code: [Sélectionner]

noInterrupts();

  //define COMPARATOR IN/OUT
  #if defined(__AVR_DA__) || defined(__AVR_DB__)      //use COMPARATOR 0 (AC0)
    Comparator0.input_p = comparator::in_p::in3;      // Use positive input 3 PIN_PD6
    Comparator0.input_n = comparator::in_n::in2;      // Use negative input 2 PIN_PD7
    Comparator0.hysteresis = comparator::hyst::disable;
    Comparator0.reference = comparator::ref::disable;
    Comparator0.output = comparator::out::disable_invert; // No output pin, signal inverted internally;

    // Initialize comparator
    Comparator0.init();

    // Start comparator
    Comparator0.start();
 
  #endif

  #if defined(__AVR__DD__) //default comparator value = AC0

    Comparator.input_p = comparator::in_p::in3;      // Use positive input 3 PIN_PD6
    Comparator.input_n = comparator::in_n::in2;      // Use negative input 2 PIN_PD7
    Comparator.hysteresis = comparator::hyst::disable;
    Comparator.reference = comparator::ref::disable;
    Comparator.output = comparator::out::disable_invert; // No output pin, signal inverted internally;

    // Initialize comparator
    Comparator.init();

    // Start comparator
    Comparator.start();

  #endif

  #if defined(__AVR_ATmegax08__) || defined(__AVR_ATmegax09__) //default comparator value = AC0
    Comparator.input_p = comparator::in_p::in2;      // Use positive input 2 PIN_PD6
    Comparator.input_n = comparator::in_n::in2;      // Use negative input 2 PIN_PD7 
    Comparator.hysteresis = comparator::hyst::disable;
    Comparator.reference = comparator::ref::disable;
    Comparator.output = comparator::out::disable_invert; // No output pin, signal inverted internally;

    // Initialize comparator
    Comparator.init();

    // Start comparator
    Comparator.start();

  #endif 
 
 
  //DEFINE CCL LUT0: 
  Logic0.enable = true;                       //ACTIV LUT0
  Logic0.input0 = logic::in::ac;       //AC0 OUT
  Logic0.input1 = logic::in::pin;      //PIN_PA1
  Logic0.input2 = logic::in::masked;   //NOT USED
  Logic0.output = logic::out::enable;  //PIN_PA3
  Logic0.truth = 0x04;                 // Set truth table

  Logic0.init();


  //Event1.assign_generator_pin(gen1::pin_pa7); //PIN_PA7 as input //ERROR
  Event1.set_generator(PIN_PA7); //BETTER
  Event1.set_user(user::ccl1_event_b);        //user
  Event1.set_user(user::ccl3_event_b);        //user too
  Event1.start();                             //start event channel1

  //DEFINE CCL LUT1:
  Logic1.enable = true;                 //ACTIV LUT1
  Logic1.input0 = logic::in::ac;      //AC0 OUT
  Logic1.input1 = logic::in::event_a; //event_a
  Logic1.input2 = logic::in::event_b; //event_b
  Logic1.output = logic::out::enable; //PIN_PC3
  Logic1.truth = 0xc1;                // Set truth table

  Logic1.init();

  //DEFINE CCL LUT2:
  Logic2.enable = true;                 //ACTIV LUT2
  Logic2.input0 = logic::in::ac;        //AC0 OUT
  Logic2.input1 = logic::in::pin;       //PIN_PD1
  Logic2.input2 = logic::in::pin;       //PIN_PD2
  Logic2.output = logic::out::disable;  //NO OUTPUT DIRECTLY SO USE EVENT CHANNEL 0 INSTEAD
  Logic2.truth = 0x04;                  //Set truth table

  Logic2.init();

  Event0.set_generator(gen::ccl2_out);

  #if defined(DCC_USES_TIMERB0)
    Event0.set_user(user::tcb0_capt); //route to TCB0
  #elif defined(DCC_USES_TIMERB1)
    Event0.set_user(user::tcb1_capt); //route to TCB1
  #elif defined(DCC_USES_TIMERB2)
    Event0.set_user(user::tcb2_capt); //route to TCB2
  #elif defined(DCC_USES_TIMERB3)
    Event0.set_user(user::tcb3_capt); //route to TCB3
  #else
    Event0.set_user(user::tcb0_capt); //route to TCB0 by default
  #endif


  Logic3.enable = true;                //ACTIV LUT2
  Logic3.input0 = logic::in::ac;       //AC0 OUT
  Logic3.input1 = logic::in::event_a;  //event_a
  Logic3.input2 = logic::in::event_b;  //event_b
  Logic3.output = logic::out::disable; //NO OUTPUT DIRECTLY SO USE EVENT CHANNEL 2 INSTEAD TO ROUTE TO PIN_PF2
  Logic3.truth = 0xc4;                 //Set truth table

  Logic3.init();

  Event2.set_generator(gen::ccl3_out);
  Event2.set_user_pin(PIN_PC2);
 
  Event2.start();


  Event3.set_generator(gen::ac0_out);
  Event3.set_user_pin(PIN_PF2);
  Event3.start();

  Logic::start(); //start all logic blocs activated


  interrupts();


Pour memo

1 TIMER B est utilisé pour la gestion du décodage des trames DCC en entrée
1 TIMER B est utilise pour un compteur interne avec les timings utilisés pour les opérations de CUTOUT
1 Comparateur (AC0)
4 LUT ( Logique programmable) pour combiner et traiter le pilotage des broches du pont H ( et des leds autours)
4 Events pour liaisonner le tout.

La partie CUTOUT va être celle ci dessous

CUTOUT_PIN et ENABLE_PIN, présentes ici  vont en fait être des pins de SORTIES LOGIQUES.
Elles ne pilotent pas directement  la broche ENABLE ou une broche CUTOUT
Elles sont utilisées en les liant à des pins d entrée des CCL LIUT: elle agiront comme signaux dans la circuiterie qui va auto réagir vers les broches de pilotage des composants  les broches réelles qui drive le L6203: ENABLE PIN, IN1 IN2 et les leds diverses.

Toute la partie CCL est hardware et ne dépend pas des cycles du CPU.
La réaction est donc (quasi) immédiate (qq nano secondes suffisent!)

Les valeurs de références sont calculées selon la vitesse du CPU ( F_CPU) ( pour les timings suivant en us: 26, 30,484,488):

Code: [Sélectionner]


#define ENABLE_STOP F_CPU / 1000000 * 26    // CUTOUT MIN START VALUE
#define ENABLE_START F_CPU / 1000000 * 488  // CUTPOUT MAX STP¨VALUE
#define CUTOUT_START F_CPU / 1000000 * 30   //4us security gap cutout at start
#define CUTOUT_STOP F_CPU / 1000000 * 484   //4us secutity gap cutout at stop



Code: [Sélectionner]

void CUTOUT(void)
  {   
    //TIMER B IS ALREADY STARTED AND CNT GO UP     
    if(TICK_TIMER.CNT < ENABLE_STOP) //< 26us
    {
      //L6203_ENABLE_PIN ON
      ENABLE_PIN_ON;
    }
    else if((TICK_TIMER.CNT < CUTOUT_START) && (TICK_TIMER.CNT >= ENABLE_STOP)) // >=26us & <30us
    {
      //L6203_ENABLE_PIN OFF
      ENABLE_PIN_OFF;
    }
    else if((TICK_TIMER.CNT < CUTOUT_STOP) && (TICK_TIMER.CNT >= CUTOUT_START)) //>=30us & <484us
    {
      //MAKE CUTOUT
      CUTOUT_PIN_ON;
    }
    else if((TICK_TIMER.CNT < ENABLE_START) && (TICK_TIMER.CNT >= CUTOUT_STOP)) // >=484 us & < 488us
    {
      //STOP CUTOUT
      CUTOUT_PIN_OFF;
    }
    else if ((TICK_TIMER.CNT >= ENABLE_START)) // >=488us
    {
      //ENABLE PIN ON:
      ENABLE_PIN_ON;

      //CUTOUT IS OVER => STOP TICK COINTER
      STOP_TICK_TIMER();
    }
  }




Le pilotage des broches IN1 et IN2 L6203_ENABLE_PIN ne passent pas par le cœur du CPU mais par les portes logique (CCL LUT) qui vont les commander selon les valeurs des tables.

Astucieux?

[Brunotoutsimple]

bonjour Laurent
je suis avec intérêt tous tes travaux, ainsi que ceux de Christophe, je découvre beaucoup de chose. J'essais de comprendre le fonctionnement.
d' après ce que j'ai compris, il faut:
1) Labox de Christophe mais qui est en évolution afin qu'elle puisse contenir le Cutout pour RailCom.
2) la carte main
3) X satellites, un pour chaque canton.
4) la carte watchdog.

Maintenant je n'ai pas tout compris sur le fonctionnement des boosters sur le réseau.

Cordialement
Bruno

[Brunotoutsimple]

Bonjour Laurent

Puisque tu es entrain de redessiner Les satellites autonomes, serait-il  pas intéressant de les transformer directement en Booster autonome.
Pourquoi pas utiliser le câble 4 Paires ,si cela est possible, pour distribuer:
1/ 1 paire pour le signal CAN
2/ 1 paire pour Le signal CD
3/ 1 paires pour le 0V commun
Et concernant la sortie E (d'après ce que j'ai compris, c'est la signalisation du défaut du booster),vous pourrez la transmettre par le réseau CAN.

et un câble pour la ligne de distribution 12 ou 24V qui alimenterait les "Booster-Autonome".

Bonjour Marc,

Je suis bien d'accord avec toi pour le cas que tu évoques "2 secteurs chacun alimenté par son propre booster". Cependant, je ne crois pas que ce cas ait été abordé. Cela m'amène à te poser trois questions :

1° - Quel intérêt y a t-il à alimenter chaque secteur avec son propre booster ?
2° - Perso, j'en vois quelques-uns, surtout dans le cadre de satellites autonomes où du coup on peut pousser plus loin le principe d'autonomie puisque l'on parlerait aussi de boosters autonomes (la centrale et les commandes restant centralisées mais pas la puissance). Ce concept te parait-il cohérent et présenter un quelconque intérêt ?
3° - Du coup, peut-on imaginer des cartes moteur de moindre puissance (1 à 2A) comme par exemple la Pololu MP6550 (https://www.pololu.com/product/4733) qui, si je ne me trompe pas, est capable également d’assurer le break nécessaire au cutout ?

Cette carte Pololu MP6550  dispose d’une détection de courant mais je ne sais pas si elle est assez fiable.

Quels sont vos avis, Marc et autres ?

Christophe

Et pourquoi pas utiliser comme propose Christophe en le disant à Marc, un Pololu MP6550 pour chaque "Booster-Autonome" qui aurait sa propre limite de courant

J'ai bien conscience que c'est un gros travail pour vous de repenser le Hardware de la carte "Booster-Autonomes" , mais je pense que cela serait judicieux.

Etant novice dans le domaine, c'est juste une proposition.

Bonne journée à vous tous.

Bruno

[laurentr]

Bonjour Bruno

Ce qui est décrit est une option. Elle semble valable mais n'est pas dans l'esprit du moment. ( au moins sur la version en cours)
Par ailleurs cela impose d avoir une parfaite inter synchro entre les éléments, impose d avoir la gestion du reverse localement.

In fine la souplesse acquise est à mettre en balance avec le cout.

Toutefois les modules conçus ici et utilisés sont parfaitement réutilisables sur un design socle diffèrent.

Ltr

[Brunotoutsimple]

Bonjour Bruno

Ce qui est décrit est une option. Elle semble valable mais n'est pas dans l'esprit du moment. ( au moins sur la version en cours)
Par ailleurs cela impose d avoir une parfaite inter synchro entre les éléments, impose d avoir la gestion du reverse localement.

In fine la souplesse acquise est à mettre en balance avec le cout.

Toutefois les modules conçus ici et utilisés sont parfaitement réutilisables sur un design socle diffèrent.

Ltr

Bonjour Laurent
Merci pour votre réponse.
j'aurais quelques questions à vous poser:
A - Est-ce que vous pouvez publier le Schéma du "RailCom: Générateur de CutOut avec booster" avec la liste des composants, car d'après ce que j'ai compris LaBox ne permet pas de produire le CutOut pour railCom.
B - Est-ce que C et D peuvent être distribués en direct entre chaque booster et LaBox ou ne vaut-il pas mieux les isoler avec des optocoupleurs type 6N137 ou autre équivalent ?
C - Est-ce qu'il serait pas préférable de distribuer C et D avec une tension de 12 ou 24V afin de réduire la chute de tension dans les câbles ?
Désolé de poser ce genre de question.
Je vous en remercie par avance

[laurentr]

Bonsoir Bruno

Je teste actuellement cette solution.
Je n'ai pas encore assez avancé pour publier le résultat ( autant ne publier que ce qui fonctionne!?) mais cela sera fait des que possible.

En effet on a bien l'équivalent des plots C et D.
Convertir les tensions ajoute de la complexité mais reste une option (à tester aussi)

Je n'ai pas travaillé sur une refonte de Labox intégrant un dispositif de cutout mais d autres membres du forum s'y consacrent.

Cela devrait aboutir dans de nouvelles propositions.

Ltr

[Brunotoutsimple]

Bonsoir à vous

Laurent
Dites moi si je ne trompe, la sortie E de CDE permet de signaler un problème du booster. On pourrez récupérer et envoyer cette information au TCO en passant par le CAN. l'opérateur de gestion pourra réaliser manuellement ou automatiquement le détournement des trains sur une autre voies et signaler se défaut.

[laurentr]

Bonjour Bruno

C est une option mais la mise en œuvre n'est pas si trivial.

Ltr

[laurentr]

Bonjour

Comme je l'ai explique sur le post de présentation des fonctionnalités des AVR avec les librairies DXCORE MEGATINYCORE et MEGACOREX, je poursuis les tests en vue de la mise en œuvre.

Quelques corrections de syntaxes ont été rendues nécessaires.

Quelques tests aussi ont montré une impossibilité de combiner certains éléments (sortie PA7 du CCL0 (LUT0) sur un ATTINY826. Pas de raison identifiée. Elle est cependant opérationnelle sur un autre bloc.

Ces tests très utiles sont la pour bien vérifier le bon comportement comme attendu.

A suivre donc...

[laurentr]

Bonjour


Mes tests se poursuivent (mais le temps manque pour avancer aussi rapidement que souhaité!)

Pour des raisons de commodité j'ai porté aussi le code vers les AVRx ( AVRDx et Atmega serie0  x08 & x09).

Je me suis aussi aperçu à cette occasion d'une simple modification dont les effets de bords sont plus qu'appréciables et dont je vais devoir aussi consacre du temps de test.

En effet il ne s'agit ni plus ni moins que de pouvoir porter pour un décodeur mobile ( dit décodeur de fonctions) la capacité à emmètre des trames de messages railcom.
Le mécanisme d analyse de la trame DCC est similaire à celui déjà mis en œuvre dans cet exemple pour placer au bon moment la fenêtre CUTOUT et les actions qui en découlent.

Ici un noInterrupt() vient lors des conditions de mise en œuvre du cutout suspendre toutes les interruptions. avant de les rétablir une fois le fenêtre cutout close.
Si pour le booster ce mécanisme est suffisant pour laisser un blanc dans la trame d'émission, cela rend impossible d'utiliser d'autres interruptions pourtant nécessaires à d'autres usages dont justement Serial pour emmètre les trames de messages RAILCOM pour un décodeur mobile par exemple.

Quelle est la magie derrière? Juste une utilisation judicieuse/astucieuse des ressources des CPU et de leurs librairies.

Mon implémentation actuelle est "en dure": comprendre que j'ai volontairement choisi des attributions de broches de manière fixe et placer les alias dans le code. Aussi le mapping n'est pas dynamique avec l'utilisation de certaines ressources. Cela ne semble pas être un frein outre mesure, juste une contrainte de design de routage de PCB au plus et une portabilité réduite de la solution.
Cela fera peut-être l'objet d'un axe d'évolutions futures mais je n'ai pas trop envie de m'aventurer dans cette voie pour le moment. Si certains veulent s'en occuper... je n'ai rien contre! Bien au contraire même!! Et il faudra alors créer le post qui va bien pour discuter de cette solution... et de ses déclinaisons/usages