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.


Messages - Dominique

Pages: [1] 2 3 ... 137
1
Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can
« le: septembre 17, 2021, 04:20:13 pm »
Merci Sébastien.
Maintenant j’ai une base pour expérimenter les autres modes, le mode LOOP n’étant sûrement pas celui qu’il faut dans LaBox

2
Composants / Re : Nouveau ATtiny 417, 814, 816, 817
« le: septembre 17, 2021, 04:16:49 pm »
A titre indicatif, où as-tu commandé ces microcontroleurs ?

Merci d’avance.

3
Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can
« le: septembre 16, 2021, 07:14:29 pm »
Ce que j'ai fait n'est pas sorcier, en partant d'un exemple.
L'IDE Arduino propose un générateur de code morse, moi j'ai pris un exemple de télécommande infrarouge ailleurs sur le web.

Les includes sont tous dans le core ESP32 (aucune bibliothèque à ajouter):
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/event_groups.h"
#include "Arduino.h"

#include "esp32-hal.h"

J'ai ensuite créé une série de bits d'un paquet IDLE qui sera répété indéfiniment.
#define NR_OF_IDLE_BITS 40


///////////////////////////////////////////////////////////////////////////////
// The NMRA DCC Signal is sent as a square wave with each half having
// identical timing (or nearly identical). Packet Bytes have a minimum of 11
// preamble ONE bits in order to be considered valid by the decoder. For
// RailCom support it is recommended to have at least 16 preamble bits. For the
// Programming Track it is required to have a longer preamble of at least 22
// bits. Packet data follows immediately after the preamble bits, between the
// packet bytes a DCC ZERO is sent. After the last byte of packet data a DCC
// ONE is sent.
//
// DCC ZERO:
//    ----------------
//    |      96      |
// ---|     usec     |      96      ---
//                   |     usec     |
//                   ----------------
// DCC ONE:
//    --------
//    |  58  |     
// ---| usec |  58  ---
//           | usec |
//           --------
//
// The timing can be adjusted via menuconfig with the above being the default
// values when using the APB clock.
// Une trame IDLE est émise quand il n’y a pas de trame de commande à envoyer,
// de façon à alimenter continuellement la voie :
// 111111111111 0 11111111 0 00000000 0 11111111 1
//
///////////////////////////////////////////////////////////////////////////////
int IDLE_pattern[NR_OF_IDLE_BITS] = {1,1,1,1,1,1,1,1,1,1,1,1, 0, 1,1,1,1,1,1,1,1, 0, 0,0,0,0,0,0,0,0, 0, 1,1,1,1,1,1,1,1, 1};
rmt_data_t idle_data[NR_OF_IDLE_BITS];
rmt_obj_t* rmt_send = NULL;
et les 2 variables idle_data (les formes de bits à émettre et rmt_send, pointeur nécessaires au driver.

Ensuite, tout est dans le setup:
void setup()
{
    Serial.begin(115200);
    Serial.println("init RMT pin33");
   
    if ((rmt_send = rmtInit(33, true, RMT_MEM_64)) == NULL) // init sur DCC pin = 33
    {
        Serial.println("init sender failed\n");
    }

    /**
    *    Sets the clock/divider of timebase the nearest tick to the supplied value in nanoseconds
    *    return the real actual tick value in ns
    */
    float realTick = rmtSetTick(rmt_send, 1000); // a calculer pour 1 uS
    Serial.printf("real tick set to: %fns\n", realTick);

    int i=0;
    /*
     * Preparation du jeu d'essai : une trame IDLE
     */
    for (i=0;i<NR_OF_IDLE_BITS; i++) {
      if (IDLE_pattern[i]==0) { // UN
        idle_data[i].level0 = 1;
        idle_data[i].duration0 = 96;
        idle_data[i].level1 = 0;
        idle_data[i].duration1 = 96;
      } else {                  // ZERO
        idle_data[i].level0 = 1;
        idle_data[i].duration0 = 58;
        idle_data[i].level1 = 0;
        idle_data[i].duration1 = 58;
      }
    }
    pinMode(32, OUTPUT); 
    digitalWrite(32, HIGH); 
    Serial.println("loop");

    // Send the data
    rmtLoop(rmt_send, idle_data, NR_OF_IDLE_BITS);
}

rmtInit(33, true, RMT_MEM_64) définit la pin de sortie de l'ESP32, le mode émission seulement et la taille du tampon mémoire utilisé.
rmtSetTick(rmt_send, 1000) définit la période des TICKS, ici proches de la microseconde, ce que confirme realTick.

Ensuite la variable Idle_data est garnie avec les valeurs correspondant à chaque bit de la trame DCC
        idle_data.level0 = 1;        // le 1/2 bit haut
        idle_data.duration0 = 96; //aura une durée de 96 uS
        idle_data.level1 = 0;        // le 1/2 bit bas
        idle_data.duration1 = 96; // également 96 uS

Et l'instruction rmtLoop(rmt_send, idle_data, NR_OF_IDLE_BITS) se charge d'envoyer le signal DCC automatiquement et de façon répétitive.

De ce fait tout cet exemple tient dans le setup.

Mais j'aurai pu utiliser dans la loop l'instruction rmtWrite(rmt_send, idle_data, NR_OF_IDLE_BITS) avec les même arguments,
qui pourrait donner les mêmes résultats ou permettre d'émettre des séquences de trames DCC plus complexes.
Mais il vaut mieux contrôler les flux entre le programme et le tampon RMT, probablement comme l'indique Sébastien en utilisant les interruptions disponibles lorsqu'une fraction du tampon est disponible, car la norme DCC nécessite que les émissions soient permanentes pour alimenter le matériel roulant.

Maintenant il faut intégrer ce mécanismes avec toutes les autres tâches (Wifi, Serial, Can, I2C, AnalogInputs, ..)

Mais cela peut nous rassurer pour le moment, en espérant que ce projet puisse intéresser plusieurs contributeurs pour se renforcer  :D ;D

4
Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can
« le: septembre 16, 2021, 02:06:44 pm »
Dans la foulée, un essai valide cette faisabilité mais c'est un exemple qui n'est pas encore intégré avec le reste (donc il peut y avoir des interactions):

La maquette utilisée : LaBox complète avec son booster, connectée au sniffer ESP32.

Les résultats récupérés par msport.

Le code de l'exemple qui ne nécessite aucune bibliothèque.

Je reviendrai sur les détails au retour de mes courses...


5
Vos projets / Re : Train HO avec pilotage par ESP8266 à l'intérieur
« le: septembre 14, 2021, 11:05:32 am »
Dans le dernier numéro de MRH, il y a un nouveau projet de Geoff Bunza qui s’intéresse aux connexions inter-wagons avec des aimants comme connecteurs:
https://model-railroad-hobbyist.com/node/43382#comment-485518

Ça semble applicable au HO uniquement pour le moment mais je vois aussi des applications dans les décors.

6
Vos projets / Re : Re : projet centrale "LaBox" wifi DCC++ Can
« le: septembre 14, 2021, 09:50:37 am »
En revanche, en émission, il possède un mode à buffer CIRCULAIRE qui permet d'injecter un flux en continu dans le système...avec une interruption levée quand une fraction du buffer est consommée (ce qui permet de le recharger).

Je n'ai pas essayé ce mode....mais ça doit le faire.

Merci Sébastien : c’est dans ce mode émission que la solution aux problèmes de timing de LaBox devrait se trouver.
J’ai vu qu’il existe des bibliothèques Arduino à base de RMT. Je n’ai pas pu essayer mais cela doit pouvoir s’implémenter dans l’environnement Arduino.

7
Présentez vous ! / Re : Bonjour à tous
« le: septembre 12, 2021, 06:32:26 pm »
Bravo  ;D

Et pourquoi n’avez-vous pas choisi DCCpp qui offre quelques fonctions supplémentaires ?

8
Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can
« le: septembre 09, 2021, 06:36:26 pm »

9
Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can
« le: septembre 09, 2021, 06:25:07 pm »
UN rapide coup d'oeil sur les exemples montre l'utilisation de l'ESP-IDF.

Comment intégrer un driver RMT dans le code Arduino ?


10
Vos projets / Re : Re : projet centrale "LaBox" wifi DCC++ Can
« le: septembre 09, 2021, 02:39:14 pm »
Si effectivement on arrive pas à générer un signal stable directement avec l'ESP, oui il faut confier ça à un composant externe. Plutot qu'un FPGA j'aurais tendance à garder un petit CPU 8 bits facilement sourçable et que tout le monde sait programmer....

Un petit ATtiny pourrait être retenu (ou un modèle compact plus approvisionnable a moyen/long terme).
Le fait  que le principe des registres dans DCC++ et DCCpp permet de construire et mettre en file d’attente les commandes DCC. Le transfer dans le microcontroleur annexe sans contrainte de temps réel (celui-ci émet des IDLE quand son tampon est vide) soulagerait l’ESP32. Évidemment une nouvelle version du PCB serait à faire.

Dans une version antérieure du projet que j’avais tenté avec un ESP8266, j’utilisais un Nano avec un DCCpp minimal alimenté par des commandes DCC++ via I2C. Là ce serait encore plus simple, je pense. 

11
Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can
« le: septembre 09, 2021, 10:06:09 am »
La question reste posée: comment obtenir cette précision avec l’ESP32, sachant que les moyens de mesures fiables et précis existent maintenant ?
Avec un grand merci à vous deux.

Idéalement la génération des bits devrait se faire à l’extérieur de l’ESP32, avec une sorte de registre à décalage “serie-serie” chargé en I2C, I2S ou PCI, avec un doublement des bits 0 pour conserver une période de 55 uSec partout et un pattern d’IDLE quand le truc n’est pas chargé ou vide. Il faudrait aussi un marqueur de fin de commande car elles ont dès longueurs variable.

Une sorte de FPGA sur mesure ou alors la même fonction a l’intérieur de l’ESP32 mais à l’abri du RTOS.

Qu’en pensez-vous ?

12
Présentez vous ! / Re : Bonjour.
« le: septembre 07, 2021, 08:53:04 am »
 Bienvenue Antonio  :D

13
Vos projets / Re : projet de reseau etagere analogique
« le: septembre 06, 2021, 09:35:09 pm »
Vous pouvez regarder ce sujet tout frais :
https://forum.locoduino.org/index.php?topic=1219.msg13803#msg13803

notamment le programme Configurateur

14
Vos projets / Re : Re : projet de reseau etagere analogique
« le: septembre 06, 2021, 08:34:14 pm »
Bonjour Dominique

J'ai vraiment des lacunes concernant le CAN entre le filtre et l'id
OUI

Citer
Pour moi, le filtre est utilisé pour inhiber la réception de messages inutiles pour le controleur.
OUI

Citer
Par exemple Si j'ai un masque 0x7FF et un filtre à 0x7A0 , je ne recevrai que les messages dont l'id sera 0xA0, toute autre valeur d'id sera ignorée
OUI mais ausi 7A0

Citer
Dans votre exemple
const ACAN2515Mask masque = extended2515Mask (0x1FFFFFFF) ; // For filter #0 and #1
  const ACAN2515AcceptanceFilter filtres [] = {
    {extended2515Filter (0x1FFFFF7A), messageCmd},
    {extended25l15Filter (0x1FFFFF7B), messageCmd},
  } ;
les filtres refletent les ID 0x7A et 0x7B
NON : il n'acceptent que les Ids de messages longs 1FFFFF7A et 1FFFFF7B mais n'émettent surtout pas de messages avec ces Ids

Citer
Si je reprend mon tableau
Le master a pour IDs 01/03/05/07/09/0A/0F (les MASTER_XXXX)
Le tableau des filtres implanté dans le master sera le suivant
const ACAN2515Mask masque = 0x7FF);
  const ACAN2515AcceptanceFilter filtres [] = {
    {0x701, messageAlert}, // Réception alertes depuis les contrôleurs
    {0x703, messageErr},   // notification d'erreurs depuis les contrôleurs
    {0x705, messageOrdre}, // réception des ordres depuis le TCO
    {0x707, messageAck},  // notifications d’acquittement depuis les controleurs
    {0x709, messageAccessoire}, // réception des ordres pour les accessoires
    {0x70A, messageFini}, // notifications de fin d'opérations pour les ordres "longs" (par exemple déplacement d'aiguille)
    {0x70F, messageInfo} // messages d'informations depuis les contrôleurs
} ;

