Llevando tu método al límite, Iván, si nuestro programa está basado en una máquina de estados, incluso podríamos ir al estado que estaba activo durante el Reset, ¿verdad?
Según tengo entendido la RAM permanece con los mismos valores, por lo que quizás se podría conseguir una transparencia total para el usuario.
Opino que son raras las aplicaciones que deban correr justo en el punto anterior a donde venian corriendo, ya que si por ejemplo, estamos atendiendo algo importante y se resetea el pic por un BOR, tardará algunos useg o mseg (dependiendo de qué tengamos activado) en volver al lugar donde estaba lo cual en muchos casos sería peor a que directamente reinicie de nuevo.
De todas formas si ese es el caso, sugiero usar memorias externas muy veloces y que tengan posibilidad de 'recordar datos' frente a un reset. Un ejemplo claro son las memorias ferro magnéticas que se graban en micronésimas de segundo!
http://www.ramtron.com/doc/AboutFRAM/Technology.aspCreo que no hay soluciones tan simples y que realmente se complican muchisimo porque también puede darse el caso de que a la mitad de una grabación se corte la alimentación o se resetee el pic. Si hablamos de una aplicación que corra constantemente entonces estas cosas sí pueden pasar.
Lo ultimo no nos salva de que al reiniciar el software, tener que leer la memoria y verificar que los datos allí incluidos sean correctos, para ello tal vez debamos agregar algun checksum por ejemplo, dentro de la misma memoria que valide los datos.
Por ello soy de insistir en que si bien por software hay cosas para hacer y tener en cuenta, es por hardware donde reamlente debemos hacer que la cosa funcione y sea confiable.
En lo particular por software me dedico a interpretar y/o determinar las causas de un reset, más que volver a donde estaba. No siempre es posible y en muchisimos casos es peligroso y hasta puede daniar algo.
Da la impresión de que la EEPROM es algo inestable y que se borra con mucha facilidad. Nada más lejos de la realidad, lo raro es que los adatos estén corruptos y muy dificilmente se borran por ruido. La prueba la tenemos en los propios porgramas almacenados el los pic que duran años y años perfectamente. Yo me inclino a pensar que los problemas con la memoria son debidos a una mala programación. De todas formas con un buen checksum no deberiamos tener más problemas y si los datos guardados no coinciden con los escrito habria que revisar las subrutinas que realizan estas operaciones.
Un saludo
Las eeprom son mas o mucho más inestables que las FLASH. Si tus programas no hacen uso de la eeprom, allí tienes la respuesta.
Si tus programas sí hacen uso de la eeprom, entonces estamos frente a un hardware bien diseñado para el entorno en el que trabaja. A veces un hardware bien diseñado para un entorno no lo es bueno para otro que contenga más ruido magnético o un ambiente eléctrico más ruidoso en general.
Aunque ahora, siempre que necesito EEPROM, uso una Externa. La interna no me da buena espina.
Solo a modo de anécdota puedo decir que ambas eeprom son vulnerables a los mismos problemas. En una oportunidad me pasaba que una aplicación con eeprom externa andaba mal y le echaban la culpa al pic. Bien, como estas cosas son dificiles de demostrar sin datos fehacientes (sino termina siendo la palabra de uno contra el otro por más argumentos que uno esgrima) , me vi forzado a hacer un código dentro de la propia aplicación que verificaba la eeprom del pic y la eeprom externa, a cada rato. Pasaba que cuando frenaba un motor, se metía un pulso electrico que afectaba a la eeprom externa y no al pic (el cual tenía su hardware más bien diseñado). Este es un caso en que el problema era la eeprom externa! y le echaban la culpa al pobre PIC. Solucion? -> les dije que filtren mejor la alimentación de la memoria y santa solución!.
En efecto, en todos los PIC's en que he probado esto hasta ahora se dá ese efecto, tras un Reset, MCLR a masa, la RAM queda intacta con todos los valores que tenía anteriormente (16F628, 16F777, 16F876, 18F2550 y 18F4550)
Creo que se puede agregar que esto funciona y va de la mano de una buena deteccion de la causa del reset
Sino, seria altamente peligroso.