Basura en doble comunicacion serial PIC18F4550

[canival35]

Hola tengo unos dias rompiendome la cabeza con esto, espero alguien pueda ayudar:

implemento dos canales de comunicacion serial con USART 1 por software y otro por hardware, independientemente trabajan en excelentes condiciones manejando "streams" recibo sin problemas por hardware desde un modulo GPS y transmito hacia la PC por el otro canal,

el problema es:  la transmision del USART por SOFTWARE comienza a fallar en el momento en que ambos canales de comunicacion se encuentran activados, hacia la terminal de la computadora transmito "HOLA" y recibo algo como esto

Código: [Seleccionar]

HOLAHOLA ý[1D]®  ñ[11]¨ HOLAHOLA ñ[11]¨ HOLAHOLA[08]ý[05]º¸[08]=ÅŠˆHOLAHOLA =ÅTÐHOLAHOLA ÷[17]¨ È=ÅêˆHOLAHOLA ÷[17]¨ HOLAHOLA ñ[11]¨  ô[14]êèHOLAHOLA =ÅêèHOLAHOLA8ý[05]® HOLAHOLAHOLA[08]ý[05]¢ HOLAHOLA8ý[1D]® HOLAHOLA
cada dos o tres transmisiones falla y envia pura basura o caracteres erroneos, aqui esta el codigo, de antemano se les agradece la ayuda 

Código: [Seleccionar]

#include <18F4550.h>
#fuses NOWDT,NOPROTECT,NOCPD,NOLVP,INTRC_IO,NOMCLR,NOPUT,NOBROWNOUT,NOPBADEN,NOCPD,NODEBUG,NOWRT,NOVREGEN  //este es sin cristal CPU a 4MHz
#use delay(clock=2MHZ)// a 2MHz este y el    setup_oscillator(OSC_8MHZ);
#use rs232(baud=9600,parity=N,RCV=PIN_C7,XMIT=PIN_C6,bits=8,Stream=GPS,ERRORS)
#use rs232(baud=9600,parity=N,RCV=PIN_B2,XMIT=PIN_B1,bits=8,Stream=PC,Force_sw)

#include "LCD420pD.C"

 

#include <time.h>       
#include <rtctimer.c>   
#include <stdlib.h>
#include <input.c>

int t,i=0,j=0,k=0;
int procesarGPSid=0;
int16 ADC=0;

int horaSUM,hora1,hora2,min1,min2,seg1,seg2,dia1,dia2,mes1,mes2,anio1,anio2;
int   lat1,lat2,lat3,lat4,lat5,lat6,lat7,lat8,long1,long2,long3,long4,long5,long6,long7,long8,long9;

char c;
char gpsL[70];// gpsLECTURA
char gpsID[5];// toma el encabezado de cada cadea GPS
char gpsC[5];//gpsCOMPARACION


/////////////////////////////////////////////////////////////////////
/////////////////////////INTERRUPCIONES//////////////////////////////
/////////////////////////////////////////////////////////////////////

#int_rda
void serial_isr(void) {
while(kbhit(GPS))
 {

c=fgetc(GPS);
if(c=='$')
    {for (t=0;t<5;t++){
 delay_ms(1);
       gpsID[t]=fgetc(GPS);}

   if((gpsC[0]==gpsID[0])&(gpsC[1]==gpsID[1])&(gpsC[2]==gpsID[2])&(gpsC[3]==gpsID[3])&(gpsC[4]==gpsID[4])&(gpsC[1]==gpsID[1]))
      {   
         j=0;
         for (t=0;t<70;t++)
         {
            gpsL[t]=fgetc(GPS);
          if(gpsL[t]=='*')
            {t=80;}
         }
         
procesarGPSid=1;


      }
   else   
      {//while(kbhit(GPS)){c=fgetc(GPS);}     
//lcd_putc("\f");lcd_gotoxy(1,4);printf (lcd_putc,"NO");procesarGPSid=0;
      }
 
    }
 }
}
/////////////////////////////////////////////////////////////////////
///////////////////DECLARACION DE FUNCIONES//////////////////////////
/////////////////////////////////////////////////////////////////////
void PROCESARgps();

/////////////////////////////////////////////////////////////////////
/////////////////////////MAIN////////////////////////////////////////
/////////////////////////////////////////////////////////////////////

