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

USART trop bavard = PIC qui s'y perd



  1. #1
    hoffmann

    Question USART trop bavard = PIC qui s'y perd

    Bonjour,
    Voila un de mes composants envoie constamment des trames en liaison série vers mon pic 18F4520.

    Lorsque mon pic n'est consacré qu'a la lecture de ces trames, tout fonctionne. Mais lorsqu'il veut faire autre chose en plus (les traiter) alors j'ai l'impression que le buffer de réception se remplis et le pic n'arrive plus a lire ensuite les données entrante...

    Comprenez bien que ce qui m'interresse n'est pas de savoir tout ce que le composant raconte dans sa trame. Je veux juste récupérer la dernière trame émise lorsque je le désire.

    J'ai essayé de faire une fonction :
    OpenUsart => lecture de l'info => CloseUsart.

    Mais rien n'y fait... Il perd les pédales...

    Auriez-vous une démarche ?


    A titre d'information voici ma configuration USART :

    OpenUSART( USART_TX_INT_OFF & // TX : Interruption OFF
    USART_RX_INT_OFF & // TX : Interruption OFF
    USART_ASYNCH_MODE &
    USART_EIGHT_BIT &
    USART_CONT_RX & //Quelle est la différence entre réception CONTinu et SINGLE ?
    USART_BRGH_HIGH,
    52 ); // Baud rate : 4800

    Merci beaucoup !

    -----

    Hoffmann

  2. Publicité
  3. #2
    badrbo

    Re : USART trop bavard = PIC qui s'y perd

    Bonjour
    Pour lire les informations qui entre a travers la liaison série UART lorsque le PIC est en train de faire quelque chose ,tu doit utiliser une interruption pour arrêté le fonctionnement du PIC et passer a lire et traiter les information

  4. #3
    hoffmann

    Re : USART trop bavard = PIC qui s'y perd

    Merci pour ta réponse, mais je recherche une solution différente..

    Je ne désire pas connaître tout ce que dit le composant.

    Je souhaite que le micro controlleur puisse quand il le désire écouter ce que le composant envoie.
    Un peu comme l'exemple si après :

    - PIC : écoute la trame et relève une information qui l'intéresse...

    - PIC : fait autre choses (mais l'autre composant envoie toujours des trames, que j'aimerai donc ignorer)

    - PIC : écoute a nouveau les trames... (celle qui arrive... pas les ancienne arrivé en cours de route)


    Le problème est que lorsque le PIC fait autre chose, d'autre données arrivent, et apperement ça doit depasser la taille se son buffer car il ne comprend plu rien lorsqu'il revient a l'écoute...


    Je me suis fait comprendre ou je vous est plus embrouillé ?


    Cordialement
    Hoffmann

  5. #4
    RISC

    Re : USART trop bavard = PIC qui s'y perd

    Salut,

    Il se peut que ton temps de traitement soit trop long...notamment le temps de traitement de l'interruption.
    Pour comprendre comment optimiser le temps de traitement des interruptions en C18 il existe un webseminar dédié.

    Fais-tu fonctionner ton PIC à la fréquence maximum (40MHz) ?

    Concernant les trames, tu as plusieurs possibilités :
    si tu sais exactement combien de caractères tu dois recevoir, alors il utilises un compteur de caractères dans les interruptions, tu lis le caractère (sans le traiter) et tu remets RCIF à 0 et tu ressors aussitot. Une fois que tu as reçus le nombre de caractère AVANT ta dernière trame, tu lis les caractères dans l'interruption.

    Ce qu'il ne faut SURTOUT pas faire c'est d'ignorer les caractères reçus car cela provoquera "l'overrun" après quoi l'UART ne fonctionne plus correctement.

    Un logiciel UART bien fait devrait TOUJOURS tester les bits d'erreur de l'UART AVANT de lire le caractère (à quoi sert de lire un caractère érroné ???)

    a+
    Dernière modification par RISC ; 14/11/2009 à 14h35. Motif: correction

  6. #5
    hoffmann

    Re : USART trop bavard = PIC qui s'y perd

    En fait, je ne travaille pas par interruption du tout...



    Je lis ce qu'il y a....

    je fais autre chose.... (durée variable)

    puis j'aimerai relire le port sans tenir compte des caractères déjà passés entre temps.
    Mais je suis d'accord visiblement j'ai un "overrun".
    Je pensais que jouer avec OPENusart puis closeUsart aurait pu fonctionner mais visiblement pas..


    Je ne travaille pas en interruption car sinon mon programme serait constamment interrompus chose qui n'ai pas utile.

    Avez-vous des idées ?

    Encore merci pour vos réponses !
    Hoffmann

  7. A voir en vidéo sur Futura
  8. #6
    DAUDET78

    Re : USART trop bavard = PIC qui s'y perd

    Citation Envoyé par hoffmann Voir le message
    Je ne travaille pas en interruption car sinon mon programme serait constamment interrompus chose qui n'ai pas utile.
    Et alors? quel est le problème d'être interrompu?
    Un µC est fait pour travailler comme ça et ça t'éviterait ce genre de question.
    J'aime pas le Grec

  9. Publicité
  10. #7
    hoffmann

    Re : USART trop bavard = PIC qui s'y perd

    Disons que comme les trames arrivent régulièrement (GPS NMEA), et que 95% d'entre elle ne m'intéresse pas. je trouvais ça un peu du gâchis d'etre coupé a chaque fois que l'on recevais un caractère.

    Mais si vous pensez que c'est la seule méthode saine. Je testerai ça bientot...

    cordialement
    Hoffmann

  11. #8
    DavidDB

    Re : USART trop bavard = PIC qui s'y perd

    Salut,

    Faire perdre les pédales au µC avec une UART configurée à 4800 bauds, c'est carrément sur-réaliste...

    Faut revoir sérieusement la programmation, et même en polling sans interruption cela doit fonctionner...

    David.

  12. #9
    invite9865321

    Re : USART trop bavard = PIC qui s'y perd

    le mieux est de prendre la datasheet du pic et de regarder quel bit dans quel registre arrete la lecture.

    Tu active le bit quand tu en as besoin.

    Je ne vois pas où est le pb ^^

  13. #10
    RISC

    Re : USART trop bavard = PIC qui s'y perd

    Salut,

    Contrairement à ce que tu penses, il faut faire quelque chose de spécial si tu souhaites pendant un certain temps ne plus écouter la liaison série.
    Si tu reçois des caractères, que tu es en mode réception et que tu ne les traites pas ton UART aura des erreurs (overrun et autres).
    Pour pouvoir de nouveau l'utiliser correctement il faut impérativement la réinitialiser (de tête il y a un bit enable/disable uart) avant d' attendre des caractères.

    Peux-tu confirmer à quelle fréquence tu travailles (Fosc), avec quel oscillateur et si tu as ou non activé la PLL interne (x4) ?

    a+

  14. #11
    hoffmann

    Smile Re : USART trop bavard = PIC qui s'y perd

    Bonjour
    Ca marche !!!!!!

    Je publierai bientôt le code source sur mon site.

    Donc d'après mes tests :
    - si je ne connais pas exactement la taille du buffer RX, mais il suffisait que de quelques secondes de remplissage pour qu'il soit plein.

    - si je ne vide pas le buffer avant qu'il soit plein, l'uart ne fonctionne plus. Il faut sûrement le réinitialisé (non testé)

    Méthode utilisé :
    Open USART
    lecture
    Close USART

    Je ne sais pas pourquoi tout a l'heur ça ne fonctionnait pas...
    Merci pour vos pistes !
    Hoffmann

  15. #12
    badrbo

    Re : USART trop bavard = PIC qui s'y perd

    Bonjour
    je te conseil de voir la datasheet du modem GPS (commandes AT/NMEA), surement tu peut activer ou de désactiver l'envoi successif des chaines NMEA et comme ça le PIC ne sera pas planté

    Open_UART
    Config_Modem_GPS (baud_rate, types des trames, ....)
    activer_GPS
    lire_trames
    desactiver_GPS
    traiter_trames
    ....
    ....
    ....

    Close_UART

  16. Publicité

Discussions similaires

  1. Usart<-----> pic
    Par emileu dans le forum Électronique
    Réponses: 0
    Dernier message: 26/07/2009, 13h46
  2. USART sur PIC 16F628
    Par marcel6566 dans le forum Électronique
    Réponses: 15
    Dernier message: 17/03/2009, 20h53
  3. USART pic
    Par laurentdu38 dans le forum Électronique
    Réponses: 5
    Dernier message: 04/08/2008, 16h47
  4. usart + pic + signaux inversé
    Par KHEOPS1982 dans le forum Électronique
    Réponses: 2
    Dernier message: 08/05/2008, 09h58
  5. USART sur PIC
    Par noisyboxes dans le forum Électronique
    Réponses: 6
    Dernier message: 23/04/2007, 07h39