Bienvenue aux nouveaux arrivants sur FantasPic !

- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.

--- L’équipe FantasPic ---
Forum général sur le langage C !

Modérateur : Jérémy

Detection fin de trame UART
Jérémy
Administrateur du site
Administrateur du site
Messages : 2722
Âge : 44
Enregistré en : juillet 2015
Localisation : Dans le sud
Contact :

#11 Message par Jérémy » mar. 11 avr. 2017 01:18 lien vers la Data-Sheet : Cliquez ici

Re,

Après une après midi de test, plein d’expérience engrangée !
Par où commencer ???

Connais-tu le maxima de caracteres recus ?

A l'heure actuelle c'est 8 ! mais ce chiffre peut augmenter .

Avec 10ms de time-Out , ca plantait . à 12ms encore un peu de temps en temps . avec 20ms ca ne plantait plus du tout ; J'ai donc mis 40ms :sifflotte:

Je pense que le problème est résolu .

J'en ai profité pour améliorer mon système de vérification de cheksum ! Maintenant il se calcule tout en fonctionner des données réellement reçues et comparé avec l'original .

La donnée est donc validée comme bonne seulement après vérification !

Je ne sais pas si cela intéresse quelqu'un de voir mon code. dites le moi je le posterais ! même si il est commenté , pas évident de comprendre ma façon.

J'ai par contre un autre problème plus compliqué à résoudre ! j'ai du mal a comprendre l'utilisation de RTS ! Ce n'est pas trop le forum pour parler de ça mais peut être que quelqu'un peut avoir une solution .


Voici le contexte:

Un transceiver que j'appelle "centrale" avec un numéro d'ID(N°99) . Ce transceiver est connecté à ma carte easy PIC et dialogue avec un PIC 18F46K22. je me sers ainsi de l'écran LCD connecté à ma carte. c'est lui la centrale du réseau, c'est à dire qu'il doit pouvoir piloter les modules satellites.

J'ai ensuite deux platines de ma fabrication avec chacune le même module radio et un pic 16F1847( plus led et BP pour la mise au point du programme) . Ces deux platines me servent d'émetteur. Appelons les, des satellites, car sur le projet final il m'en faudra 8. eux aussi possède un Identifiant propre ( N°1 et N°2) j'ai fais simple :-D .

Le fonctionnement voulu :
Sur ordre la centrale envoi un broadcast à tous les satellites. Dans ce message , le numéro d'Identifications des modules concernés par le message ainsi que leur actions à faire(la même dans le même message) . Par exemple , satellites N°1, N°3 et N°8 allumez la led verte.
La centrale reçoit aussi des satellites, ce que j'appelle une ligne de vie. pour savoir si le module est allumé, ou a portée radio et m'indique ainsi son RSSI .

Les satellites eux , envoi tous à la même destination d'Identification ( N°99 qui correspond à ma centrale) , un message pour connaitre le RSSI et savoir qi il sont allumés et connectés.
J'indique leurs états de connexion sur mon LCD ainsi que le RSSI .

Donc ma centrale reçoit en permanence les messages des satellites qui sont à sa portée. pour le moment j'ai fais un envoi toutes les 2 secondes pour la ligne de vie. au bout de 5 secondes sans réponses il est considéré comme éteint ou Hors de porté.

Maintenant mon problème !
Par chance ou malchance je sais pas trop comment le dire, j'ai un satellites qui émet sa ligne de vie un tout petit peu plus vite que le second. Par conséquent, il rattrape l'envoi du premier . Ceci à pour conséquence qu'a un certain moment, les satellites émettent exactement au même moment. J'ai donc vu passer sur mon LCD mes satellite à "Off" pendant quelques secondes, avant de reprendre correctement le fonctionnement. j'ai pus reproduire ce moment et c'est toujours pareil, il y a un bug à ce moment précis. Si ca le fait avec 2 modules j'imagine pas avec 8.

Un départ je pensais a une collision radio ! d'mon idée d'utilisé le RTS du transceiver. mais il s'avére que c'est peu etre mon programme qui est trop lent .

En effet j'ai connecter mon cordon RS-232 via Realterm, pour voir ce qui se passait !!! et ben rien du tout ! je n'ai aucun bug de réception; je vois clairement les bytes affichés puis que le satellites N°2 double le satellites N°1 une inversion de l'affichage, ce qui est totalement normal.
Mais aucun BUG !!!!

Par contre mon programme lui bug . Au pire qu'il ne mette pas à jour les données je peux comprendre il attendra la prochaine mise à jour . mais de la à ce qu'il me passe les satellites en Off je ne comprends pas .