void main() {
setup_oscillator(OSC_8MHZ);
  enable_interrupts(global);
  enable_interrupts(int_rda);

////////ADC
  setup_adc_ports(AN0);
  setup_adc(ADC_CLOCK_INTERNAL);
  set_adc_channel(0);
////////MAIN PROG
   lcd_init();
   delay_ms(100);
gpsC= "GPRMC";
///////////////
///////////////
char kb;

 while(1) {

delay_ms(1000);
fprintf(PC,"H");
fprintf(PC,"O");
fprintf(PC,"L");
fprintf(PC,"A");


k++;

ADC= read_adc();
lcd_gotoxy(18,2);printf(lcd_putc,"%Lu",ADC);
PROCESARgps();
}
 

}



[AngelGris]

  No entiendo porque pones use delay 2MHz si tu oscilador está trabajando a 8MHZ.

[canival35]

  No entiendo porque pones use delay 2MHz si tu oscilador está trabajando a 8MHZ.

Buena pregunta!!
No se por que pero a si me funcionan los delays y el Baudrate, quizás tengo mal configurado los #fuses pero misteriosamente siempre eh tenido una relación de 1/4 en el tiempo de mis retardos y el tiempo real implementado en el pic, simulado no tengo ese problema, quizás no eh configurado bien los fuses, eh programado con ASM y CCS y con diferentes programadores y siempre eh tenido esa particularidad con la ejecución de instrucciones cuando utilizo el oscilador interno

[AngelGris]

  No entiendo porque pones use delay 2MHz si tu oscilador está trabajando a 8MHZ.

Buena pregunta!!
No se por que pero a si me funcionan los delays y el Baudrate, quizás tengo mal configurado los #fuses pero misteriosamente siempre eh tenido una relación de 1/4 en el tiempo de mis retardos y el tiempo real implementado en el pic, simulado no tengo ese problema, quizás no eh configurado bien los fuses, eh programado con ASM y CCS y con diferentes programadores y siempre eh tenido esa particularidad con la ejecución de instrucciones cuando utilizo el oscilador interno

  ¿A qué te refieres cuando dices que siempre has tenido una relación de 1/4 entre tus retardos y el tiempo real del pic?
  Se supone que si trabajas a 8MHz, la sentencia "#use delay....." debería ser también con 8MHz.

  ¿En Proteus, qué velocidad de trabajo colocas?

[canival35]

¿En Proteus, qué velocidad de trabajo colocas?

en proteus a 2Mhz,

pero crees que esto sea el problema???

porque de lo contrario no tendria recepcion de las sentencias "HOLA" en ningun momento y tampoco recibiria correctamente los datos provenientes del GPS por el puerto del USART por hardware, el GPS me viene a 9600 y como te comento si configuro el oscilador y el USE DELAY a 2Mhz por ejemplo, los retardos de 1000 ms me andan a 4000 ms y el baud no me da, solo con esa relacion de 1 a 4 es como me ha vendo funcionando siempre xD

[AngelGris]

  En mi opinión está mal. Tal vez te esté dando de casualidad algún valor similar de BaudRate, pero si justamente los retardos no te dan quiere decir que está mal.

  En Proteus también debes colocar 8MHz, que es la velocidad del clock del PIC y vas a notar el mismo problema que en la realidad con respecto a los tiempos.

  Yo te recomiendo que hagas un pequeños programa con destellos de leds, con oscilador interno a 8MHz (como lo tienes ahora) y uses la sentencia "use delay..." también con 8MHz y lo mismo en proteus y vas a ver como las instrucciones de delay sí te dan el valor adecuado. Luego puedes agregarle alguna transmisión via UART y tendría que coincidir casi perfectamente el BaudRate.

[canival35]

  Yo te recomiendo que hagas un pequeños programa con destellos de leds, con oscilador interno a 8MHz (como lo tienes ahora) y uses la sentencia "use delay..." también con 8MHz y lo mismo en proteus y vas a ver como las instrucciones de delay sí te dan el valor adecuado. Luego puedes agregarle alguna transmisión via UART y tendría que coincidir casi perfectamente el BaudRate.

   

Muy bien ahorita hago algunas pruebas aunque anteriormente ya lo habia hecho pero quizas se me fue algo, gracias =)

[canival35]

Conoces alguna funcion que me permita limpiar el buffer del USART sin tener que ser descargada por getc(); ??
quizas queda basura en el buffer y sea necesario limpiarla antes de transmitir por el stream por software

