Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Sujets - trimarco232

Pages: [1]
1
Bonjour,
de me suis finalement décidé à dessiner ce décodeur
la base est la même que que le décodeur à uln2003 https://forum.locoduino.org/index.php?topic=1431.0
les uln2003 sont remplacés par de petits mosfets en boitier double sot23-6 ; les caractéristiques de ces mosfets sont 30v, 2A5 continu et 10A pulsé
cela suffit peut-être pour du peco ou du seep, mais je l'ai plutôt prévu pour des solénïdes de roco, fleischmann, trix ...
le dispositif de protection prévu pour les mosfets utilise des NUP2105L, normalement faits pour protéger les lignes CAN, est ambitieux, optimiste ou raisonnable, en tous cas pas encore évalué, on est donc sur de l'expérimental pour cette partie
je ne conçois pas de commande de solénoïde sans dispositif CDU, même si les moteurs sont munis de fin de course ; il vaut même mieux, amha, mettre les fins de course hors service et utiliser le cdu
ici, le cdu est un peu particulier : l'alim se fait en 10-12v, et les tensions nécessaires aux solénoïdes sont 16v, voire 24v pour du peco ; on a donc un convertisseur dcdc boost qui charge la capa cdu à la tension voulue ; l'arduino peut choisir cette tension entre 2 valeurs (par ex 16v ou 24v), on peut donc panacher les moteurs d'aiguille ; le CI convertisseur dcdc est aussi en boitier sot23-6 : c'est un MT3608
le cdu doit stopper la charge de la capa cdu tant qu'il y a une consommation au niveau des solénoïdes : c'es le rôle de l'électronique de contrôle située à droite de la capa cdu (on intervient "simplement" sur la broche enable du CI convertisseur dcdc)
l'arduino mesure aussi la tension de la capa cdu, le but c'est d'attendre qu'elle doit rechargée avant de commander la décharge suivante
en pj, un dessin du décodeur avec l'identification des différentes parties
bien entendu, il y a aussi les cartes d'extensions, visibles en situation sur la 2ème pj

2
Bonjour,
j'avais dessiné des modules d'extension qui permettent de commander des moteurs type mtb (à la rigueur, ça peut marcher avec des solénoïdes à faible consommation genre fleischmann)
emporté par mon élan, j'ai aussi dessiné un décodeur dcc qui peut servir de maître pour ces modules : la capacité est impressionnante