Je pense que le problème vient donc de mon programme en reception sur ma centrale ! l'augmentation de la vitesse du baud ou du µC peut eventuellement m'aider à résoudre ceci !

Si vous m'avez lu jusqu'a la , merci déjà . si vous comprenez mon programme chapeau bas !

voici les éléments:

Présentation Module AMB8420

AMB8420_2520_MA_V3_15.pdf


Code d'un satellite : je n'ai qu'a changer l'identification dans les #define pour numéroter le satellite de N°1 ou N°2
La partie Interruptions UART est la même que pour la centrale.
► Afficher le texte



Partie du module "Centrale" qui pose problème lors de la réception très rapide de deux trames consécutives !

► Afficher le texte
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
C'est en faisant des erreurs, que l'on apprend le mieux !!!

Detection fin de trame UART
Jérémy
Administrateur du site
Administrateur du site
Messages : 2722
Âge : 44
Enregistré en : juillet 2015
Localisation : Dans le sud
Contact :

#12 Message par Jérémy » mar. 11 avr. 2017 10:54 lien vers la Data-Sheet : Cliquez ici

Bonjour à tous,

Oups Claudius je n'ai pas fait attention que tu avait posté !

Merci pour l'explication, mais malheureusement je n'ai pas tout compris sur le fonctionnement du TLV ! :oops:

Sinon, pour mon soucis, mes certitudes viennent de s'effondrer !

Je pensais que le temps de traitement des infos reçues était trop long . Oui j'utilise le lcd, donc je dois convertir des valeurs en string ! plus l'affichage LCD et l'effacement qui est plutot long !
DOnc en recevant deux trames piles poils à la suite, je n'ai pas le temps de traiter les infos.

Il y a de fortes chances que le problème vienne de la !

Cependant, j'ai pensé à quelques chose. A la fin de la réception d'une trame complète, j’arrête les INT sur réception UART. Ceci dans le but de me laisser le temps de traiter les infos . Au pire je loupe une trame, ce qui n'est pas trop grave ! car j'en reçoit une toutes les 2 secondes, et que le module détecte une absence au bout de 5 secondes.

Quenini !!! même en arrêtant les INT le bug se produit !

Je pense que j'ai un mauvais timing . je vais essayer en émettant mla ligne de vie toutes les secondes au lieu de 2.
Je vais passer mon PIC à 32Mhz avec PLL enable, pour accélérer le traitement de l'info.
Descendre les bauds ne servirait à rien je pense, car c'est le moment entre 2 réceptions qui doit poser problème.

To be continued....
C'est en faisant des erreurs, que l'on apprend le mieux !!!

Detection fin de trame UART
Jérémy
Administrateur du site
Administrateur du site
Messages : 2722
Âge : 44
Enregistré en : juillet 2015
Localisation : Dans le sud
Contact :

#13 Message par Jérémy » mar. 11 avr. 2017 17:02 lien vers la Data-Sheet : Cliquez ici

Yop,

Je suis tombé sur un OS, en voulant changé la vitesse de 8Mhz avec crystal 8Mhz , à 32Mhz en activant les PLL , l'UART ne fonctionne plus à 9600 bauds! :furieux:

Je vais essayé une nouvelle stratégie pour bufferisé mes datas.

Comme je reçois le numéro identifiant, je vais affecté un buffer propre à chaque satellite suivant ce numero d'ID . Ainsi si le satellites N°1 envoie les données je les écrierais dans le buffer1 si c'est le satellite N°2 dans le buffer2 etc .... Ainsi il ne devrait pas y avoir de chevauchement.
C'est en faisant des erreurs, que l'on apprend le mieux !!!

Detection fin de trame UART
Jérémy
Administrateur du site
Administrateur du site
Messages : 2722
Âge : 44
Enregistré en : juillet 2015
Localisation : Dans le sud
Contact :

#14 Message par Jérémy » ven. 14 avr. 2017 14:38 lien vers la Data-Sheet : Cliquez ici

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 !!

Je vais essayer de généraliser mon problème pour essayer de vous aider , à m'aider ! :-D . Sans parler de pure programmation mais plutôt de chose à faire ou à essayer.

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 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 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...).

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).

Comment faire, pour me permettre de mettre à jour mon affichage sans AUCUN bug ! Je suppose qu'il faut bufférisé tout ca , 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 ca 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 !


Étant à limite programmation et de la radio-fréquence je vais aussi tenter ma chance sur futura ! voir si je peux glaner quelques astuces

PS : FOSC du pic 8 Mhz ; UART à 38400bauds . une trame entière dure moins de 2ms .
C'est en faisant des erreurs, que l'on apprend le mieux !!!


Retourner vers « Langage C »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 50 invités