PIC18 EUSART overrun

[invite51e48a05]

Hello,

Je tente de faire communiquer 2 MCU (dont 1 PIC18F16K20) de manière asynchrone à 9600 bauds.

coté PIC, l'EUSART est configuré et la transmission (TX) s'effectue correctement. Le MCU comprend parfaitement les instructions du PIC.

Une interruption (high) est déclenchée si PIR1bits.RCIF vient à 1 (détection RX).
Dans le gestionnaire de cette interruption, je lis RCREG pour vider le buffer d'entrée de l'EUSART, cependant RCSTA.OERR s'active presque immédiatement après les premiers caractères reçus et bloque donc la suite de la lecture.

Comment écrire correctement la routine de gestion d'interruption RX afin d'éviter ces erreurs de dépassement du buffer (qui je pense peut contenir seulement 2 caractères au maximum)?

J'ai tenté d'augmenter la vitesse de fonctionnement du pic au maximum (16Mhz avec l'oscillateur interne), car j'ai cru que celui ci n'était pas assez rapide... cela ne solutionne pas le problème d'overrun.

Auriez vous des exemples fonctionnels de réception eusart asynchrone sur PIC18 (C18), ou bien quelques idées pour debbuger ces erreurs d'implementation de communication?

Merciiiiiiii d'avance
-----

[RISC]

Salut Eki,

Tout d'abord le PIC18F16K20 n'existe pas...il s'agit soit du PIC18F26K20 ou PIC18F46K20 ?

Tu as oublié une chose TRES importante : l'oscillateur interne de ce PIC n'est PAS ASSEZ PRECIS pour fait une liaison UART qui nécessite un oscillateur à +/- 2% MAX
Lis la datasheet et tu verras la déviation de l'oscillateur interne est supérieure.

Il faut donc utiliser soit un résonateur céramique, soit un quartz...ou une salle super thermostatée à 25C car la déviation de l'oscillateur interne est garantie à +/- 1% max à 25C...mais elle augmente dès que tu t'écartes de cette température.

a+

[invite51e48a05]

Hello Risc ,

effectivement, je voulais parler du PIC18F26K20, merci.

Oui, j'avais vu l'info à propos de la faible qualité de l'oscillateur interne, mais je souhaiterais en savoir plus sur les conséquences de l'imprécision au point de vue de l'usart car je ne pense pas que ce soit réellement un problème (sauf s'il est IMPOSSIBLE d'échanger le moindre byte sans erreur).

Je compte utiliser un protocole en couche supérieure qui supervisera la communication, ou les chaines erronées seront relancées, et les chaines valides seront acquittées... dans le pire des cas je perdrai quelques dixièmes de secondes sur certaines communications...
Je peux aussi envisager de récupérer la température via un capteur afin d'ajuster SPBRG dans les situations extrèmes...

Je ne vois pas la cause à effet avec mon souci d'overrun (qui semble plutot etre un problème de logique ou de vitesse de réaction), toi oui ?

Eki

[invitee05a3fcc]

Je compte utiliser un protocole en couche supérieure qui supervisera la communication, ou les chaines erronées seront relancées, et les chaines valides seront acquittées... dans le pire des cas je perdrai quelques dixièmes de secondes sur certaines communications...

Complétement illusoire ....
Si ton générateur de baud est différent de quelques pour-cents (de mémoire 4%), toutes tes transmissions seront pourries et ça ne sert à rien de relancer une trame identique qui sera autant pourrie à la réception.

[A voir en vidéo sur Futura]

[invite51e48a05]

Merci pour cette réponse constructive

Et mon mot au sujet du capteur de température est tout aussi illusoire?
Sinon, ok j'ai compris l'oscillateur interne n'est pas adapté pour ce job! Mais immaginons un monde parfait ou il fait toujours 25°, pensez-vous que mon problème d'overrun soit solvable?

Eki

[invitee05a3fcc]

pensez-vous que mon problème d'overrun soit solvable?

Evidemment ! C'est un problème de soft et de gestion de la lecture de l'UART en interruption. Mais là, je ne peux t'être d'aucune aide.

Si ton problème était insoluble ..... on ne pourrait jamais faire une transmission en RS232

[invite51e48a05]

Ah ben voilà, je me sens déjà beaucoup mieux... merci pour ta précieuse intervention !

[RISC]

Salut,

L'overrun peut être du à différentes causes....par exemple ton programme

Je te recommande d'utiliser un exemple de code pour les PIC18 : http://www.microchip.com/codeexamples (il y en a surement un pour l'UART).

Il existe également une paire de bugs sur l'UART (s'il est récent) : lis bien l'erratasheet du PIC18F26K20. Il y a un workaround pour nettoyer le bit overrun...

Logiquement, à température ambiante tu devrais arriver à faire fonctionner l'UART sur l'oscillateur interne si tu n'as pas effacé la valeur de calibration usine de l'oscillateur du PIC.

As-tu un schéma de ta carte ?
Quel outil utilises-tu ?
Quelle datecode as-tu sur le PIC (10xx,11xx,12xx) ?

a+

[invite51e48a05]

Merci encore Risc,

je vais aller potasser tout cela...
Je n'utilise pas d'outils supplémentaires (juste C18 dans MPLAB)
Je n'ai pas de schéma encore établi (connexion série classique RXpic -> TXmcu / TXmcu -> RXpic et GND commun)

Je suis en effet persuadé que je me plante lamentablement dans mon code

Le datecode du PIC est 1114DS3

A bientôt

[paulfjujo]

bonsoir,

Il faut utiliser un protocole
genre xon, xoff
ou ack , nack
pour synchroniser les echanges asynchrones ...
ou eventuellement rajouter des delais inter-caracteres