[nRF24L01+] communication rapide duplex

Marsh Posté le 31-05-2021 à 19:06:21

Bonsoir,

après je ne sais combien d'heures à me faire chier je désespère vraiment et je viens demander de l'aide ici. Avis aux connaisseurs des nRF24L01+. Désolé pour le pavé, c'est un poil compliqué...

J'explique: J'ai deux PCB, chacun équipé d'un AVR et d'un module nRF (et d'autres bidules, peu importe).
Le premier PCB, appelons le "maître", fonctionne en 5V avec un régulateur linéaire pour le nRF (qui a des entrées qui supportent 5V et MISO je le passe à travers un convertisseur de niveaux 74HCT vers 5V). Le nRF est un module taille standard avec connecteur THT. Il y a un quartz 18,432MHz sur le AVR.
Le deuxième PCB, "esclave", fonctionne en 3,3V, tout en CMS et avec la version miniature du nRF qui est interfacé directement. Le quartz est de 9,quelque MHz (maxi 10MHz en 3,3V pour les AVR!).

L'idée finale c'est de transmettre des données dans les deux sens avec dans chaque sens une quinzaine de kilo-octets par seconde. Comme les modules ne font pas le full-duplex il y a un "Transmit Token" que les deux AVR se renvoyent, celui qui a le Token émet un paquet (pour l'instant vide, j'ai testé 16 oct et 32 oct, pour des raisons je dois rester sur un multiple de 16) et se met ensuite en mode RX. Je dois/veux écrire le code en partant de zéro, donc exit les Arduino et autres libs pris sur internet et qui constituent la majorité des résultats Startpage...

En principe cela est assez simple et fonctionne en mode "basse vitesse", mais il y a une grosse contrainte: Sur l'esclave et pour des raisons que je ne peux changer je ne peux occuper le bus SPI en continu que pendant 120µs environ (car ensuite il faut communiquer avec un autre bidule branché sur le même bus). Et je dois aussi, pour des raisons de latence et de RAM, avoir un "turnaround" très rapide. Mon but c'est d'avoir un paquet "TX-Token" (+ données éventuellement) maxi tout les 625µs. Je sais, c'est sportif mais un calcul me dit qu'un cycle TX à 2Mbps avec auto-ack et retransmit si nécessaire fait 530µs, donc ça devrait être faisable.

Sauf que: Ben non. Au bout de quelque échanges (entre 1 et >100) de "Token" la communication finit par planter. Actuellement (=avec le code du moment et la météo du jour) c'est l'esclave qui geule "MAX_RT is set", autrement dit l'esclave a envoyé un paquet de données à plusieurs (3 maxi) tentatives mais n'a pas reçu de ACK du maître. Je ne peux pas permettre plus de tentatives car - ben oui, pas le temps...

Le soucis c'est que vu les contraintes de temps je ne peux pas simplement mettre des printf partout évidemment. J'ai deux broches de libres sur chaque AVR que je peux utiliser pour débugger, un scope 2 entrées seulement (hélas!) et un analyseur logique clone Salae (8 entrées, 24MHz).

Ce que j'ai déjà fait/tenté/...:
-rajouté 22µF (chimique, mesuré 18µF avec un ESR 2,xy Ohm) sur le module nRF THT. Le module CMS c'est plus délicat, il est branché avec des fils de 2cm environ et sur le PCB il y a 100p, 100n et 10µ céramiques.
-utilisation de la broche INT plutôt que de faire du "polling" du registre STATUS pour savoir si la transmission est terminée etc, il paraît que ça rend le nRF instable (info trouvée quelque part sur internet)
-baissé les vitesses SPI sous les 8MHz, le nRF24L01+ est censé supporter 10MHz plutôt que 8MHz pour l'ancienne version, mais bon, modules chinois toussa...
-testé différents canaux (bande ISM, Wifi, toussa)
-1001 modifications du code, des heures avec le scope/LA à vérifier les timings, avalé 3 boîtes de calmants, ...

Je me pose plusieurs questions:
-L'utilisation de la broche CE. En mode TX il faut l'activer pour au moins 10µs (délai 11µs dans mon code) pour démarrer une transmission; mais pas pour plus de 4ms (?). En mode RX il n'y a pas de limite logiquement ??? Faut-il, en mode RX, mettre CE à zéro dès que INT passe à l'état bas, autrement dit avant même de lire le registre STATUS pour savoir ce qui c'est passé ou pas???
-Quelles sont les autres contraintes de timing à respecter? J'ai lu la doc x fois, à priori je respecte tout, y compris les fameux 130µs de settling, mais il y a peut-être un truc qui n'est pas spécifié? Si j'ai bien compris TX_DS est mis à 1 (et donc INT à 0) AVANT l'envoi du ACK, j'ai bon? C'est complètement stupide, car j'ai tendance à désactiver CE dès que le module me dis "j'ai envoyé les données"...
-Comment savoir si c'est le PRX qui n'envoye pas de ACK ou le PTX qui ne le reçoit pas??? Je n'ai pas d'analyseur de spectre ni de SDR ou autre chose qui permettrait de répondre à cette question. Une astuce?

Pour illustration, voici un extrait de la dernière capture LA:
-CE_* représente directement l'état de la broche du même nom sur chaque PCB. L'impulsion brève (11µs) est un envoi, l'état haut pendant longtemps c'est le mode RX
-UART_SLAVE est utilisé QUE en cas de platage de la com' car 9600 c'est lent...
-ERRFLG_MASTER change d'état si le maître se retrouve avec une erreur (MAX_RT)
-RXDFLG_MASTER change d'état à chaque réception du Token par le maître

Je peux fournir d'autres détails voir des extraits de code aussi. Merci déjà à ceux qui auront tenu jusqu'ici. :jap: Je suis vraiment à deux doigts de fout tout ça par la fenêtre.