Répondre à la discussion
Affichage des résultats 1 à 10 sur 10

PIC18 EUSART overrun



  1. #1
    Eki27

    PIC18 EUSART overrun


    ------

    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

    -----

  2. Publicité
  3. #2
    RISC

    Re : PIC18 EUSART overrun

    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+
    Ma marotte ? les microcontrôleurs ;=)

  4. #3
    Eki27

    Re : PIC18 EUSART overrun

    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
    Dernière modification par Eki27 ; 11/02/2012 à 16h24.

  5. #4
    DAUDET78

    Re : PIC18 EUSART overrun

    Citation Envoyé par Eki27 Voir le message
    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.
    J'aime pas le Grec

  6. A voir en vidéo sur Futura
  7. #5
    Eki27

    Re : PIC18 EUSART overrun

    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
    Dernière modification par Eki27 ; 11/02/2012 à 16h42.

  8. #6
    DAUDET78

    Re : PIC18 EUSART overrun

    Citation Envoyé par Eki27 Voir le message
    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
    J'aime pas le Grec

  9. Publicité
  10. #7
    Eki27

    Re : PIC18 EUSART overrun

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

  11. #8
    RISC

    Re : PIC18 EUSART overrun

    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+
    Dernière modification par RISC ; 11/02/2012 à 17h15.
    Ma marotte ? les microcontrôleurs ;=)

  12. #9
    Eki27

    Re : PIC18 EUSART overrun

    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

  13. #10
    paulfjujo

    Re : PIC18 EUSART overrun

    bonsoir,

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

Discussions similaires

  1. Programmation microcontrôleur PIC18
    Par Amine_34 dans le forum Électronique
    Réponses: 12
    Dernier message: 27/08/2010, 14h21
  2. audio record - pic18
    Par jahcooik dans le forum Électronique
    Réponses: 4
    Dernier message: 17/12/2009, 17h59
  3. Carte PIC18 WIFI
    Par microchip dans le forum Électronique
    Réponses: 1
    Dernier message: 23/12/2008, 06h23
  4. Dérive PIC18
    Par hackduc dans le forum Électronique
    Réponses: 18
    Dernier message: 12/09/2008, 16h31
  5. programmation PIC18
    Par leader00 dans le forum Électronique
    Réponses: 1
    Dernier message: 22/03/2007, 17h39
Découvrez nos comparatifs produits sur l'informatique et les technologies.