Dans tout ça il faut largement moduler les "vérités" qui sont lancées ici ou là...
Le traitement des interruptions sur ESP32 donne lieu à une commutation de thread de RTOS et à l'activation d'un contexte....opération relativement lourde d'une part, mais aussi totalement soumise au scheduler de l'OS.
On parle de RTOS donc on est pas trop mal loti, mais il est clair que ça sollicite un mécanisme pas totalement controlé.
Pour générer un flux continu de données contraintes temporellement, on aura plus intéret dans ce cas précis à lancer une tache avec des paramètres de scheduling spécifiques indiquant justement au scheduler que le timing doit etre stricte : c'est à ça que sert RTOS. Une priorité élevée pourra suffire à obtenir un résultat de qualité...possible qu'on arrive au même résultat avec un paramétrage fin de la tache que l'on met en "sticky" pour le gestionnaire d'interruption, mais pas sur...
En revanche, sur un Atmega ou autre ce n'est pas du tout pareil : en dehors du cas ou on a bloqué les interruptions explicitement via "cli", on aura un traitement immédiat d'une interruption déclenchée....sauf si une autre est déjà en cours de traitement.
J'ai traité à l'oscillo lors de mes tests plusieurs systèmes :
- Centrale Lenz LZV100
- Centrale Dgikeijs DR 5000
- Multimouse avec booster ROCO 10764
- Ma Base Station construite avec mon code + Arduino MEGA et carte de booster fournie par msport
Les signaux obtenus sur la Lenz, la DR5000 et la Base Station sont nickels et stables. J'ai d'ailleurs fourni il y a quelques temps une capture à l'oscillo du signal issu de la Base Station.
Les signaux issus de la Multimaus + booster ROCO sont propres dans l'ensemble, mais la centrale insère systématiquement une perturbation (ou un signal à destination d'un autre dispositif, or de la norme DCC). Globalement le décodage "passe au dessus" mais cela fait appel implicitement à un contrôle stricte des bits...car si on "ouvre un peu la tolérance" pour le décodage (par rapport aux spécifications DCC), comme le fait par exemple la lib NMRADCC, on aura un décodage de trames bidons....qui sera ensuite filtré par un mauvais checksum de paquet, mais pas toujours ! (J'ai eu le cas en tests.....)
Je n'ai en revanche pas essayé à ce jour de génération de signal sur ESP32....je n'ai que du décodage à traiter....mais ça peut venir demain, donc si vous voulez un coup de main pour quelques tests, n'hésitez pas.
Bon, tout ça pour dire que le problème ne vient pas du fonctionnement "sous interruption" de façon générale...mais du fait qu'on est sur un système d'exploitation qui "pollue" ce traitement...et que le code sous interruption utilisé sur un ATMEGA marche parfaitement bien, car dans ce cas on a un meilleur contrôle sur le comportement global du CPU.