Bonjour à tous,
J'avoue que mon problème est plutôt compliqué sans avoir les choses sous les yeux ! Mais je n'arrive pas à obtenir le comportement voulu et je ne comprends pas pourquoi !!
Module AMBER8420
AMB8420_2520_MA_V3_15.pdf
Je vais essayer de généraliser mon problème pour essayé de vous aider, à m'aider !. Sans parler de pure programmation mais plutôt de fonction ou chose à faire ou à essayer.
La configuration:
Deux transceivers "esclaves" (Identifiant:1 et identifiant :2) émettent des infos individuellement en permanence toutes les 100ms en direction d'un maitre(Identifiant:99) !
Ces infos (payload) sont composées d'une lettre et d'un chiffre. elles font partie d'une trame sur laquelle le module rajoute l’identifiant de l'envoyeur et un cheksum. Les modules sont configurés de telle sorte que si ils ne reçoivent pas d'ACK de la part du maitre il ré-envoie la trame(10 tentatives) . Après ces 10 tentatives le module esclave poursuit son programme et repart pour un envoi avec 10 tentatives quelques milli-secondes plus tard. etc .....
Le problème:
LE HIC, c'est qu'il arrive, que ces 2 esclaves émettent au même moment, ou tellement proche que l'écart entre les deux trames à l'arrivé ne laisse pas le temps de traiter les informations reçues immédiatement.
Surtout que le traitement de ces informations peut être long, à cause de l'affichage sur un LCD ( conversion Byte to string par exemple, calcul du RSSI etc...).
Les résultats:
Le résultat observé sur un terminal RS-232, sur ce qui arrive sur mon PIC maitre(18F46K22) .
- Je n'ai aucun bug dans une trame complète . Elles arrivent toutes , entière avec les 2 bonnes valeurs de payload .
- Le bug se situe dans l'ordre des ces trames. En effet il arrive au moment de la "pseudo collision" que je reçoive 8 fois de suite la trame N°1. puis 3 fois la N°2 ensuite pour repasser à la trame N°1 . Bref il y a chevauchement des trames . Après quelques chevauchement tout redevient normal ( on a passé la collision).
Qu'il y ai des sautés dans les trames, ce n'est pas trop grave, le plus important c'est que les infos ne soit pas corrompus. Mais comment faire, pour me permettre de mettre à jour mon affichage sans AUCUN bug ! Je suppose qu'il faut bufférisé tout ça , mais j'y arrive pas ou pas assez bien, car j'ai toujours des ratés.
J'ai simulé à 100ms pour deux esclaves, car au final il y en aura 8. Les temps de rafraichissement au final seront plus long pas besoin d'avoir un rafraichissement toutes les 100ms. Mais par contre à 8 , les collisions seront plus fréquentes. C'est pour simuler de nombreuses collision que j'ai mis 100ms !
J'ai également mis en place un système de détection de perte de comm ou d'éloignement.
VIA un timer, je met à jour un compteur propre à chaque esclave avec la valeur du timer. si je détecte que la mise à jour de l'esclave ne s'est pas produite pendant 3 secondes(exemple), c'est qu'il est hors de portée ou éteint ! cela reste secondaire ! J’essaye d'abord d'avoir des données FIABLES, même au moment de la collision.
J'ai eu beau essayé de couper les INT après avoir reçu une trame, mais sa ne change pas le problème, voir ça l’aggrave car l’interruption se redeclenche au milieu d'une trame par exemple.
J'ai aussi essayé de couper la réception radio après une trame, mais pareil que pour les INT .
Je dispose que d"une broche RTS sur les modules radio ! Si j'ai compris son fonctionnement ( ça c'est pas sur du tout) , il ne me servirais à rien dans ce cas de figure ! car je n'envoie pas de donné au transceiver dans cette phase la !
Si il vous manque des infos pour la compréhension dite le moi , je ferais le maximum pour vous les fournir.
PS : FOSC du pic 8 Mhz ; UART à 38400bauds . une trame entière dure moins de 2ms .
-----
).
Envoyé par Seb.26 
