Messages

1

Vos projets / Re : centrale DCC / analogique modulaire

« le: mai 01, 2024, 07:39:46 pm »

Hello Marc

C est beau!
Y a du travail derrière!!Belle œuvre appréciable

Rm sur les utilisations: avec le retour d'expérience des satellites autonomes qui font appel à des détecteurs "ponctuels" placés aux extrémités de zone(s) via des capteurs optiques ( sortie 0-1) sur comparateur , est ce que cela  n'arrangerait il pas tes usages ? La zone pilotée par le PONT H serait alors composée d' un seul segment ("canton") et si besoin des capteurs aux extrémités viennent informer de l'occupation "locale" selon les zones ou le tain se situe en plus de la détection globale par conso au niveau "canton"?

Pour ce qui est du calcul des couts avec les NE556 ( x2)/555(x1) et les coils selon, leur nombre (5 à priori)  le cout est assez faible mais c est plus une question d encombrement qui sera probablement supérieur à ton dispositif actuel à base de diodes. et avec des montages externes pour les capteur locaux.

la SS34 est une Schottky à faible chute (mais rapide)  aussi tu risques d'avoir quelques surprises avec cette faible chute qui sera plus franche avec une diode "classique" avec un Vdrop plus haut.
.

Ltr

2

Vos projets / Re : RailCom: Générateur de CutOut

« le: avril 30, 2024, 05:46:08 pm »

Y a bien une petit ligne qui le dit:

Code: [Sélectionner]

#ifdef __AVR_ATmega328P__                    // --- Arduino AVR --
Donc oui pour le TINY pas de sujet mais si 328P /MEGA ou autre le mapping brochage est à revoir pour être sur INT0 ( PD2) comme PB2 l'est sur le TINYx5

Ltr

3

Vos projets / Re : centrale DCC / analogique modulaire

« le: avril 30, 2024, 05:43:15 pm »

Hello

Si je me souviens bien des hypothèses de départ l' idée  était de réduire le nombre de composants "externes" au delà du CPU .

Si on peut en ajouter pourquoi alors ne pas partir sur un montage externe qui dans tous les cas donnera la "vérité" sur l'occupation 0/1 de la zone en question? ( montage à diodes + opto? montage  à base de COIL, COIL +NE555/556..?)

Si on désire avoir toutes les mesures de conso local alors on acceptera de poser de petit TINY et remonter cela d une façon ou d une autre...

Pour la détection en analogique une solution peut consister à envoyer un bref temps un courant qui indiquera en retour l'état...

Ltr

4

Vos projets / Re : RailCom: Générateur de CutOut

« le: avril 30, 2024, 04:28:46 pm »

Bonjour

@Christophe, l'adaptation pour le 328P ne devrait elle pas plutôt avoir PD2 comme entrée (INT0) pour le signal DCC ? et passer les broches de pilotage sur le PORTB ? ( PB2 ne gère pas des interruptions externes me semble t il?)

Je regarde de mon cote pour porter cela sur AVRx ( MAGTINY AVRx série 0 ou 1 (Atmegax08 x09, NANOEVERY et AVR Dx ( DA DB DD)...)
Je pense cependant plus à un hardware disposant de 2 timer B dans ce lots de candidats...

Ltr

5

Vos projets / Re : RailCom: Générateur de CutOut avec booster

« le: avril 29, 2024, 05:29:11 pm »

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;                       //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
  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;                      //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.assign_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.assign_generator(gen::ccl3_out);
  Event2.set_generator(event::user::evoutc_pin_pc2);

  Event3.assign_generator(event::gen::ac0_out);
  Event3.set_user(event::user::evoutf_pin_pf2);
  Event3.start();

  Logic::start(); //start all logic bloc 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?

6

Vos projets / Re : RailCom: Générateur de CutOut

« le: avril 28, 2024, 09:12:00 pm »

De ma compréhension le SECURITY GAP intervient lorsqu'un véhicule est à cheval entre sur 2 boosters. Ceux ci pilotant des électroniques qui peuvent avoir un temps de réaction "élastique" l'un vis à vis de l'autre pour être certain de ne pas être dans un cas où l'un a déjà fini et pas l'autre, on ajoute cette temporisation ce qui pourrait avoir des effets de bords sur les décodeurs mobiles.
C est donc un temps mort de sécurité mis à chaque bout du cutout.

(on pourrait aussi avoir en tête les fameux 4us de précision de delta des AVR avec micro?)

On pourra surement voir avec un L18200 et les ponts similaires comment traiter cela.

Ltr

7

Vos projets / Re : RailCom: Générateur de CutOut

« le: avril 28, 2024, 05:17:13 pm »

Bonjour

J ai une question qui va aider la recherche d éventuels autres pont H.

D après OPEN DCC il faut insérer un "SECURITY GAP" de 4us  sur le L6203 entre son activation/désactivation ( broche ENABLE) et la commande de mise en "CC" ( via IN 1 et IN2)
Ceci est (fortement) recommandé notamment dans le cas de la présence de plusieurs boosters.

Comment gérer cela au niveau du L298 ( que je ne connais pas) ou d'autres ponts H qui ne reposent pas sur la présence de broche ENABLE? ( et donc intégrer cela au dispositif en cours de mise au point pour LABOX)

Ltr

8

Vos projets / Re : RailCom: Générateur de CutOut avec booster

« le: avril 28, 2024, 04:50:51 pm »

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)

