Un récepteur Manchester avec un nombre d'octets précis attendus par la centrale devrait être plus simple que ces récepteurs de télécommande. Ceux là traitent et testent bit à bit pour les valider, détecter les violations, et en extraire des codes, à peu de bits...
Si on attend 1, 2, 4 ou 8 octets, plus une checksum, on sait combien de bits RMT doit recevoir, avec le start bit.
Sauf timeout, dès que RMT a reçu tous les bits attendus, qu'ils sont en RAM,
on ignore le start bit, un bit à 1, inutile de le tester?
on décode les symboles bits, on écrit les octets puis la checksum dans une structure,
éventuellement, on teste au passage les violation Manchester, mais il ne devrait jamais en exister, ce serait du temps CPU perdu
on vérifie la checksum, si elle est invalide, on droppe le paquet...
Edit... ces 3 lignes sont encore trop courtes. Avant la data et le start bit, il y a un préambule. Il faudra donc aussi:
recevoir bits à bits le préambule (par symboles)
tester tous les bits de ce préambule, jusqu'à détection du start bit
ensuite seulement on commence à recevoir la data...
On est donc très éloigné de ce que peuvent faire des UART, périphériques SPI et CAN, en Rx, avec de gros flux de données, sans solliciter la CPU. Avec RMT Rx, la CPU doit tout traiter symboles par symboles, bit à bits, etc.
Si on disposait d'un périphérique hardware dédié à la Rx MFX, ou d'un Tiny dédié, on aurait:
- une interruption pour signifier qu'on a détecté rien qu'une porteuse 52k, jamais de start bit
- une interruption pour signaler que X octets valides sont en RAM (le hardware en aurait validé la checksum)
- une interruption pour signaler qu'il y a eu erreur de transmission (checksum invalide ou timeout, etc)
Reste l'intérêt de RMT Rx pour des messages courts et à bas débit, non susceptibles de trop charger la CPU. Avec du code plus ou moins compliqué, on doit pouvoir recevoir n'importe quel type de données encodées, reçues via un fil/GPIO Rx.
C'est ce qui semble avoir été fait pour la réception de codes IR, de télécommandes. RMT Rx passe les symboles à la CPU, la CPU décode les messages, qui restent courts et occasionnels.
Même dans la doc, je lis que ce n'est pas fait pour des choses trop évoluées ni trop rapides... En mode Tx/Rx, on ne pourrait faire que du half duplex; on aurait à faire du Tx sur un canal, du Rx sur un autre canal. Quand au buffer, il est limité aussi.
The RMT module contains eight channels. Each channel has both a transmitter and a receiver, but only one of them can be active in every channel. The eight channels share a 512x32-bit RAM block which can be read and written by the processor cores over the APB buss, read by the transmitters, and written by the receiver. https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdfThe RMT RAM can be accessed via the APB bus. La doc ne semble pas parler de DMA pour de gros volumes à échanger.
Au départ, donc, une solution pour télécommandes IR (plus télécommandes ou messages courts via RF433MHz). Avec une souplesse, pour permettre toutes sortes d'encodages, à gérer par la CPU. Soit une souplesse pour étendre les capacités I/O de l'esp lorsque les performances vs charge CPU restent en adéquation.
