Posible bug ccs4.084

[micro_pepe]

Me ocurre lo siguiente:

Version: 4.084

Pic: PIC16F876A

Si utilizo el fuse HS y un reloj de 8Mhz, el programa de la interrupción externa funciona correctamente. Pero si utilizo fuse XT y reloj de 4Mhz, esa parte no funciona.

Los cristales están bien, con el de 8Mhz funciona, y el de 4Mhz lo he probado en otro pic y funciona, ademas he probado con otros cristales.

Un saludo.

[Nocturno]

¿No será que a la interrupción no le da tiempo a terminar por alguna razón?
¿Qué código tienes en la interrupción?
¿Has visto el código ASM generado por si hay diferencias?

[micro_pepe]

¿No será que a la interrupción no le da tiempo a terminar por alguna razón?

No creo, esa interrupción lee un codigo de un mando a distancia, por lo que tarda lo mismo en ejecutarse a una frecuencia u otra.

¿Has visto el código ASM generado por si hay diferencias?

Si lo he visto, las diferencias están en los retardos y en las direcciones de salto, pero el resto del codigo es igual. Solo he mirado la parte de la interrupcion.

Un saludo.

[migsantiago]

¿Qué pasa cuando pones reloj HS y cristal de 4MHz?

[RALF2]

Que tal micro_pepe!
Mira aqui lo tengo funcionando en el simulador revizalo a ver si te sirve   

Al principio no me compilaba  pero le di primero a Compile y luego le di a built all y empeso a compilar bien 
Puede ser que halla un pequeño bug 

Saludos

[micro_pepe]

¿Qué pasa cuando pones reloj HS y cristal de 4MHz?

Ocurre lo mismo, ya lo habia probado.

El caso es que cuando comencé a escribir el programa usaba 4Mhz, y la parte de la interrupción externa ño la he modificado. Pero despues agregué lineas de codigo, le puse a 8Mhz, se me ocurrió pasarlo de nuevoa 4Mhz, y dejó de funcionar la parte de la interrupción 

Un saludo.

[elmasvital]

Si quieres saber si es un bug de ccs no tienes mas que cargar el .hex generado por el ccs en mplab y ver las palabras de configuración para ver qué tiene puesto en la parte del oscilador

importas el hex en mplab file--> import y luego en configure-->configurate bits...

si usas delays comprueba tambien el #use delay no vaya a ser que hayas insertardo un 0 de mas o de menos.
1 saludo

[micro_pepe]

Si quieres saber si es un bug de ccs no tienes mas que cargar el .hex generado por el ccs en mplab y ver las palabras de configuración para ver qué tiene puesto en la parte del oscilador

importas el hex en mplab file--> import y luego en configure-->configurate bits...

Pues la configuración está bien, entonces no será un bug.

si usas delays comprueba tambien el #use delay no vaya a ser que hayas insertardo un 0 de mas o de menos.

Lo he comprobado y tiene sus seis ceros.

Será un problema de mi codigo? 

Un saludo.

[migsantiago]

Ocurre lo mismo, ya lo habia probado.

El caso es que cuando comencé a escribir el programa usaba 4Mhz, y la parte de la interrupción externa ño la he modificado. Pero despues agregué lineas de codigo, le puse a 8Mhz, se me ocurrió pasarlo de nuevoa 4Mhz, y dejó de funcionar la parte de la interrupción 

Un saludo.

Entonces es momento de que compartas el código con nosotros para que lo chequemos 

[micro_pepe]

Pues ahi va el codigo. Se trata de hacer un control de volumen digital, con un encoder para el panel, y un mando a distancia por RC5.

Un saludo.

[migsantiago]

Tienes Interrupción por RB0 y por Timer0. El valor del desbordamiento de timer0 es la variable Periodo. El valor de Periodo lo definiste como 0, ¿lo actualizas a otro valor cuando usas 4MHz?

Si no cambias el valor de periodo, los desbordamientos de timer0 a 4MHz y a 8MHz tendrán una duración diferente. Si duran diferentes tiempos entonces puede que te lleguen 2 interrupciones al mismo tiempo, pero la de RB0 será ignorada mientras se atiende la de TIMER0.

¿Crees que por ahí ande el problema? 

[micro_pepe]

Pues no anda por ahi, he probado a ajustar el periodo y no he conseguido nada, incluso a quitar la interrupción del timer0 y nada. De todas formas en la interrupción si entra, el problema es que lee un codigo incorrecto, cuando es correcto, o bien se programa una tecla o se actua en consecuencia, si es incorrecto no se hace nada, pero puse un testigo (hacer parpadear un led) para comprobarlo y lo que hace es que detecta un codigo incorrecto.

La parte a la qe me refiero es esta:

Código: [Seleccionar]

if(state){
         //Error.
         //PitidoCorto();///////////////////////////////////este es el testigo.
         /*lcd_gotoxy(1,1);//fila 1, col 1
         printf(lcd_putc,"Error           ");*/
         Delay_cycles(1);
   }else{//Dato correcto.
         if(!GRABAR)
            AlmacenaTecla();
         else
            ProcesaTecla();
   }

Un saludo.

[migsantiago]

¿Y si le quitas 10us o menos al delay_us que está antes del if?

if(input(REC_IR) != 1)

Talvez el delay tiene unos cuantos microsegundos de diferencia entre la compilación a 4MHz y 8MHz. Además es la única sección que pone state=1.

[micro_pepe]

Pues eso tampoco lo soluciona 

[migsantiago]

Estoy leyendo el RC5 de phillips y ya veo de dónde sacas los 889ms, es la mitad de tiempo de un toggle. Lo que no sé bien es porque esperas tanto tiempo...

Código: [Seleccionar]

#INT_EXT
void MandoDistancia(){

delay_us(444); //Espera 444

while((nbit++ != 13) && (state == 0)){

   delay_us (889); //Espera 889 más, ya esperó 1333ms

   if(input(REC_IR)==0){
        delay_us (889);
        if(input(REC_IR) != 1)
            state=1;
        bit=0;
   }else{
         delay_us(889); //Espera otros 889, ya esperó 2222
         if (input(REC_IR) != 0)
               state=1;
         bit=1;
   }
   shift_left(data,2,bit);
}