9

Vos projets / Re : RailCom: Générateur de CutOut avec booster

« le: avril 28, 2024, 04:35:48 pm »

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

10

Vos projets / RailCom: Générateur de CutOut avec booster

« le: avril 28, 2024, 01:52:35 pm »

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

11

Vos projets / Re : RailCom: Générateur de CutOut avec booster

« le: avril 28, 2024, 04:21:36 am »

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

12

Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial

« le: avril 15, 2024, 12:32:19 pm »

Bonjour

Le bouclier assurant les détections est arrivé. 
Ici en panneau 3x3 il faut encore l'équiper de ses composants "traversants" dont les "COILS" et le passage du fil dans l'anneau.
L'empreinte pour les COILS est adaptée pour différents modèles.
Illustrés ici sur les photos le cas de ZMCT103C de 1000 tours.

Quelques essais restent donc encore à mener pour les valider.

Pour memo ils sont basés sur le montage "PAISELY" proposé par NOXPOR (Eric) qui a été ici adapté au contexte "satellites" en approche modulaire.
Le NE555 remplace le NE556 puisque seule une "entrée" est utilisée.
Un opto assure la conversion de tension (5V ou 3V3) de l'état de sortie pour aller vers le CPU.
Des indicateurs lumineux (ROUGE = OCCUPE) ( VERT = libre) complètent le dispositif en affichant l'état sur la zone de détection.

En complément il est possible d'inverser l'état de sortie haut ou bas qui traversera l'optocoupleur pour indiquer au CPU l'état d'occupation.

Ltr

13

Vos projets / Re : Décodeur Accessoires Arduino

« le: avril 08, 2024, 10:16:26 pm »

Bonsoir

Il faut se pencher sur quelques réponses pour mieux cibler:
mode de d'alimentation des MEGA et des leds, de la couche LOCONET, ...

Un  schéma peut aider à mieux visualiser.

Ltr

14

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: avril 08, 2024, 04:53:51 pm »

Bonjour

En effet se passer de "AnaloguRead() comme nous en avons discuté va éviter des temps de traitement relativement "longs" qui plus est sur les AVR "historiques"

Sur les AVR plus récents ( AVR Dx et MEGATINY) il y a 2 éléments à considérer:
1 l analoguRead est beaucoup plus rapide que sur les anciens AVR.

Les mesures faites par Spence KONDE en témoignent:
https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Ref_Analog.md voir la section mTC/DxC) bool analogSampleDuration(duration)

En grosso ici lecture unique sur 12us ( comme sur les anciens AVR) et temps de traitement (10us) amènent à 22us ( 4 fois plus rapide que sur AVR anciens)

2/ Ces nouveaux AVR on vu 3 versions successives d'ADC et ne se commandent pas de la même façon (ce que masque cependant le analoguRead() classique)

Et pour utiliser directement les registres il faudra selon le CPU retenu tout se "palucher" à la main...

J'ai déjà écrit une partie mais elle n'est pas déclinable à toutes les broches ( il faudrait la retravailler) mais comme l analoguRead est (à priori) "assez rapide" c'est peut être  pousser un peu loin sans réel besoin... A voir par quelques tests.

A noter que sur les nouveaux AVR l'échantillonnage étant réglable (par configuration) peut sortir directement une valeur dont il restera à diviser par le nombre d'échantillons demandés. (le fameux >>4 utilisé par Christophe dans le code ci dessus pour la moyenne de 4 lectures successives)

Lorsque j aurai reçu le matos nécessaire je ferai quelques tests et vous communiquerai les résultats.

Ltr

15

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: avril 06, 2024, 12:51:31 pm »

Bonjour

Petit interlude pour connaitre le mapping de sensibilité(s) que vous arrivez à déceler depuis le primaire? ( et du range de valeurs en sorties).

Quid en fait du seul correspondant en "bruit" et donc d une valeur en deca la mesure de détection est à "nettoyer"?

Ltr