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

transfert de donnée PC vers Pic



  1. #1
    chestercat

    transfert de donnée PC vers Pic


    ------

    Bonjour

    Je travaille sur un pic 16f877 pour mon projet et je bloque depuis un petit moment sur la transmission série.
    J'ai un programme en vb2005 qui doit envoyé des valeurs au pic par le port serie pour qu'il les stocke dans une eeprom externe.
    Le problème c'est que le pic se bloque lors du transfert, il récupère bien les premiers caractères puis se perd. Je ne trouve pas de solutions, peut-etre que ça vient d'un problème de format de caractère . Mais j'avoue etre un peu perdu.
    Faut-il faire des pauses dans le vb pour laisser le temps au pic de le suivre???

    Merci de votre aide

    Au revoir

    Tig

    -----

  2. Publicité
  3. #2
    mat64

    Re : transfert de donnée PC vers Pic

    il faut que tu arrives à diagnostiquer ce qui se passe par tes propres moyens, il y a tellement de causes possibles...

    Donnes nous quelques infos supplémentaires :
    - vitesse de ta transmission série
    - quel mode de contrôle de flux est utilisé ?
    - fréquence de fonctionnement du PIC
    - quel langage utilises tu (C / asm) ?
    - de quels moyens disposes-tu ? débuggueur ?

    Quelques pistes :
    - l'écriture en EEPROM est parfois lente. est-ce qu'après avoir récupéré les premiers caractères, tu n'est pas bloqué sur l'EEPROM ?
    - comment gères-tu le port série ? tu utilises les interruptions, n'est-ce pas ?
    - pour ton idée de "faire des pauses dans le vb pour laisser le temps au pic de le suivre" : en principe y'a pas besoin, mais ça coute rien d'essayer, ça peut toujours t'apprendre des choses sur le fonctionnement de ton code...

  4. #3
    chestercat

    Re : transfert de donnée PC vers Pic

    Bonjour et merci pour ta réponse,

    Voilà quelques infos supplémentaires:
    Mon pic fonctionne à 20MHz
    Ma liaison série à 9600baud/s
    Le programme est en C, mais je N'UTILISE PAS les interruptions, peut-être devrais-je mais mon projet est à rendre demain soir au plus tard, je suis donc un peu coincé par le temps.

    Quand je fais dérouler les 2 programme pas à pas en cliquant au bon moment sur les envois et réception de data de chaque côté ça fonctionne mais si un des 2 prog tourne de lui même ça bloque au bout du 2ème caractère envoyé.

    J'ai essayé plusieurs choses:
    -augmenter la taille du buffer côté PC
    -ralentir la connexion
    -essayé de renvoyer le caractère reçu avant de recevoir le suivant(peut être faudrait-il continuer dans ce sens)

  5. #4
    freepicbasic

    Re : transfert de donnée PC vers Pic

    De toute évidence le problème est soft , sans le code asm , on ne peut pas trouver grand chose...
    A+, pat

  6. #5
    chestercat

    Re : transfert de donnée PC vers Pic

    J'ai un debuggeur mais pas d'oscilloscope

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

    Re : transfert de donnée PC vers Pic

    Voici mon code:
    Code:
    #include "16F877.h"
    #include <STDLIB.h>
    #fuses HS
    #include <24256.c>        
    #include <ds1307.c>
    #use delay (clock=20000000)
    #use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
    #use i2c(master,sda=PIN_C4,scl=PIN_C3)
    
    #ifndef EEPROM_SDA
    #define EEPROM_SDA  PIN_C3
    #define EEPROM_SCL  PIN_C4
    #endif 
    
    //#define SDA  7   // (pin 28)  --- output-->SDA - I2C Devices..2.7K pullup ACHANGER NUMERO PIN
    //#define SCL 6    // (pin 27)  <--in/out---> SCL   //ATTENTION RESISTANCE PULL_UP SUR SDA
    #define  DEV_DS1307 0xD0  // RTC I2C
    #define impulsion_stop PIN_B4
    #define impulsion_rec PIN_B5
    
    BYTE HeureDate[8];
    //long int m;
    //BYTE heureloc,minloc,jourloc,moisloc;
    char heurdeb;
    char moisdeb,heurfin,minfin,jourfin,moisfin,mindeb,jourdeb;
    Byte hr,min,sec,hl,mil,jl,ml,year,dow;
    char disque,camera;
    int i;
    unsigned char adress_eeprom,adress_max,max_seq;
    char first,second;
    
    void compare_date();
    void choix_camera_disque(int camera,int disque);
    void recup_prog(unsigned char adress_eeprom);
    void mise_heure();
    void INIT();
    void enregister_on();
    void enregister_off();
    void com_serie();
    byte get_bcd();
    
    void main()
    {
       INIT();
       setup_uart(9600);
       while(1)
       {
          if (kbhit()==1)
             {
                com_serie();
             }
          compare_date();
       }
       
    }
    
    void recup_prog(unsigned char adress_eeprom)
    {     
         adress_eeprom=0x00;
         max_seq=getc();          //recuperer le nbre de séquence_max
         delay_ms(100);
         //printf("%c",max_seq);
         for(i=0;i<=max_seq;i++)
         {
         heurdeb=getc();
         delay_ms(100);
         //go=strcat(Heurdeb[1],Heurdeb[0]);
         write_ext_eeprom(adress_eeprom++,heurdeb);//ATTENTION peut etre d'abord recup les données puis ecrire
         delay_ms(100);
         mindeb=getc();                          //eeprom car temps d'accès de l'eeprom
         write_ext_eeprom(adress_eeprom++,mindeb);
         delay_ms(100);
         jourdeb=getc();
         write_ext_eeprom(adress_eeprom++,jourdeb);
         delay_ms(100);
         moisdeb=getc();
         write_ext_eeprom(adress_eeprom++,moisdeb);
         delay_ms(100);
         disque=getc();                              //disque adress_eeprom+4  
         write_ext_eeprom(adress_eeprom++,disque);
         delay_ms(100);
         camera=getc();
         write_ext_eeprom(adress_eeprom++,camera);  //camera adress_eeprom+5
         delay_ms(100);
         heurfin=getc();
         write_ext_eeprom(adress_eeprom++,heurfin);//HEURE DE FIN
         delay_ms(100);
         minfin=getc();                          
         write_ext_eeprom(adress_eeprom++,minfin);
         delay_ms(100);
         jourfin=getc();
         write_ext_eeprom(adress_eeprom++,jourfin);
         delay_ms(100);
         moisfin=getc();
         write_ext_eeprom(adress_eeprom++,moisfin);
         delay_ms(100);
         }
       adress_max=adress_eeprom;
       adress_eeprom=0x00;
    }
    
    void compare_date()
    {
       ds1307_get_time(hl,mil,sec);
       ds1307_get_date(jl,ml,year,dow);
       delay_ms(100);
       HeureDate[0]=read_ext_eeprom(adress_eeprom);  //heure
       delay_ms(100);
       HeureDate[1]=read_ext_eeprom(adress_eeprom++);//min   
       delay_ms(100);
       HeureDate[2]=read_ext_eeprom(adress_eeprom++);//jour
       delay_ms(100);
       HeureDate[3]=read_ext_eeprom(adress_eeprom++);//mois
       delay_ms(100);
       HeureDate[4]=read_ext_eeprom(adress_eeprom++);//heurf   
       delay_ms(100);
       HeureDate[5]=read_ext_eeprom(adress_eeprom++);//minf
       delay_ms(100);
       HeureDate[6]=read_ext_eeprom(adress_eeprom++);//jourf
       delay_ms(100);
       HeureDate[7]=read_ext_eeprom(adress_eeprom++);//moisf
       delay_ms(100);
       
       if(hl==HeureDate[0] && mil==HeureDate[1] && jl==HeureDate[2] && ml==HeureDate[3])
          {
             enregister_on();
          }
          else if(hl==HeureDate[4] && mil==HeureDate[5] && jl==HeureDate[6] && ml==HeureDate[7])
          {
             enregister_off();
          }
    }
    
    void mise_heure()
       {
            unsigned char h,m,j,mo;
            h=getc();
            delay_ms(100);
            m=getc();
            delay_ms(100);
            j=getc();
            delay_ms(100);
            mo=getc();
            delay_ms(100);
            ds1307_set_date_time(j,mo,8,1,h,m,0);
       }
    
    void choix_camera_disque(camera,disque)
       {
          switch(camera){
          case 1:  output_low(PIN_A4);
                   delay_ms(100);
                   output_high(PIN_A3);
                   delay_ms(100);break;
          case 2:  output_low(PIN_A3);
                   delay_ms(100);
                   output_high(PIN_A4);
                   delay_ms(100);break;}
           
          switch(disque) {
          case 1:  output_low(PIN_A1);
                   delay_ms(100);
                   output_low(PIN_A2);
                   delay_ms(100);
                   output_high(PIN_A0);
                   delay_ms(100);break;
                   
          case 2:  output_low(PIN_A0);
                   delay_ms(100);
                   output_low(PIN_A2);
                   delay_ms(100);
                   output_high(PIN_A1);
                   delay_ms(100);break;
                   
          case 3:  output_low(PIN_A0);
                   delay_ms(100);
                   output_low(PIN_A1);
                   delay_ms(100);
                   output_high(PIN_A2);
                   delay_ms(100);break;}
       }
       
    void enregister_on()
    {
       output_low(PIN_C1);  //pour le test allumer la led
    }
    
    void enregister_off()
    {
       output_low(PIN_C2); 
    }
    
    void com_serie()
    { 
    unsigned char receive;
    
              receive=getc();
              delay_ms(100);
              if(receive=='m')
                   {
                      mise_heure();
                   }
              if(receive=='t')
                   {
                      recup_prog(adress_eeprom);
                   }      
    }
    
    void INIT()
    {
       adress_eeprom=0;
       adress_max=0;
       max_seq=0;
       heurdeb[0]=0;
       heurdeb[1]=0;
       mindeb=0;
       jourdeb=0;
       moisdeb=0;
       heurfin=0;
       minfin=0;
       jourfin=0;
       moisfin=0;
       
    }
    
    byte get_bcd() {   // **** version get_bcd originale pour  rs232 
    
    
    do { 
    first=getc(); 
          } while ((first<'0') || (first>'9')); 
          //putc(first); 
          first-='0'; 
      
          do { 
            second=getc(); 
          } while (((second<'0') || (second>'9')) && (second!='\r')); 
          //putc(second); 
      
          if(second=='\r') 
            return(first); 
          else 
               return((first<<4)|(second-'0')); 
        }

  9. Publicité
  10. #7
    mat64

    Re : transfert de donnée PC vers Pic

    Citation Envoyé par chestercat Voir le message
    Mon pic fonctionne à 20MHz
    Ma liaison série à 9600baud/s
    je fais fonctionner des liaisons séries 115kBauds sur des pics à 15 MHz sans souci : donc aucune raison que le pic ne suive pas.

    Citation Envoyé par chestercat Voir le message
    Le programme est en C, mais je N'UTILISE PAS les interruptions
    je n'utilise pas le C sur PIC, mais vu la vitesse de ta liaison série, je pense que le surcout du C ne sera pas un problème.
    Par contre pour les interruptions, c'est une très mauvaise idée de ne pas les utiliser. Si un octet arrive sur la liaison série alors que ton prog est occupé (mettons dans une boucle d'écriture EEPROM au hasard), c'est foutu. Il gfaut lire la liaison série sur interruption.

    Citation Envoyé par chestercat Voir le message
    mon projet est à rendre demain soir au plus tard, je suis donc un peu coincé par le temps.
    la solution était pourtant simple : il fallait t'y prendre avant... la on peut rien faire pour toi

    Citation Envoyé par chestercat Voir le message
    Quand je fais dérouler les 2 programme pas à pas en cliquant au bon moment sur les envois et réception de data de chaque côté ça fonctionne mais si un des 2 prog tourne de lui même ça bloque au bout du 2ème caractère envoyé.
    si tu laisses tourner le PIC et que tu envoie les octets au compte goutte avec le PC, ça bloque au deuxième ? y'aurait pas un gros bug dans le prog du pic APRES la récéption d'un octet ? faut suivre en pas à pas.

    Citation Envoyé par chestercat Voir le message
    J'ai essayé plusieurs choses:
    -augmenter la taille du buffer côté PC
    -ralentir la connexion
    -essayé de renvoyer le caractère reçu avant de recevoir le suivant(peut être faudrait-il continuer dans ce sens)
    essayer des trucs au hasard peut parfois permettre d'apprendre des choses sur le fonctionnement d'un programme, mais c'est quand même plus efficace d'essayer de comprendre ce qu'il se passe. soit tu as un gros bug après la réception de l'octet, soit le programme se déroule normalement mais n'est pas prêt pour le deuxième, et la la seule solution c'est la réception série sur interruption. de toute manière traiter tout ce qui est asynchrone sur interruption c'est une bonne idée (c'est fait pour ça...)

  11. #8
    mat64

    Re : transfert de donnée PC vers Pic

    bon, j'ai raté l'échange avec freepicbasic pendant que je rédigeais ma réponse. A la vue de ton prog, et sachant que tu as un débuggueur, je te conseilles;
    1- si suis en pas à pas après la réception de l'octet pour savoir ou ça bloque
    2- tu passes sur interruption, ton programme fait plein de choses qui prennent du temps...

  12. #9
    chestercat

    Re : transfert de donnée PC vers Pic

    ok merciiiiiii

  13. #10
    chestercat

    Re : transfert de donnée PC vers Pic

    en fait il bloque au moment de recevoir le suivant il attend indéfiniment car je pense que l'octet est déjà passé.

    A moins que ce soit le vb2005 qui envoie plus mais ca me parait beaucoup moins probable

  14. #11
    freepicbasic

    Re : transfert de donnée PC vers Pic

    ton prog est temps réel, et tu ne peut pas te permettre de mettre des delayms partout.
    Ta routine de réception doit d'abord bufferisé le message et l'interpréter ensuite.
    s'il s'agit de message ASCII on peut considérer le CR ou LF comme fin de message et a ce moment aller l'interprèter.

    Il serait aussi plus pratique d'avoir un caractère de début ainsi tout caractère
    reçu avant ce début de message serait impitoyablement jeté , de façon a n'avoir dans le buffer un message complet avec début et fin de message.

    Soit on passe par l'interruption pour recevoir.
    Soit la routine la plus utilisée comme delayms est faite maison et poll la réception afin d'aiguiller vers la routine de réception dès l'arrivée d'un nouveau caractère.
    A+, pat

  15. #12
    mat64

    Re : transfert de donnée PC vers Pic

    Citation Envoyé par freepicbasic Voir le message
    Ta routine de réception doit d'abord bufferisé le message et l'interpréter ensuite.
    s'il s'agit de message ASCII on peut considérer le CR ou LF comme fin de message et a ce moment aller l'interprèter.

    Il serait aussi plus pratique d'avoir un caractère de début ainsi tout caractère
    reçu avant ce début de message serait impitoyablement jeté , de façon a n'avoir dans le buffer un message complet avec début et fin de message.
    je trouve que la technique utilisée par modbus est pas mal : au bout d'un timeout on considère que le message est terminé et on interprète.

    Citation Envoyé par freepicbasic Voir le message
    Soit on passe par l'interruption pour recevoir.
    je me tue à le répéter


    Citation Envoyé par freepicbasic Voir le message
    Soit la routine la plus utilisée comme delayms est faite maison et poll la réception afin d'aiguiller vers la routine de réception dès l'arrivée d'un nouveau caractère.
    bon c'est jouable mais c'est quand même un peu bricolo comme solution (avec tout le respect que je te dois freepicbasic)

  16. Publicité
  17. #13
    chestercat

    Re : transfert de donnée PC vers Pic

    est-ce que quelqu'un sait pourquoi il lit 2 caractère toujours 2 jamais un autre nombre

  18. #14
    chestercat

    Re : transfert de donnée PC vers Pic

    Excusez mon ignorance mais j'essaye depuis tout à l'heure de bufferiser les données avant de les lire et je crois pas avoir bien saisi.
    Il faut les stocker comment alors??
    Pourriez vous me montrer rien qu'un mini exemple de routine de bufferisation?

  19. #15
    mat64

    Re : transfert de donnée PC vers Pic

    bufferiser les données avant de les lire ça veut dire placer les octets qui arrivent sur liaison série dans un tableau, et une fois qu'un ensemble cohérent d'octets est arrivé (en jargon réseau on dit une trame), on commence à interpréter le message.

    ça permet de séparer les actions : quand on reçoit, on ne fait pas autre chose, et quand le message est complet, on le traite. Le problème est de savoir délimiter la trame : freepicbasic à donnée une solution (caractères de controle), j'en ais donné une autre (timeout).

    est-ce que quelqu'un sait pourquoi il lit 2 caractère toujours 2 jamais un autre nombre
    tu pose cette question alors que tu affirme toi même un moment plus tôt :

    en fait il bloque au moment de recevoir le suivant il attend indéfiniment car je pense que l'octet est déjà passé.
    On peut pas débugguer à ta place... as-tu au moins tenu compte de nos remarques ? freepicbasic t'as expliqué que tu ne pouvais pas mettre des boucles d'attentes partout (quand tu es dans la boucle, tu ne peut pas recevoir un octet sur la liaison série...à moins d'utiliser les interruptions, mais apparament ça ne te plait pas...)

  20. #16
    chestercat

    Re : transfert de donnée PC vers Pic

    Si je m'exprime simplement pas très bien. J'ai tenu compte de vos remarques bien évidemment je n'ai pas la prétention d'y arriver seul. J'ai enlever les boucles d'attente de mon code et je tente le buffer.

    Ce que je voulais dire dans ma question
    est-ce que quelqu'un sait pourquoi il lit 2 caractère toujours 2 jamais un autre nombre
    C'est est-ce qu'il n'y a pas quelquechose qui fait qu'il peut lire les 2 premiers et pas les autres.
    Pour l'histoire du buffer cette partie du code que j'ai depuis le début est dans l'esprit non? même si c'est pas un tableau:
    je stocke tout dans des variables mais ça change rien.
    Code:
    void mise_heure()
       {
            unsigned char h,m,j,mo;
            h=getc();
            m=getc();                
            j=getc();                
            mo=getc();
            
            ds1307_set_date_time(j,mo,8,1,h,m,0);
       }
    Sinon j'ai trouvé ce code d'un projet très ressemblant au mien et apparemment ça marche mais....???
    Code:
    void Wait_PC()           //attendre une communication du PC
    {
      while (! USART_Data_Ready())
      {
      asm nop;
      }
    }
    if (receive==2)         //modifier l'heure
          {
          Wait_PC();
          jour=Usart_Read();
          Wait_PC();
          heure=Usart_Read();
          Wait_PC();
          minute=Usart_Read();
          Wait_PC();
          seconde=Usart_Read();
          WriteTime();             //écrire l'heure dans le DS1307

  21. #17
    chestercat

    Re : transfert de donnée PC vers Pic

    J'ai aussi l'impression que tu penses que je suis un guignol qui veut faire faire le travail aux autres. J'aimerais être clair là-dessus
    la solution était pourtant simple : il fallait t'y prendre avant... la on peut rien faire pour toi
    Ca fait plus d'un mois et demi que je travaille là dessus et je suis partie de rien aucunes connaissances sur les PIC, le C, le VB alors un petit peu d'aide un après-midi dans tout ça c'est pas de la faignantise enfin à mon sens.

  22. #18
    mictour

    Re : transfert de donnée PC vers Pic

    Bonjour chestercat,

    est-ce que quelqu'un sait pourquoi il lit 2 caractère toujours 2 jamais un autre nombre

    De mémoire l’usart reçoit un caractère, le place dans le registre de sortie reçoit le suivant, et se bloque si il n’y a pas eu de lecture entre temps.
    Je n’ai pas vérifié dans le datasheet … mais je te conseille de le faire.
    A 9600 bauds il faut 1ms environ pour transmettre un caractère, alors les délais de 100ms !!
    Au minimum il faut un buffer de réception (Alias tableau style char tab [10]
    puis écriture/lecture dans une boucle)… mais il me semble qu’on te l’as déjà suggéré ?
    Bonne soirée, mictour.

  23. Publicité
  24. #19
    chestercat

    Re : transfert de donnée PC vers Pic

    Merci mictour de ta réponse
    oui on me l'a suggéré mais alors si j'ai bien compris je dois avoir quelquechose comme ça:
    Code:
    for(i=0;i<10;i++)
    {
          tab[i]=getc();
    }
    et plus loin dans une autre fonction je traiterais ma tab[i].

    Bonne soirée à toi aussi.

  25. #20
    mat64

    Re : transfert de donnée PC vers Pic

    Citation Envoyé par chestercat Voir le message
    J'ai aussi l'impression que tu penses que je suis un guignol qui veut faire faire le travail aux autres. J'aimerais être clair là-dessus

    Ca fait plus d'un mois et demi que je travaille là dessus et je suis partie de rien aucunes connaissances sur les PIC, le C, le VB alors un petit peu d'aide un après-midi dans tout ça c'est pas de la faignantise enfin à mon sens.
    mais remarque c'était pas pour dire que t'es un fumiste qui veut faire faire son travail aux autres, c'était pour dire que demander de l'aide sur un sujet pareil la veille de l'échéance, c'est trop tard. Comme tu le vois il y a du monde ici plein de bonne volonté : si tu t'y étais pris il y a 2 semaine par exemple, tu aurais d'aussi bon conseil, et du temps pour les appliquer et y réfléchir.

    Citation Envoyé par chestercat Voir le message
    Si je m'exprime simplement pas très bien. J'ai tenu compte de vos remarques bien évidemment je n'ai pas la prétention d'y arriver seul. J'ai enlever les boucles d'attente de mon code et je tente le buffer.
    ben si tu le dis pas on peut pas le deviner... on a l'impression que tu poses le même question à répétition depuis ce matin. dis-nous : j'ai essayé ça : ça donne ça, et ensuite : j'ai essayé ci ; ça donne ci... parceque répéter plusieurs fois de suite ; " pourquoi ça bloque au 2ème octet ? " ça fait pas avancer le schmilblik...


    Citation Envoyé par chestercat Voir le message
    Ce que je voulais dire dans ma question


    C'est est-ce qu'il n'y a pas quelquechose qui fait qu'il peut lire les 2 premiers et pas les autres.
    A part les grosses lacunes qu'on a souligné avec freepicbasic, je ne vois pas le point précis qui fait planter. Le truc qui m'échappes c'est qu' apparemment, ça plante toujours au même endroit (après 2 octets, c'est ça ?) Si c'est reproductible, avec le débugueur tu dois pouvoir trouver facilement ce qu'il se passe.

    dernière chose : est-ce que tu as compris oui ou non l'intérêt de travailler sur interruption ?

  26. #21
    chestercat

    Re : transfert de donnée PC vers Pic

    Oui j'ai compris l'intêret des interruptions et j'aimerais vraiment travailler dessus pour bien l'intégrer car mon but pendant mon stage est de progresser et de bien assimiler les bases importantes de la programmation de PIC.
    Ceci dit des instances plus haut placées me mettent la pression pour des résultats et je suis donc partie de mini bout de code retrouvés dans les placards sur un sujet similaire et le gars n'avait pas utilisée les dites interruptions donc pour gagner du temps que je n'ai pas je suis parti tête baissée(comme un idiot je le conçois) dans une communication sans les interruptions en me disant que je m'y replongerai plus tard(pour ma culture personnelle).
    Je suis désolé de m'être emporté mais le stress est en train d'avoir raison de moi.
    Merci en tout cas du temps que tu me consacres.

  27. #22
    mictour

    Re : transfert de donnée PC vers Pic

    …… Oui. Une boucle pour la lecture une autre pour l’écriture dans l’eeprom, ton programme y gagnera aussi en lisibilité, et donc en facilité de debug.
    Mais la réception rs232 de plusieurs caractères sans interruption « pas plus simple !»

    Pour info j’ai retrouvé ceci dans mes docs :

    /* If two (or more) char's are recieved, */
    /* but not read, the reciever will be locked! */
    /* To unlock the reciever, run function OverrunRecover() */

    void OverrunRecover(void)
    {
    char trash;
    trash = RCREG; /* the two char's that locked the reciever */
    trash = RCREG; /* are read and ignored */
    CREN = 0; /* the unlock procedure ... */
    CREN = 1;
    }

    Bonne prog. Mictour

  28. #23
    freepicbasic

    Re : transfert de donnée PC vers Pic

    ça permet de séparer les actions : quand on reçoit, on ne fait pas autre chose, et quand le message est complet, on le traite. Le problème est de savoir délimiter la trame : freepicbasic à donnée une solution (caractères de controle), j'en ais donné une autre (timeout).
    A mon avis un prog sérieux utilise les 2.
    Pour le polling de la réception c'est effectivement un peu bidouille , mais si le pic n'as que ça à faire , pourquoi pas...
    D'ailleurs c'est ce que fait le getc().

    est-ce que quelqu'un sait pourquoi il lit 2 caractère toujours 2 jamais un autre nombre
    Il y a des bits d'erreurs a nettoyer
    FERR et OERR
    FERR et effacer par la seconde lecture de RCREG .
    Mais OERR est a effacer
    bsf STATUS,rp0
    bcf STATUS,rp1
    clrf RCSTA,OERR
    A+, pat

  29. #24
    freepicbasic

    Re : transfert de donnée PC vers Pic

    Effectivement CREN nettoie les OERR , c'est ce qui est conseillé dans le datasheet.
    A+, pat

  30. Publicité

Sur le même thème :

Discussions similaires

  1. Réponses: 8
    Dernier message: 08/05/2009, 02h47
  2. Transfert de donnée Bluetooth
    Par Odoobe dans le forum Électronique
    Réponses: 1
    Dernier message: 11/10/2007, 14h00
  3. suite de fonctions dont la TF converge vers une fonction donnée
    Par alnitak dans le forum Mathématiques du supérieur
    Réponses: 0
    Dernier message: 14/06/2007, 12h08
  4. pb de transfert de donnée sur fanuc 18imb
    Par mik37 dans le forum Technologies
    Réponses: 0
    Dernier message: 04/05/2007, 13h44
  5. Transfert caméscope numérique vers PC
    Par jerry dans le forum Électronique
    Réponses: 7
    Dernier message: 30/10/2003, 21h37
Découvrez nos comparatifs produits sur l'informatique et les technologies.