[AngelGris]

  Lo ideal para limpiar el buffer es leerlo.

  Insisto en que tienes un error en el programa. En Proteus te funcionaba porque ponías 2MHz de clock, pero debe ir la velocidad a la cual queda trabajando el núcleo del PIC. Por ejemplo, en el caso de utilizar un cristal de 20MHz y que pase directo hacia el micro, el valor a colocar sería 20MHz.

[canival35]

Bueno he solucionado el error de la basura transmitiendo dentro de la rutina de la interrupcion RDA por el puerto de la PC (SOFTWARE y el mismo que mandaba la basura)  cuando me llega el paquete en el puerto del GPS (HARDWARE)


algo asi :

Código: [Seleccionar]

#int_rda
void serial_isr(void) {
while(kbhit(GPS))
 {
////atiendo la rutina
c=fgetc(GPS);
if(c=='$')
    {for (t=0;t<5;t++){
       gpsID[t]=fgetc(GPS);}
////// transmito lo que quiero por el otro puerto

    fprintf(PC,"HOLA -%d",k);   

//////terimnar de limpiar el buffer
    while(kbhit(GPS)){c=fgetc(GPS);}   
 }
clear_interrupt(int_rda);
}


  Insisto en que tienes un error en el programa. En Proteus te funcionaba porque ponías 2MHz de clock, pero debe ir la velocidad a la cual queda trabajando el núcleo del PIC. Por ejemplo, en el caso de utilizar un cristal de 20MHz y que pase directo hacia el micro, el valor a colocar sería 20MHz.

de que tengo el error  en la configuracion la tengo, algo curioso es que con los cristales tengo el mismo problema como si uso el oscilador interno, en proteus en cambio si tengo que poner el

#use delay(clock=2MHZ)
setup_oscillator(OSC_2MHZ);

pero al implementarlo en el pic si tengo que mantener esa relacion 1 a 4 para que me funcione el generador de BAUDRATE y los retardos =S esta raro eso,  espero algun dia encontrar el problema de porque no me trabaja, tanto en CCS como en ASM de MPLAB, he leido la documentacion y buscado en foros pero no encuentro el por que, de igualmanera ya solucione mi problema que tambien no supe cual era la causa, solo cambie el momento donde transmitia y se soluciono, gracias AngelGris 

[ignaciorod]

la relacion 1/4 la tenes cuando usas en el micro (real) y no cuando simulas con el proteus?
con que cargas el programa al micro si se puede saber

[canival35]

la relacion 1/4 la tenes cuando usas en el micro (real) y no cuando simulas con el proteus?
con que cargas el programa al micro si se puede saber

asi es, te comento que anteriormente lo hacia con un JDM que yo mism elabore y utilizaba WINPIC800 y el ICPROG, y ahora utilizo un pickit2 y de igual manera, con el JDM compile en mis primeros momentos en ASM y tena ese problema con programitas simples de encender y apagar leds, o transmitir hacia una consola por RS232 y despues en CCS tambien, los retardos se generaban por ejemplo si ponia en el codigo que queria 1 segundo me daba 4 segundos el retardo en el pic fisicamente   

[AngelGris]

la relacion 1/4 la tenes cuando usas en el micro (real) y no cuando simulas con el proteus?
con que cargas el programa al micro si se puede saber

asi es, te comento que anteriormente lo hacia con un JDM que yo mism elabore y utilizaba WINPIC800 y el ICPROG, y ahora utilizo un pickit2 y de igual manera, con el JDM compile en mis primeros momentos en ASM y tena ese problema con programitas simples de encender y apagar leds, o transmitir hacia una consola por RS232 y despues en CCS tambien, los retardos se generaban por ejemplo si ponia en el codigo que queria 1 segundo me daba 4 segundos el retardo en el pic fisicamente   

  ¿Estás teniendo en cuenta que el ciclo de instrucción tiene 1/4 de la frecuencia del cristal que uses?

  Es decir, que con un cristal de 4MHz, el pic trabajaría a 1MHz. Tal vez estás calculando mal los tiempos.

[ignaciorod]

el pickkit2 nunca lo use :S.Pero yo un par de veces usando el winpic y un jdm tuve los mismos errores usando el fuse hs, porque mi winpic me lo dividia automaticamente x4 pero despues iba a la pestaña "configuracion" y en una parte donde dice -cpu divide clock- le ponia: "No divide"

[thegame]

ignaciorod,si andas por ahi,donde quiera que estes,gracias loco me diste la solucion a mi problema de mucho tiempo,el PLL,gracias