Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
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.
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/event_groups.h"
#include "Arduino.h"
#include "esp32-hal.h"#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.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);
}
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.
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....
Bonjour DominiqueOUI
J'ai vraiment des lacunes concernant le CAN entre le filtre et l'id
Pour moi, le filtre est utilisé pour inhiber la réception de messages inutiles pour le controleur.OUI
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éeOUI mais ausi 7A0
Dans votre exempleNON : il n'acceptent que les Ids de messages longs 1FFFFF7A et 1FFFFF7B mais n'émettent surtout pas de messages avec ces IdsCode: [Sélectionner]const ACAN2515Mask masque = extended2515Mask (0x1FFFFFFF) ; // For filter #0 and #1les filtres refletent les ID 0x7A et 0x7B
const ACAN2515AcceptanceFilter filtres [] = {
{extended2515Filter (0x1FFFFF7A), messageCmd},
{extended25l15Filter (0x1FFFFF7B), messageCmd},
} ;
Si je reprend mon tableauNON: 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.
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 suivantCode: [Sélectionner]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 suivantCode: [Sélectionner]const ACAN2515Mask masque = 0x7FF);
const ACAN2515AcceptanceFilter filtres [] = {
{0x7F0, messageAffichage} // Réception commandes d'affichage
} ;
Le meme principe est appliqué pour les autres types de controleurs :C'est bien ça qui est à revoir !
les filtres adaptés en fonction des ID pouvant être reçus par le controleur implantéOUI ça c'est vrai
Maintenant, la ou je ne suis pas sur c'est comment doit etre effectué le dialogue dans le programme:l'Id uniquement (le masque c'est en réception seulement)
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 ?
Premier exemple, action sur aiguillage depuis le TCOet mettez les valeurs des Ids dans les messages
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