Para MGLSOFTLas escrituras eeprom necesitan que NO se realicen otras acciones mientras ocurren, porque se malogran y el solo hecho de grabar un byte en eeprom, presupone 18 mseg con un reloj de 4 mhz.
No pense que era tanto tiempo, es lo unico que no habia pensado, , sobre que no se este haciendo otra cosa es que no se va a hacer otra cosa mas que grabar la EEPROM. Con respecto a lo de reentrante es que estoy acostumbrado a verlo desde el ASM (se que no es ASM pero es el funcionamiento del PIC), yo en ASM no activaria las interrupciones dentro de una interrupcion por simple logica, cuando entra a la interrupcion el PIC se desactivan, pero si el codigo de escribir en la EEPROM (de CCS ) lo activa nuevamente entonces ahi no te queda otra que hacer uno mismo la funcion de la escritura de la EEPROM. Y eso lo nombre en el post anterior. Si uno hiciera el codigo de la EEPROM no activaria las interrupciones, por lo tanto no existiria una "reentrada". Y eso contesta a esto:
Como el CCS ejecuta una interrupción y al momento borra las banderas (flags) de interrupción, queda listo para ejecutar otra vez la misma interrupción aun estando en ejecución el código de la anterior interrupción (en este caso la escritura en eeprom), lo que ocasiona recursividad, que esta prohibido en un PIC, por eso te avisa el compilador que desactivara esa interrupción para evitar una nueva entrada (reentrancy disabled).
El tema es que el necesita grabar los datos cuando exista una caida de tension para justamente que no se pierdan, la cual no le va a servir para nada asi como esta su programa. En el que hay momentos hasta con 3 segundos de delay. Si supuestamente ocurre este caso, vos no te preocupas por que tu programa "siga" ya que es una condicion por asi decirlo "de parada". Es lo ultimo que harias, y por lo cual no me preocuparia por si llego a retrasar el CCP o perder 0.5s en el contador, lo cual no va a hacer por que tiene una interrupcion de 0.5s y la grabacion de la EEPROM duraria mucho menos. Supongamos que se activo el flag de caida de tension, entro a la interrupcion y cuando entro y estoy grabando se activa el flag del CCP, no va a haber problema por que estan desactivadas las interrupciones mientras estoy en una interrupcion. Cuando termine de grabar la EEPROM y quiera salir, al activar la interrupcion el micro va a ver la flag del CCP y va a entrar de nuevo. la cual va a hacer el codigo del CCP, limpiar el flag y salir.lo cual estas ante un tiempo de 0.5s a 1s para salir de tu grabada de EEPROM y entrar a la del CCP (si es que sigue y fue una "falsa alarma" ) y no queres perder datos, ( el CCP te borra el timer asi que menos problema con eso )
Mi idea fue la de grabarlo lo mas rapido posible, como decia esta es una condicion de parada en la cual el PIC ya no va a tener mas tension, y mi idea era que aprovechara rapidamente ese ultimo momento para guardar las cosas. Si lo pone en el loop while deberia reformular su codigo, incluso reformulado si te "agarra" en el comienzo de una escritura del LCD tal ves corras la misma suerte que con el delay. Por eso dije de la interrupcion.
Resumiendo por si no me explique:
En caso que sea lo ultimo que haga el PIC por que se corto la tension:
- Entra a la interrupcion (es lo mas rapido 20 ciclos maximo deberia tener), graba la EEPROM ( lo que tarde ), termina de grabar, se sale de la interrupcion (limpia flag, etc) y que continue el programa hasta que no tenga mas tension y se pare.
Comparacion con el metodo de ponerlo en el while:
En el While sos dependiente de donde este el programa y seguro que la mayoria de las veces tenes mas de esos 20 ciclos para comenzar a grabar la EEPROM, comenzas tarde a grabarla, lo cual corres mas riesgo de que a la mitad de la grabacion quedes sin energia y quede corrupto lo guardado, obviamente con la interrupcion corres la misma suerte, pero al comenzar mas rapido es un poco menos el riesgo.
En caso de que sea una falsa alarma:
- Con interrupcion no seria problema, como ya comente el CCP se encarga de poner a 0 el Timer1 y la flag quedaria activada, se grabaria la EEPROM, tomaria el RETFIE ( que activaria la interrupcion global ) y al estar activado el flag del CCP entraria nuevamente a la interrupcion por el CCP, el cual aumentaria sus segundos, borraria el flag y seguiria normalmente. Lo unico que "retrasaste" es el programa principal por que entraste 2 veces a la interrupcion (1 para el CCP y otra para la EEPROM).
Lo que no entendi fue esto:
En palabras simples, si entra en esa interrupción y deshabilita, no vas a tener comunicaciones serie por interrupciones, se entiende??
Cuando se entra la interrupcion se deshabilita solo las interrupciones globales, el RETFIE es quien las habilita nuevamente. Pero si misteriosamente usas una funcion como escribir en la EEPROM que posee las instrucciones de desactivar y activar las interrupciones dentro como para poder usarlas en el loop while por ejemplo, entonces ahi SI vas a tener problemas y va a ser reentrante. Y es a esto a lo que estoy apuntando.
Grabar la EEPROM en la interrupcion no es el problema, el problema es la funcion de grabado de la EEPROM.
Y ahora te pido que me entiendas a mi
O los dos estamos diciendo lo mismo y no nos entendemos
Para arielmdqNo tengo muy en claro cuando hablan de flag supongo que es una señal, un parametro ,una palabra a la que se le asigna un valor ? o simplemente una variable y la llaman flag ,se supone que esto ya lo debería saber pero bue en algun momento lo tenía que preguntar disculpame pero no tengo muy incorporado el termino .
Flag normalmente es una "variable" de un 1 bit, es 0 o 1, en el cual puede indicar algo, por ejemplo cuando ocurre una interrupcion se pone en 1 una flag llamada CCP1IF indicando que ocurrio la condicion interrupcion del modulo CCP. ( No hace falta que este habilitado la interrupcion para que se ponga en 1 la flag), vos hiciste algo parecido, creaste una "flag" llamada a ( aunque de 8 bits seguro) la cual para vos te indica si entro o no a la interrupcion, eso es una flag, es una bandera ( traduccion ) como para indicar algo