(j'ai aussi sous le coude des modules à mosfets costauds (pour peco), ou moyens (pour tous solénoïdes raisonnables), le tout commandé par "ma" centrale
je dessinerai peut-être un décodeur maître pour ceux-cis, (s'il y a une demande), un peu moins simple car j'y ajouterai une cdu à xl6007)
édit : le décodeur dcc pour solénoïdes courants (roc, flesichmann, trix ...) est dessiné, voir l'article https://forum.locoduino.org/index.php?topic=1433.msg15526#msg15526

une image, en attendant :

3
suite à la demande de Pierrre sur https://www.locoduino.org/spip.php?article161#forum6190

/*
   Decoder for traffic light with three or two /// or 4 leds on ARDUINO NANO

   by default the red leds are switched on
   pin 2 receives DCC interrupts

   TRAFFIC LIGHT WITH THREE leds (GREEN, RED, YELLOW)
   5 decoders of traffic lights with three leds on Arduino NANO/UNO
   the leds are controlled by pins 3 to A3 by triplet
   traffic light 1 : 3,4,5
   traffic light 2 : 6,7,8
   traffic light 3 : 9,10,11
   traffic light 4 : 12,13,A0
   traffic light 5 : A1,A2,A3
   two addresses by traffic light
   even addresses for green and red lights
   odd addresses for yellow light

   /// TRAFFIC LIGHT WITH 4 leds (green, red, yellow, carre))
   4 decoders of traffic lights with 4 leds on Arduino NANO/UNO
   the leds are controlled by pins 3 to A4 by quadruplets
   traffic light 1 : 3,4,5,6
   traffic light 2 : 7,8,9,10
   traffic light 3 : 11,12,13,A0
   traffic light 4 : A1,A2,A3,A4
   two addresses by traffic light
   even addresses for green and red lights
   /// odd addresses for yellow and carre indications

   TRAFFIC LIGHT WITH TWO leds (GREEN, RED)
   8 decoders of traffic lights with two leds on Arduino NANO/UNO
   the leds are controlled by pins 3 to A4 by pair
   traffic light 1 : 3,4
   traffic light 2 : 5,6
   traffic light 3 : 7,8
   traffic light 4 : 9,10
   traffic light 5 : 11,12
   traffic light 6 : 13,A0
   traffic light 7 : A1,A2
   traffic light 8 : A3,A4
   one address by traffic light

   CONFIGURATION
   MODE : determined by the common of the led, LOW if common = HIGH, HIGH if common = LOW
   FIRST_ID_DCC : DCC address of the first traffic light
   NB_TRAFFIC_LIGHT : determined by the kind of traffic light, BICOLOR for two leds, TRICOLOR for three leds

*/

/// modifs / ajouts pour 4 feux
//// dégobage pour modifs pour 4 feux : supprimer la ligne

/***************************************************************************************
              CONFIGURATION SETTING

 ****************************************************************************************/

#define CONSOLE                             // output console, comment this line after checking the soft
#define MODE   LOW                          // LOW or HIGH
#define FIRST_ID_DCC   90                   // first DCC address, DCC_CODE
#define NB_TRAFFIC_LIGHT  FOURCOLOR         //  TRICOLOR or BICOLOR /// ou FOURCOLOR

/**********************************************************************************
     DON'T CHANGE THE FOLLOWING
 *********************************************************************************/

/******************************************************************************
      INTERNAL PARAMETERS

 ********************************************************************************/

//  DCC

#include "DCC_Decoder.h"                // Minabay library /// "DCC_Decoder.c" must be present too in the folder
#define kDCC_INTERRUPT    0             // pin 2 receives DCC interrupts
int previous_address = 0;               // avoids multiple DCC addresses
int previous_position = 2;              // avoids multiple DCC orders
volatile boolean update_light;          // set if an update should be processed after DCC control

// traffic light

#define BICOLOR  8                     // 8 traffic lights with two leds
#define TRICOLOR 5                     // 5 traffic lights with three leds
#define FOURCOLOR 4                    /// 4 traffic lights with 4 leds
#define FIRST_PIN         3            // pin of the first traffic light
#define GREEN             0            // address DCC/0
#define RED               1            // address DCC/1
#define YELLOW            2            // address DCC+1/0
#define CARRE             3            /// address DCC+1/1

// traffic light definition

struct light {
  int address;                    // its DCC address
  int current_position;           // green / red / yellow /// carre
  int green;                      // pin of the green led
  int red;                        // pin of the red led
  int yellow;                     // pin of the yellow led
  int carre;                      /// pin of the carre led
  boolean activation_request;     // request of activation
};
light traffic_light[NB_TRAFFIC_LIGHT];    // the set of traffic light

/********************************************************************
   method called if a request is made by the DCC

 *******************************************************************/

void activation_traffic_light() {
  for (int i = 0; i < NB_TRAFFIC_LIGHT; i++)                 // for all traffic lights
  {
    if (traffic_light[i].activation_request == true)  // if the traffic_light is waiting for activation
    {
      switch (traffic_light[i].current_position)           // we look the current position
      {
        case GREEN : {                                         /// indication GREEN
            digitalWrite(traffic_light[i].green, MODE);        // switch on green
            digitalWrite(traffic_light[i].red, !MODE);         // switch off red
            if ( NB_TRAFFIC_LIGHT == TRICOLOR || NB_TRAFFIC_LIGHT == FOURCOLOR) {
              digitalWrite(traffic_light[i].yellow, !MODE);    // switch off yellow
            }
            if ( NB_TRAFFIC_LIGHT == FOURCOLOR) {         ///
             digitalWrite(traffic_light[i].carre, !MODE);     /// switch off carre
            }
            /**/#ifdef CONSOLE
            Serial.print("active -> signal "); Serial.print(i); Serial.println(" : green led");
            /**/#endif
            break;
          }
        case RED : {                                         /// indication RED
            digitalWrite(traffic_light[i].green, !MODE);     // switch off green
            digitalWrite(traffic_light[i].red, MODE);        // switch on red  /// incomplet ?
            if ( NB_TRAFFIC_LIGHT == TRICOLOR || NB_TRAFFIC_LIGHT == FOURCOLOR) {
              digitalWrite(traffic_light[i].yellow, !MODE);  // switch off yellow
            }
            if ( NB_TRAFFIC_LIGHT == FOURCOLOR) {       ///
              digitalWrite(traffic_light[i].carre, !MODE);   /// switch off carre
            }
            /**/#ifdef CONSOLE
            Serial.print("active -> signal "); Serial.print(i); Serial.println(" : red led");
            /**/#endif
            break;
          }
        case YELLOW : {                                         /// indication YELLOW
            digitalWrite(traffic_light[i].green, !MODE);        // switch off green
            digitalWrite(traffic_light[i].red, !MODE);          // switch off red
            digitalWrite(traffic_light[i].yellow, MODE);        // switch on yellow
            if ( NB_TRAFFIC_LIGHT == FOURCOLOR) {               ///
              digitalWrite(traffic_light[i].carre, !MODE);      /// switch off carre
            }
            /**/#ifdef CONSOLE
            Serial.print("active -> signal "); Serial.print(i); Serial.println(" : yellow led");
            /**/#endif
            break;
          }
        case CARRE : {                                          /// indication CARRE
            digitalWrite(traffic_light[i].green, !MODE);        // switch off green
            digitalWrite(traffic_light[i].red, MODE);           /// switch on red  // incomplet ?
            digitalWrite(traffic_light[i].yellow, !MODE);       // switch off yellow
            digitalWrite(traffic_light[i].carre, MODE);         /// switch on carre
            /**/#ifdef CONSOLE
            Serial.print("active -> signal "); Serial.print(i); Serial.println(" : carre + red led");
            /**/#endif
            break;
          }
      }
    }
    traffic_light[i].activation_request = false;            // the traffic light is updated
  }
  update_light = false;                                        // all updates are made
}

/*************************************************************************************
    DCC method

 ***********************************************************************************/

void BasicAccDecoderPacket_Handler(int address, boolean activate, byte data)
{
  address -= 1; address *= 4; address += 1; address += (data & 0x06) >> 1;    // DCC address decoding
  int led = (data & 0x01) ? GREEN : RED;                                      // DCC/0 or DCC/1
  int traffic_light_index = address;                                          // index of a traffic light
  int color = led;                                                            // the color of the led
  boolean activation = false;
  if ((address != previous_address) || ((led != previous_position) && (address == previous_address))) { // if we change the address or the led
    switch (NB_TRAFFIC_LIGHT) {
      case BICOLOR : {      // if the address is in our range for traffic light with two leds
          if ((address >= FIRST_ID_DCC) && (address < FIRST_ID_DCC + NB_TRAFFIC_LIGHT)) {
            traffic_light_index = address - FIRST_ID_DCC;                                  // index of the traffic light
            activation = true;
          }
          break;
        }
      case TRICOLOR : {     // if the address is in our range for traffic light with three leds
          if ((address >= FIRST_ID_DCC) && (address < FIRST_ID_DCC + (2 * NB_TRAFFIC_LIGHT))) {
            if (address % 2 != 0) {
              traffic_light_index = address - 1;  // if odd address => yellow led
              color = YELLOW;
            }
            traffic_light_index = (traffic_light_index - FIRST_ID_DCC) / 2;                  // index of the traffic light
            activation = true;
          }
          break;
        }
      case FOURCOLOR : {     /// if the address is in our range for traffic light with 4 leds
          if ((address >= FIRST_ID_DCC) && (address < FIRST_ID_DCC + (2 * NB_TRAFFIC_LIGHT))) {
            if (address % 2 != 0) {
              traffic_light_index = address - 1;  // if odd address => yellow led
              if (data & 0x01) color = CARRE; else color = YELLOW; /// en fonction du poids faible
            }
            traffic_light_index = (traffic_light_index - FIRST_ID_DCC) / 2;                  // index of the traffic light
            activation = true;
            /**/#ifdef CONSOLE
            Serial.print("s"); Serial.print(traffic_light_index); Serial.print(" a"); Serial.print(address); Serial.print("/"); Serial.print(data & 0x01); Serial.print(" ");
            /**/#endif
          }
          break;
        }
    }
    traffic_light[traffic_light_index].activation_request =  activation;    // activation is requested
    traffic_light[traffic_light_index].current_position = color;            // state is requested (color of the led)
    update_light = activation;                                              // traffic light update is requested
  }
  previous_address = address; previous_position = led;                     // the current activation is saved
}
/**********************************************************************************************
    setup

 ******************************************************************************************/

void setup() {
#ifdef CONSOLE
  Serial.begin(115200);
#endif
  delay(1500); /// compatible debogage promicro

  int pin_jump = 0;                                                    // a jump for traffic light pins
  int traffic_light_jump = 0;                                          // a jump for traffic light number
  for (int i = 0; i < NB_TRAFFIC_LIGHT; i++) {                         // for all the traffic lights
    traffic_light[i].activation_request = false;                       // no activation request
    traffic_light[i].green = pin_jump + FIRST_PIN;                     // pin number of the green led
    pinMode(traffic_light[i].green, OUTPUT);                           // green led in output(ID DCC/0)
    digitalWrite(traffic_light[i].green, !MODE);                       // green led switch off
    traffic_light[i].red = 1 + pin_jump + FIRST_PIN;                   // pin number of the red led
    pinMode(traffic_light[i].red, OUTPUT);                             // red led in output  (ID DCC/1)
    digitalWrite(traffic_light[i].red, MODE);                          // red led switch on
    if (NB_TRAFFIC_LIGHT == TRICOLOR || NB_TRAFFIC_LIGHT == FOURCOLOR ) {   // if 3 leds /// or 4 leds
      traffic_light[i].address = traffic_light_jump + FIRST_ID_DCC + i;   // its DCC ID
      traffic_light[i].yellow = 2 + pin_jump + FIRST_PIN;              // pin number of the yellow led
      pinMode(traffic_light[i].yellow, OUTPUT);                        // yellow led in output  (ID DCC+1/0)
      digitalWrite(traffic_light[i].yellow, !MODE);                    // yellow led switch off
      traffic_light_jump++;                                            // the following traffic light
      pin_jump += 3;                                                   // the following pin for three leds
      if (NB_TRAFFIC_LIGHT == FOURCOLOR) {                             /// if 4 leds
        traffic_light[i].carre = pin_jump + FIRST_PIN;
        pinMode(traffic_light[i].carre, OUTPUT);                       // carre led in output  (ID DCC+1/1)
        digitalWrite(traffic_light[i].carre, MODE);                    // carre led switch on
        pin_jump += 1;                                                 /// the following pin for 4 leds
      }
    }
    else {                                                             // if two leds
      traffic_light[i].address = FIRST_ID_DCC + i;                     // its DCC ID
      pin_jump += 2;                                                   // the following pin for two leds
    }

  }

  DCC.SetBasicAccessoryDecoderPacketHandler(BasicAccDecoderPacket_Handler, true);   // instanciate the DCC
  DCC.SetupDecoder( 0x00, 0x00, kDCC_INTERRUPT );                                   // its IT
  update_light = false;                                                             // no update

#ifdef CONSOLE
  //// Serial.begin(115200);
  Serial.println(""); Serial.println(""); Serial.println(""); ///
  for (int i = 0; i < NB_TRAFFIC_LIGHT; i++) {
    Serial.print("traffic light "); Serial.println(i);
    Serial.print("\t green led on pin : "); Serial.print(traffic_light[i].green); Serial.print(" , DCC address : "); Serial.print(traffic_light[i].address); Serial.println("/0");
    Serial.print("\t red led on pin : "); Serial.print(traffic_light[i].red); Serial.print(" , DCC address : "); Serial.print(traffic_light[i].address); Serial.println("/1");
    if (NB_TRAFFIC_LIGHT == TRICOLOR) {
      Serial.print("\t yellow led on pin : "); Serial.print(traffic_light[i].yellow); Serial.print(" , DCC address : "); Serial.print(traffic_light[i].address + 1); Serial.println("/0");
    }
    else   if (NB_TRAFFIC_LIGHT == FOURCOLOR) { ///
      Serial.print("\t yellow led on pin : "); Serial.print(traffic_light[i].yellow); Serial.print(" , DCC address : "); Serial.print(traffic_light[i].address + 1); Serial.println("/0");
      Serial.print("\t carre led on pin : "); Serial.print(traffic_light[i].carre); Serial.print(" , DCC address : "); Serial.print(traffic_light[i].address + 1); Serial.println("/1");
    }
  }
#endif
}

/*************************************************************************
   loop

 ************************************************************************/

void loop() {
  DCC.loop();                   // Is there a DCC command ?

   delay(2000) ; ////
   BasicAccDecoderPacket_Handler(24, 1, 2); ////

  if (update_light) {
    activation_traffic_light(); // if yes, activation of traffic lights
  }

   delay(2000) ; ////
   BasicAccDecoderPacket_Handler(24, 1, 5); ////

   if (update_light) { ////
    activation_traffic_light(); // if yes, activation of traffic lights ////
   }    ////



}

édits : regarder svp. la date du dernier Modifié pour s'assurer d'avoir la dernière version

4
Vos projets / centrales dcc esp32 trimarco232
« le: mai 20, 2022, 12:29:54 pm »
Bonjour,
ça fait un bail que j'ai ça sous mon coude gauche volumineux, c'est le moment d'en parler un peu
les choses à l'envers ? j'ai commencé par dessiner et réaliser le pcb, puis j'ai attaqué le soft de la génération et de l'envoi des bits dcc
actuellement j'en suis à l'étape suivante : le scheduler (ou planificateur de l'envoi des packets dcc), défi au niveau de l'analyse et de la programmation
ce que j'ai fait c'est la chose suivante, assez simple
les packets dcc créés sont classés prioritaires ou pas, selon leur nature ; par exemple les packets constituant un message de freinage, ou une commande d'accessoire dont le timing est critique, seront prioritaires, les autres non
les packets prioritaires sont placées dans des queues qui seront répétées, et exécutées avant la queue non prioritaire ; ça donne un truc de ce genre :
p3 /// queue fifo où sont mis, donc d'où sont envoyés, les nouveaux packets prioritaires
p2 /// queue fifo de la 1ère répétition des packets prioritaires
p1 /// queue fifo de la 2nde et dernière répétition des packets prioritaires, suite à quoi les packets ex prioritaires sont définitivement placée dans la queue p0
p0 /// queue qui envoie en boucle tous les packets existants, sans notion de priorité
la queue p0 ne fonctionne que si les 3 autres ont été vidées de leur packet(s)
un même packet ne peut être envoyé 2x directement à sa suite : par exemple un packet prioritaire x, qui passe de p3 à p2, attendra qu'un autre packet y soit envoyé, avant que ce packet x soit envoyé de p2 à son tour
ça, ça marche

reste quelques questions au niveau de l'analyse
- chaque packet de vitesse doit rester dans la boucle p0, dans laquelle ils sera (normalement) remplacé par un nouveau packet de vitesse qui a la même adresse
- les packets d'accessoires n'ont pas lieu de rester ni même de figurer dans la boucle p0 ?
- les packets de fonction doivent-ils rester dans la boucle p0 ? lesquels (je pense l'éclairage) ? pourquoi ?

5
Bonjour,
j'ai dessiné ceci (sans savoir si je vais l'adopter)

c'est un module de 16 entrées par registre à décalage 74hc165 ; on peut donc les chaîner pour augmenter le nombre d'entrées
il faut 3 broches de l'arduino, idéalement les miso et sck du périphérique spi, mais des io ordinaires le font aussi avec une bibliothèque qui va bien
il y a 16 résistances de pull-up placées de part et d'autres des 74hc165 : il faut donc que les boutons faisant l'objet des entrées donnent un GND
les résistances situées à droite ne sont placées que sur le dernier module, elles donnent une certaine immunité vis à vis des parasites
la connectique représentée est du jst xh au pas de 2.5mm, mais des bornes à visser au pas de 2.54, ou des fil directement soudés le font aussi
j'ai aussi dessiné ce module avec un seul 74hc165 (8 entrées)
à noter qu'alternativement j'ai aussi mis en oeuvre des modules du commerce i2c à mcp23017
avantages du module à 74hc595 trimarco :
- pas besoin de mettre d'adresse, chainage "illimité"
- disponibilité et prix en période de pénurie
- connectique ad hoc permettant un raccordement nickel
avantages du module i2c mc23017 du commerce :
- pas besoin de résistance de pull-up
- existe tout fait
- peut aussi servir en sortie

le pcb comprend 2 autres modules curieux, qui ne comportent pas de cuivre ... c'est en fait des supports pour les modules
le 2ème dessin reprend la silhouette du 1er, mais les trous de fixation font 3mm au lieu de 2 ; il est prévu à être collé sur la face intérieure du tco ; dans le trou de 3mm, il y aura des canons-écrous qui seront emmanchés à force (ou collés) : le vrai module prendra donc place sur ce support, maintenu par des vis de 2mm vissées dans les canons ; cette solution permet de faire propre et démontable
le 3ème module ne correspond pas aux 2 autres, mais sert de support, selon le même principe, à un module du commerce à tlc5947, pour la commande de 24 leds ; à noter que la connectique aux extrémités du module à 74hc165 permet d’insérer les modules à tlc5947 avec la même élégance au niveau du câblage ; j'ai choisi les modules à tlc5947 principalement parce qu'il n'y a pas besoin de résistances pour les leds
à suivre, peut-être ...

6
Discussions ouvertes / S88 et S88-N : pourquoi c'est si compliqué ?
« le: janvier 27, 2022, 05:07:52 pm »
Bonjour,
ces bus de rétrosignalisation sont toujours largement utilisés
ils sont d'origine maerklin, il me semble - ça ne rajeunit personne -
l'utilité, c'est par exemple de remonter des occupations de zones, ou de lire des boutons sur le tco
les 2 avantages sont ;
- la simplicité et le bas coût de l'électronique, faite à partir d'ics simples et courants
- la non nécessité de fixer l'adresse des modules, c'est le rang du module dans la chaîne qui donne l'adresse ; ainsi, on peut substituer un module à un autre sans autre forme de procès ; certains y voient par contre un inconvénient : si dans le cadre d'un agrandissement on rajoute un module dans la chaîne, il faut renuméroter, dans le soft, les modules existants qui se trouvent en aval du nouveau ... mais perso, je trouve + avantageux de ne pas avoir à strapper ou programmer d'adresse ...

en observant la façon dont sont faits ces modules, on y voit des registres à décalage du type 4044, ça c'est indispensable, mais aussi et des bascules rs de type 4014, pilotées par le signal reset, et dont le rôle me parait obscur ... peut-être était-ce pour garder en mémoire un contact temporaire, genre bouton pression, en attendant que le microcontrôleur ait le temps de procéder à la lecture, ce qui est compréhensible, tant à l'époque ils étaient lents et assez occupés par ailleurs
peut-être aussi le fait que le S88 est considéré comme un (mauvais) bus de terrain, et que, pour pouvoir ménager une certaine distance entre modules, la vitesse de transmission doit être réduite, et par conséquent tous les délais sont rallongés

donc naguère les microcontrôleur faisaient 1Mhz, avaient 64 octets de ram ; aujourd'hui (depuis 5 ans en fait) ils font 240Mhz sur 32 bits, ont 2 cœurs et bézef de ram et de flash : ce n'est, logiquement, plus du tout le même monde
donc amha, on devrait pouvoir construire des bus de genre S88, en enlevant les 4014, soit 2/3 de l'électronique, tout en améliorant la fiabilité des transmissions

7
Bonjour,
dans le cadre de l'article https://forum.locoduino.org/index.php?topic=1097.0
nous avions vu ;
- l'impossibilioté de synchroniser les horloges de plusieurs pca9685
- comment pallier, si on sait, pour un canton de transition, faire la sélection entre les 2 paca9685 encadrants
- la possibilité d'une alternative aux pca9685 (donc pertinente si le nombre de cantons excède 16) à bases de célèbres 74hc595, disponibles en modules tout-fait

les posts qui suivent ont été transférés du sujet "Problème pour utiliser l'horloge externe du PCA9685"

8
Composants / arduino nano : faut-il se dépêcher d'en acheter ?
« le: septembre 05, 2021, 11:32:46 am »
Bonjour,
c'est en passant commande pour des nouveaux avr que je me suis rendu compte d'une indisponiblilté durable - 1 an - de ces produits microchip
le covid et la pénurie mondiale de semiconducteurs sont passés par là
pour les atmega328p chers à nos uno, nano, micro, c'est pareil
le microcontrôleur coutait 1€50 du temps de sa disponibilité, c'est 3-4€ maintenant
il serait logique que cette hausse de prix et cette pénurie touchent aussi les arduino à base de ces atmega : pour l'instant, il y a encore du stock et des prix corrects : si vous avez des projets dans les ... 2 années à venir, je me permetrais de vous suggérer d'anticiper
affaire à suivre
les prix ont été multipliés par 4 sur beaucoup de produits, et comme la tva s'est ajoutée, ça fait x5 ...

pour ma part, je vai passer sur stm8s pendant cette période (repasser, en fait, je connais) : mais bien que fabriqués en chine, donc en principe non soumis aux aléas de la production occidentale, il subissent quand-même une hausse de tarif par ricochet
j'en ai commandé une cinquantaine pour être tranquile, on verra bien si le vendeur veut les expédier au prix affiché ...

9
Bonjour,
j'avais présenté le projet ici : https://forum.e-train.fr/viewtopic.php?f=18&t=93174
l'interrêt, c'est que la découpe de la cible, la couleur noire du fond, le liseré blanc, et le câblage de la cible viennent avec la fabrication du pcb ; on pourrait commander les pcb avec les leds directement soudées, "plus qu'à" mettre les visières et poser la cible sur le mât ...
comment ça marche ? il y a plusieurs manières de faire, voici la mienne
d'abord, à quoi ressemble le dessin du pcb, devant, et derrière :

10
Vos projets / projet : barrette à led strip rvb
« le: avril 26, 2021, 10:56:22 pm »
bonsoir,
le résultat de ma cogitation de la journée :
le but, c'est d'utiliser un strip rvb du commerce, genre WS2812B, pour pouvoir disposer les leds où on veut et on peut, dans l'axe, sur la longueur d'une voiture voyageurs
sur la pj., la barrette du haut est vue du haut et celle du bas ... du bas
les strips sont sécables, cela permet de les interrompre, si pas besoin de led, ou si il y a une traverse qui gène au niveau de la toiture ; on ne le voit pas, mais les lignes gnd, data et +5v sur la barrette sont étamées, ce qui permet de souder les extrémités de chaque segment de strip ; la ligne data de la barrette est en fait une suite continue de ponts de soudure, interrompus pour éviter de cravater les datas des segments de strip, et sur lesquels on peut facilement faire la continuité de la data entre 2 strips
des pastilles dont disposées régulièrement jusqu'à la fin de la barrette, car celle-ci est sécable, pour pouvoir s'adapter à la longueur des voitures ; ainsi on dispose au droit de l'extrémité coupée de la barrette, de pastilles permettant de raccorder au rail, mettre (au choix de l'extrémité) le condensateur du 15v et le supercondensateur du 5v, ainsi que la suite gnd+data+5v pour pouvoir mettre des leds rvb hors barrette, je pense notamment aux feux blancs et rouges d'une voiture pilote
à la base, le mcu chargé de décoder le dcc n'utiliserait que 2 broches : le dcc et la data des leds ; c'est pour ça que je me suis tourné vers un attiny412 ; ce sera l'occasion pour moi (pour nous ?) de découvrir le nouveau core avr
il reste des broches de libre, alors je les ai affectées : détection ABC (pour quoi faire ?), allumage/extinction par "contact" capacitif (en mode analogique), commande de la charge du supercondensateur

11
Bonjour,
pour signaler l'existance d'un mcu à 99% compatible avec l'ATMEGA328P
il a quelques avantages, notamment de fonctionner à 32MHz au lieu de 16MHz, cela peut être très intéressant si vous avez besoin de + de puissance, vitesse sur un nano ou un mini
j'en ai brièvement parlé ici https://forum.arduino.cc/index.php?topic=729831.0
vous y trouverez les liens utiles

12
Bonjour,
pour vous informer qu'après un bref examen du système C/MRI, je me suis rendu compte du fait que mes cartes décrites :
ici https://forum.locoduino.org/index.php?topic=728.0
et ici https://forum.locoduino.org/index.php?board=11.0
présentent une compatibilité certaine C/MRI / JMRI, alors que ce n'était pas prévu au départ

la carte "TCO en mode analogique" a en effet une interface rs485, et 48 sorties sur 74hc595, dont 40 sont dotées de mosfets pour la commande de moteurs peco ; on doit donc pouvoir la faire tourner sous C/MRI avec un minimum d'adaptations, je pense notamment :
- tenir compte du fait que c'est un micro pro (leonardo)
- utiliser la cdu incorporée, ce qui demande d'attendre la recharge de la capa avant la prochaine commande d'aiguille ; sur la carte ça se fait en mesurant la tension aux bornes de la capa par diviseur de tension et une entrée adc de l'arduino

il n'y a pas de registre à décalage pour lire des entrées, mais avec un peu de code on peut par exemple utiliser l'i2c et des modules mcp23018


la carte "8 relais à 74HC595" peut être commandée par un arduino 'par exemple un nano muni d'une interface rs485, qui peut donc commander 6 cartes à 8 relais
on pourait-même raccorder les cartes "8 relais à 74HC595" à une carte "TCO en mode analogique", (comme c'est prévu "chez moi"), mais ce serait moins léger au niveau au niveau de la programmation


13
Shields et Modules / carte 8 relais à 74HC595
« le: mars 03, 2020, 07:37:00 pm »
Bonjour,
abondance de biens ne nuisant pas, je vous propose cette carte destinée à alimenter (ou pas) les zones d'arrêt d'un réseau analogique


les points particuliers sont :
- alim en 5V, y compris les relais pour simplifier
- seul le contact travail est sorti, il peut avoir pour origine au choix le rail de gauche ou de droite, par pont de soudure
- registre 74HC595 pour simplifier le câblage et permettre le chaînage de plusieurs modules
- ULN2803 pour simplifier la vie
- pas de LED ni d'optocoupleur

14
Le logiciel DCC++ / DCC++ avec ESP32 ?
« le: octobre 05, 2019, 08:08:01 pm »
Bonjour,
juste pour vous dire que j'ai écrit un bout de code qui pourrait servir de petit début à une station dcc animée par un esp32

le but est de générer des bits 0 et 1 en dcc, selon un principe proche de celui utilisé pour dcc++

explication :
un bit dcc ressemble à une période pwm, dont la durée est 200µs pour le bit 0 et 116µs pour le bit 1, le rapport cyclique étant dans tous les cas 1/2 ... simple ...
il faut donc après l'émission de chaque bit dcc, générer une interruption au service de laquelle on indiquera au timer la prochaine période à respecter : si la valeur du bit dcc change, on rentre la nouvelle période (200 ou 116µs) ; si la valeur du bit dcc ne change pas, il n'y a rien à faire /// dans tous les cas on dispose de 58µs pour rentrer la nouvelle période, un éternité pour l'esp32

auparavant il faut configurer un canal de timer :
- en pwm
- avec un rapport cyclique de 1/2
- pour qu'une interruption se déclenche à la fin de chaque période

concrètement :
(je suis loin d'être un pro du soft, je me suis débrouillé avec des fonctions dénichées dans le sdk, on peut sûrement faire mieux)

on commence par les déclarations :
// on utilise un module qui s'appelle ledc ... selon la tradition esp32 les modules pwm servent d'abord aux leds ...
#include "driver/ledc.h" // les fonctions spécifiques sont décrites ici

const int dcc_pin = 19;  // choix de la broche dcc out : n'importe laquelle peut être utilisée /// en se servant de la matrice du gpio

// setting PWM properties
#define dcc_sig_1_freq 8621 // le sdk demande la fréquence : celle-ci correspond à ~116µs ... quelque chose arrondira à la valeur exacte
#define dcc_sig_0_freq 5000 // 200µs (ici j'utilise des macros pour définir ces constantes)
const int dcc_pin_channel = 0; // il y a foison de canaux pwm, j'ai choisi le 1er
const int dcc_sig_resolution = 1; // nombre de bits définissant la résolution du pwm ; ici un seul bit (2 valeurs différentes) suffit
/// la résolution, c'est la granulométrie du rapport cyclique : la + grosse (ne) permet (que) de faire du 50%
const int dcc_sig_duty = 1; // pour le rapport cyclique de 1/2 il faut la valeur 1 (si non c'est 0 ... )
// initialisation de la variable au bit dcc 0 ; why not ; noter que la fonction utilisatrice veut le type uint32_t pour la fréquence
uint32_t dcc_sig_freq = dcc_sig_0_freq;

et voici le setup :
void setup() {
  // configuration du canal pwm 0 avec une fréquence et la résolution
  ledcSetup(dcc_pin_channel, dcc_sig_freq, dcc_sig_resolution); // ledc les faire ...
  // relie le canal pwm à la pin choisie pour la sortie pwm /// ... et dcc par conséquent
  ledcAttachPin(dcc_pin, dcc_pin_channel); /// ! pour détacher (si besoin), il faut impérativement passer par la matrice gpio
  // fixe le rapport cyclique du canal à 1/2
  ledcWrite(dcc_pin_channel, dcc_sig_duty);
  // programme l'interruption à la fin de la période
// je n'ai pas trouvé de manière élégante pour le faire avec le timer, alors je me suis rabattu pragmatiquement sur une interruption provoquée ... par le basculement de la pin
  attachInterrupt(dcc_pin, dcc_sig_isr, RISING); // l'interruption "dcc_sig_isr" provoquée à la fin de chaque période (voire au début de la suivante)
}

et l'isr :
pour vérifier le fonctionnement je génère une suite de 0/1/0/1 ad lib
il faudra adapter pour dcc++
void dcc_sig_isr() {
  if (dcc_sig_freq == dcc_sig_0_freq) dcc_sig_freq = dcc_sig_1_freq ; // inverse la valeur du bit dcc précédent
  else dcc_sig_freq = dcc_sig_0_freq ;
// la fonction qui permet d'écrire la nouvelle fréquence demande :
// - le mode : ici high speed, (au pif) qui va bien
// - le timer utilisé : j'ai supposé bêtement que le canal pwm 0 correspond au timer pwm 0 /// je crois qu'il y a 2 canaux par timer
// - la fréquence, of course
  // ledc_set_freq(ledc_mode_tspeed_mode, ledc_timer_ttimer_num, uint32_t freq_hz)
  ledc_set_freq(LEDC_HIGH_SPEED_MODE, LEDC_TIMER_0, dcc_sig_freq); // new -or not - period value
}

pour ceux qui veulent vérifier, un petit main qui fait travailler l'esp32 :
void loop() {
  delay(10); // mettez ici ce que vous voudrez
}


les mesures réalisées donnent des résultats très corrects : il manque parfois 41ns à une période. Peut-être mon modeste matériel, en tous cas, je n'ai pas les moyens d'en trouver la cause, et on est de toute façon largement dans les clous


 

 

15
Shields et Modules / TCO en mode analogique, avec pcb
« le: mars 02, 2019, 08:43:24 pm »

Bonjour,

ce projet fait suite à un besoin particulier, pour la réalisation de 4 (au minimum) postes d'aiguillages en H0, 2 sont équipés de moteurs d'aiguille peco, les 2 autres de moteurs mtb. Le mode est analogique, mais c'est évidemment compatible avec une commande des trains en dcc ou autre

afin de ne pas encombrer avec un sujet qui par sa nature suscite relativement peu d'intérêt, je ne ne donne que quelques éléments ici. Les personnes souhaitant voir + de détails peuvent consulter le blog dédié

je ne suis pas un spécialiste de l'arduino, mais agissant au sein d'un club de mf, ce choix s'est imposé pour que le projet soit accessible au + grand nombre

les tco assurent la prise en compte de boutons poussoirs d'itinéraires, ainsi que l'affichage des voyants leds indiquant les itinéraires formés et les positions des aiguilles. Il n'y a pas de rétrosignalisation de la fin de course, on admet que la commande envoyée a fonctionné, ni de rétrosignalisation de l'occupation des voies. La commande et la sécurité sont de la responsabilité des opérateurs

une carte avec circuit imprimé (pcb) est réalisée pour la partie commande des aiguilles. Les composants sont majoritairement des cms, toutefois très faciles à souder : SO à pas de 1.27mm pour les CI, taille mini 1206 ou SMA pour les 2 pattes
-> mais l'ensemble pourrait très bien être construit avec des modules tout faits du commerce

les synoptiques :
tco pour mtb :



tco pour peco : (la partie purement tco est identique)



les vues 3d des cartes :
(un air de famille avec la Carte 24 entrées 48 sorties pour JMRI)
pcb pour mtb :
voir pj


pcb pour peco :
voir pj


(les méthodes pour insérer des images sont toutes simples : copier l'adresse de l'image après enregistrement, puis modifier, puis coller l'adresse dans la balise img)

prochainement :
photo d'un tco
ultérieurement car j'attends des composants :
photos d'un pcb terminé



* mise en place des images par Dominique  ::)
-> merci, je tacherai la prochaine fois

Pages: [1]