[PIC18F]-module USART - problème avec le bit OERR

[jorg1n]

Bonjour,

voila je rencontre un problème, j'ai développé un petit système intégrant un module de communication (RS485/Protocole MODBUS).
Seul, l'esclave (n°1)communique correctement avec le mettre, mais dès qu'un autre esclave (n°2)vient se connecter sur le réseau, le n°1 ne communique plus, et la communication se bloque, et j'ai observé que le bit OERR pas à un, et elle se réactive que si je fais passer CREN à 0 puis à 1, mais cela ne résout pas mon problème...
Comment le bit OERR peu passer à 1?
Et comment empêcher ce bit de passer à 1?

Merci d'avance et bonne soirée a tous
-----

[jorg1n]

Bonjour,

personne n 'a déja eu a faire a ce bit OERR?

Merci d'avance

[jorg1n]

Alors là... Bon bein je crois que je vais me débrouiller seul alors!!!

Si toutefois quelqu'un avait une idée... Un grand merci a lui...

Bonne journée a tous

[schmo]

salut,

Le bit OERR passe à 1 lorsque les buffers de reception de l'uart sont plein. Tu aurais apparement un probleme de timming de lecture de l'uart.
L'uart peut recevoir 2 octets dans le buffer interne et être en train de recevoir un troisième. Si tu ne vas pas lire le registre RCREG, l'uart positionne le bit OERR pour indiquer le débordement..
Aprés ta trame modbus est peut être recue à moitié, ton esclave est désynchroniser. (Il est peut être judicieux de prévoir un temps d'attente maxi entre 2 octets recu. Si le temps est expiré, tu considére la trame reçue comme erronée, et tu te prépare à recevoir la prochaine correctement.)
Il est impératif de réagir aussi rapidement que possible à l'interruption RCIF indiquant qu'un octet à été reçu..

[A voir en vidéo sur Futura]

[jorg1n]

Bonjour ,

et merci schmo pour ce petit coup de pouce...

Pour ma part, dès que j'ai une réception signalé par le flag RCIF, ça créer une interruption, et je stocke la trame reçue dans un tabeau (opération réalisée dans l'interruption) , et je traite ensuite dans mon main mon tableau nommé buffer ...

Je compte éclaircir la chose en mode Debug et voir a quel moment le bit OERR passe a 1 (RISC m'a dit que cela était possible, je vais voir comment faire..)

Par contre, si tu as une manière de faire "carré" pour gérer une communication, je suis preneur...

Bonne journée a tous..

[schmo]

salut,

Voila ce que je fait en général:
- A chaque reception d'un octet, je vérifie si il n'y a pas d'erreurs de communication (bit FERR et bit OERR). En cas d'erreur d'overrun, l'UART est réinitialisé et la trame en cours de réception est effacée.
- Apres la réception et la mise en buffer du 1er octet de la trame, j'initialise un timer qui sera remis a zéro apres mémorisation de chaque octet reçu.
- Si le timer arrive en débordement, cela indique qu'une trame à été reçue et qu'il faut la traiter (ou l'ignorer si elle est corrompue)
- Ce timer est aussi utilisé lors de la transmission d'une réponse. (débordement ET réponse en cours de transmission indique un bug: on efface tout et on remet l'UART en réception)
- apres le traitement d'une trame correcte, j'éfface le buffer de réception (cela évite qu'il reste un vieux morceau de trame qui pourrait être pris en compte)

Comme tu utilise plusieurs esclaves sur la ligne RS485, il faut que tu t'assure qu'un des esclave ne reste pas bloqué en emmission (dans ce cas il prendrais la main sur la ligne et empecherais l'autre esclave ou le maitre de communiquer)
Le bit OERR peut aussi être affecté si il y a un probleme de baudrate.

j'espère que cela pourras t'aider...

[jorg1n]

Merci pour toutes ces informations...

je vais voir pour améliorer mon soft... merci encore...