1
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« Dernier message par trimarco232 le Aujourd'hui à 05:42:10 pm »Bonjour ,
j'ai des questions (voir des doutes) quant-à la fiabilité d'un tel montage (mais c'est peut-être juste parce que je suis loin d'avoir tout compris) :
- les gens de DCC-EX , c'est des costauds , si on pouvait implémenter le cutout de manière assez fiable dans l'ESP32 , pourquoi ne l'auraient-ils pas fait ?
- c'est le RMT qui est utilisé , car il permet de dérouler le packet indépendamment des errances des cores
- à la fin d'un RMT , il faut recharger les données (pour le packet suivant) , dans le cadre d'une interruption : il vaut mieux que cette interruption se fasse au cours d'un bit dcc 0 , par exemple le packet start bit , car c'est le moment où on peut se permettre des libertés dans les délais , moyennant le stretch de ce bit , ce qui est permis par la norme
- ce code créé plusieurs approximations dans le timing :
- - la latence de l'interruption : 4 à 8us , et pire si des opérations wifi sont en cours
- - les delayMicroseconds() , c'est pas des sciences exactes , en particulier pour un ESP32
- - le digitalWrite , pareil
.
donc , je ne doute pas que tu trouves des signaux acceptables à l'analyseur logique , mais qu'en est-il quand l'ESP32 est un peu sollicité , notamment s'il fait des opérations wifi ?
j'ai des questions (voir des doutes) quant-à la fiabilité d'un tel montage (mais c'est peut-être juste parce que je suis loin d'avoir tout compris) :
- les gens de DCC-EX , c'est des costauds , si on pouvait implémenter le cutout de manière assez fiable dans l'ESP32 , pourquoi ne l'auraient-ils pas fait ?
- c'est le RMT qui est utilisé , car il permet de dérouler le packet indépendamment des errances des cores
- à la fin d'un RMT , il faut recharger les données (pour le packet suivant) , dans le cadre d'une interruption : il vaut mieux que cette interruption se fasse au cours d'un bit dcc 0 , par exemple le packet start bit , car c'est le moment où on peut se permettre des libertés dans les délais , moyennant le stretch de ce bit , ce qui est permis par la norme
- ce code créé plusieurs approximations dans le timing :
- - la latence de l'interruption : 4 à 8us , et pire si des opérations wifi sont en cours
- - les delayMicroseconds() , c'est pas des sciences exactes , en particulier pour un ESP32
- - le digitalWrite , pareil
.
donc , je ne doute pas que tu trouves des signaux acceptables à l'analyseur logique , mais qu'en est-il quand l'ESP32 est un peu sollicité , notamment s'il fait des opérations wifi ?