Comportamiento extraño usando eeprom

buenas noches, tengo un comportamiento super extraño según los datos que escribo en una dirección de la eeprom el programa hace ciertas cosas.

lo que estoy haciendo es un reloj de ajedrez, utilizo 4 direcciones en la eeprom para guardar los tiempos que se configuran para cada jugador

Código:
 * minutos_a=read_eeprom(0);
 * segundos_a=read_eeprom(1);
 * minutos_b=read_eeprom(2);
 * segundos_b=read_eeprom(3);

para mostrar los tiempos estoy usando 8 display de 7 segmentos multiplexeados, uso 7 pines del pic para manejar cada segmento, y utilizo 8 pines para manejar 8 transistores en el común de cada display, la forma clásica de multiplexear, los 8 pines de los transistores ocupan todo el puerto A, y el problema que tengo es con la dirección de la eeprom 3, que corresponde a los segundos del jugador b, el comportamiento es bastante extraño, pero al menos sigue una lógica.

el problema con la dirección 3 es que cada bit que se pone en 1 me apaga un display, si esta en 00 funcionan todos los display, si esta en ff se apagan todos, si por ejemplo esta en 01010101, se prenden intercalados, si esta 0F, se prenden los 4 últimos, y así sucesivamente con las 255 posibilidades que hay, cada bit que se pone en 1 hace que deje de funcionar un display, la verdad no entiendo que es lo que esta pasando.

recién probé cambiando la dirección 3 por la 4, y pasa lo mismo. no entiendo porque el puerto a, o los display, o no se que cosa, depende de lo que se escriba en la variable *"segundos_b"

dejo el código completo por las dudas, es bastante largo.

muchas gracias
 

Adjuntos

  • reloj.c.txt
    17.9 KB · Visitas: 9
no entiendo por qué el puerto a, o los display, o no sé que cosa, depende de lo que se escriba en la variable *"segundos_b"
Como no adjuntas el esquema, realicé únicamente la simulación sin obviamente conectarle algo al PIC para ver el valor de los registros, y noté algo extraño en el puerto A.

En el código tienes establecido todo el puerto A como salidas usando la instrucción set_tris_a(0b00000000);
Sin embargo, durante la simulación el puerto A permanece con los pines como entradas.
No sé si sea un bug de los tantos que tiene el PIC C Compiler o sea por la versión que estoy usando (5.027)

Anteriormente resolví un problema similar, pero con la instrucción port_b_pullups();
En el PIC16F887 esta instrucción no hacia su función de habilitar las resistencias pull-up del puerto B.

Tal vez esté pasando lo mismo ahora con la instrucción set_tris_a(); y el compilador sigue teniendo problemas con algunas instrucciones de los PIC16F88X.

La forma de solucionarlo, si el caso es similar; es creando una referencia del registro TRISA para sustituir la instrucción.

Realiza una prueba verificando que los pines del puerto A estén realmente funcionando como salidas, y si no, crea esta referencia:
#byte TRISA = getenv ("SFR:TRISA")
Y en el void main le das el valor 0 a TRISA
TRISA = 0;

Espero ese sea el problema.

Edit:
Acabo de ver que dentro de la rutina de servicio de interrupción por RB0, tienes una llamada a una subrutina externa. "menu();"
Eso no está bien, pues se produce un Stack Overflow al realizar esa llamada y pasará lo mismo que por aquí.

Suerte.
 
Última edición:
Ahora entiendo Un poco más. Me parecía que ese valor estaba afectando al tris, por lo tanto había probado poner de nuevo el set_tris a la salida del menu, pero seguía sin funcionar, seguramente el problema es que llamo demasiadas funciones dentro de la int. Voy a poner ese menú en el main y veo que pasa. Muchas gracias. Lo raro es que después de reiniciar el pic sigue funcionando mal. Y si escribo algo en esa dirección de EEPROM con el pickit 2 también funciona mal. Quizás pueda ser un bug también, voy a probar usando la otra instruccion



bueno, creo que ya esta, primero probé sacando el menú de la int, pero seguía sin funcionar
al final la solución era hacer esto #byte TRISA = getenv ("SFR:TRISA"), el menú igual lo dejo en el main para no hacer chanchadas, si quieres puedo subir el esquematice, pero creo que ya no hará falta.
 
Última edición:
Bueno, creo que ya está, primero probé sacando el menú de la int, pero seguía sin funcionar.
Al final la solución era hacer esto #byte TRISA = getenv ("SFR:TRISA"), el menú igual lo dejo en el main para no hacer chanchadas, si quieres puedo subir el esquemático, pero creo que ya no hará falta.
Si ya resolviste el problema con lo que te mencioné, pues ya no será necesario, pero si llegas a tener problemas nuevamente, si será necesario para darle un mejor seguimiento al asunto.

Suerte.
 
Atrás
Arriba