TODOPIC
Microcontroladores PIC => Lenguaje C para microcontroladores PIC => Mensaje iniciado por: micro_pepe en 28 de Enero de 2009, 17:46:17
-
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.
-
¿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?
-
¿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.
-
¿Qué pasa cuando pones reloj HS y cristal de 4MHz?
-
Que tal micro_pepe!
Mira aqui lo tengo funcionando en el simulador revizalo a ver si te sirve :mrgreen:
Al principio no me compilaba :? pero le di primero a Compile y luego le di a built all y empeso a compilar bien :mrgreen:
Puede ser que halla un pequeño bug :shock:
Saludos
-
¿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 :shock: :shock:
Un saludo.
-
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
-
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.
-
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 :shock: :shock:
Un saludo.
Entonces es momento de que compartas el código con nosotros para que lo chequemos ;-)
-
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.
-
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? :o
-
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:
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.
-
¿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.
-
Pues eso tampoco lo soluciona :( :(
-
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...
#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);
}
-
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...
La verdad es que copie ese codigo del foro, y como funcionaba con un mando universal no me preocupe de mas, echare un vistazo al RC5 a ver si comprendo lo que dices.
Un saludo.
-
Buenas. He estado mirando como funciona el RC5, y por lo que veo un 'o' es un nivel alto durante 889us seguido de un nivel bajo de 889us. Un '1' es un nivel bajo durante 889us seguido de un nivel alto de 889us.
Por otro lado una trama completa consta de dos unos seguidos, llamados bits de star, un bit de 'tongle', que sirve para distinguir una sola pulsación de una pulsacion mantenida, cinco de direccion, y seis de comando.
En teoria para leer una trama, (El receptor de infrarrojos invierte la señal) detectamos una bajada de la salida del detector, contamos 444us, con lo cual nos situamos a 1/4 del primer bit (un bit son 889+889 us), testeamos ese nivel, y contando otros 889us nos situamos a 3/4 del primer bit, testeamos ese nivel, y si es contrario al nivel testeado anteriormente, de momento es un codigo rc5. Guardamos el primer nivel testeado, contamos otros 889us y entonces estamos a 1/4 del segundo bit. Esto se repetiria hasta completar los 14 bit.
Esto se corresponderia con este codigo:
#INT_EXT
void MandoDistancia(){
delay_us(444); //Espera 444
while((nbit++ != 13) && (state == 0)){
if(input(REC_IR)==0){
delay_us (889);
if(input(REC_IR) != 1)
state=1;
bit=0;
}else{
delay_us(889);
if (input(REC_IR) != 0)
state=1;
bit=1;
}
shift_left(data,2,bit);
delay_us (889); //ESTO ES LO QUE CAMBIA DEL CODIGO ANTERIOR
}
Pues bien, eso no se porqué pero no funciona, sin embargo el codigo puesto por migsantiago un poco mas arriba, si funciona (a 8Mhz claro, a 4Mhz no).
PD: Aqui se puede ver graficamente algo del RC5
http://robots-argentina.com.ar/Comunicacion_protocolorc5.htm
Un saludo.