Le TCO a pour Ids 0xF0 (TCO_AFFICHAGE)
Le tableau des filtres implanté dans le TCO sera le suivant
const ACAN2515Mask masque = 0x7FF);
  const ACAN2515AcceptanceFilter filtres [] = {
    {0x7F0, messageAffichage} // Réception commandes d'affichage
} ;
NON: le MASTER, comme le TCO ne reçoit jamais de messages avec les Ids des messages qu'il envoie : 2 entités (noeuds) ne peuvent émettre avec le même Id.
Quand vous écrivez "Le master a pour IDs 01/03/05/07/09/0A/0F ", ça veut dire quoi ? Qu'il envoie des messages avec ces Ids ou qu'il en reçoit avec ces Ids ?

Citer
Le meme principe est appliqué pour les autres types de controleurs :
C'est bien ça qui est à revoir !


Citer
les filtres adaptés en fonction des ID pouvant être reçus par le controleur implanté
OUI ça c'est vrai



Citer
Maintenant, la ou je ne suis pas sur c'est comment doit etre effectué le dialogue dans le programme:
Par exemple le TCO pour transmettre un ordre au master va utiliser la commande CAN.sendMsgBuf en envoyant le message au Master sur l'id MASTER_ORDRE
Mais doit il utilisé l'ID (0x05) ou la valeur de masque (0x705) pour envoyer le message ?
l'Id uniquement (le masque c'est en réception seulement)

