transfert de donnée PC vers Pic

[invite09709e00]

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
-----

[mat64]

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...

[invite09709e00]

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)

[invitef86a6203]

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

[A voir en vidéo sur Futura]

[invite09709e00]

J'ai un debuggeur mais pas d'oscilloscope

[invite09709e00]

Voici mon 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')); 
    }

[mat64]

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.

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.

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

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.

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...)

[mat64]

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...

[invite09709e00]

ok merciiiiiii

[invite09709e00]

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

[invitef86a6203]

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.

[mat64]

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.

Soit on passe par l'interruption pour recevoir.

je me tue à le répéter

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)

[invite09709e00]

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

[invite09709e00]

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?

[mat64]

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...)

[invite09709e00]

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.

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....???

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

[invite09709e00]

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.

[mictour]

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.

[invite09709e00]

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:

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.

[mat64]

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.

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...

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 ?

[invite09709e00]

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.

[mictour]

…… 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

[invitef86a6203]

ç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

[invitef86a6203]

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