Vous n'arrivez pas à séparer l'Id d'un message émis et le filtre d'un message reçu  >:( >:(
Le meilleur moyen est de laisser tomber les masques et filtres tant que vous n'avez pas bien saisi le rôle des Ids

Reprenez votre exemple
Citer
Premier exemple, action sur aiguillage depuis le TCO
utilisateur   TCO   message   MASTER   message   SOLENOIDE
modifie position aiguille n° 7   envoi de l'information au MASTER   ==> MASTER_ORDRE   convertit le numéro de l'aiguille en couple contrôleur/sortie et envoie l'info au contrôleur de solénoide   ==> SOLENOIDE_ORDRE   réception du message
Affichage clignotant de l'aiguille   <== TCO_AFFICHAGE   réception du ACK et demande d'affichage (aiguille en attente)   <== MASTER_ACK   Mise en liste d'attente de la commande (pas d'activation simultanée de solénoïdes)
Affichage fixe de l'aiguille   <== TCO_AFFICHAGE   modification aiguille terminée. On affiche le résultat final sur le TCO   <== MASTER_FINI   L'aiguille a été actionnée
et mettez les valeurs des Ids dans les messages

Montez donc un test comme j'ai proposé, sans utiliser de filtre/masque : vous verrez plus clair ensuite.

Cdt
.

15
Vos projets / Re : projet de reseau etagere analogique
« le: septembre 06, 2021, 12:47:16 pm »
N’oubliez pas qu’il n’y a que 6 filtres par module.

Pages: [1] 2 3 ... 137