Si cargas un 0x00 en el contador de programa, tambien se hará un reset, ya que la posicion 0x00 pertenece al vector reset.
Maunix yo creo que si se podria hacer. Unicamente habria que configurar la maquina para que cuando hiciese el reset, guardase todo el estado de maquina en una parte de la eeprom, y cuando reinicie la maquina lo primero que haga es ir a mirar este sector de memoria y volver a ponerlo todo como estaba antes del reset. Pienso que se podria hacer. Ademas, los pics no tienen un bit que indica si el estado anterior es un reset ,no? Creo recordar que si. Habia un registro o un bit que avisaba si la maquina arrancaba de un estado anterior reset o power down.
La solucion con el WDT no me acaba de convencer. Soy muy reacio a utilizar el WDT para hacer nada. Prefiero deshabilitarlo, y montar aparte un sistema interruptivo donde no se me pare la maquina y haga saltar el WDT por accidente.
La verdad es que nunca he hecho un reset por software. Supongo que puede tener utilidad en aplicaciones de comunicaciones entre micros.
Hola compañeros que tal!
Ahora que miraba este post se me vino a la cabeza una instruccion en C para reiniciar el programa es RESET_CPU(); yo la e utilizado mucho en CCS para reiniciar el pic desde el programa.
Hola maunix que tal yo lo he realizado solo en 16f84a, en 16f628a y en otros pocos de la serie 16f. Yo no lo e echo en ningun 18f pero que me parece que es lo mismo en todos los PICs
Lo he puesto a trabajar con un LOW en un PORT y conectarlo al MCLR de los PIC 16F628, 16F84 y 16F877, y el programa se reinicia sin ningún problema, ademas como dijo Chaly29 que haciendo eso no me lo cargo (daño) entonces así lo estoy utilizando.
Muy bien, si bien desperdicias un pin al menos estás seguro que será un reinicio "limpio" pero cuidado con lo que hagas con el pin en cuestión ni bien se inicia el software.
Muy bien, si bien desperdicias un pin al menos estás seguro que será un reinicio "limpio" pero cuidado con lo que hagas con el pin en cuestión ni bien se inicia el software.
Si, en el proyecto es el único pin del PORTA que me quedaba libre y como me gusta el orden, cada dispositivo en un bloque de puertos, entonces lo usé para eso, solo hay 2 secuencias de reset en el programa, y ambas son llamadas solo cuando el usuario lo requiera.
una pregunta tonta manuix... desde el desconocimiento dices que goto 000 no vacia el stack. Normalmente cuando un pic inicia su actividad se dedica a borrar todas las pilas que tiene en memoria?. Tenia entendido que cualquier componente de memoria contenia basura al arrancar.
1 saludo
Esto pasa con la gente que usa mucho windows, todo lo solucionan con un reset, tengo un outage de 4 horas por que un dessarrollador oracle creyo que si reseteaba el servidor se iban a acomodar algunas cositas, no no, esto del reset es una lacura, las cosas se hacen prolijas, te armas una funcion llamemosla limpiar, que te deje las variables o lo que quieras fresquitas y listas para usar, y llamas a esa funcion osea haces que el programa se recicle.
Por otro lado ccs hace otras cosas antes de entrar al main, como la mayoria de los C..., por eso existe una funcion especial que se puede llamar antes que el main que es algo asi como after_reset() no se muy bien, a lo mejor realiza un proceso de limpieza, recordemos que ccs lleva cuenta del stak que usa:
Stack: 4 worst case (3 in main + 1 for interrupts)
y que ademas a los chicos de ccs les gusta esconder algunas cosas, hay que revisar bien ese codigo no se basen en el .lst que les deja al compilar.
El asunto de querer hacer el reset es el siguiente:
Mi aplicación es para usuarios, el sistema es configurable por el usuario y maneja demasiadas opciones, demasiadas variables durante este proceso, tambien lectura y escritura en la eeprom, y para evitar que alguna de estas variables y demas me interfiera en el funcionamiento nominal del proyecto entonces lo pongo a que se haga reset e inicie lo que necesita para trabajar, ademas tb es para safar un poco, porque tengo problemas con el lcd ya que durante la configuración activo el "parpadeo del cursor" y no soy capaz de quitarlo entre otras cosas.
A veces, cuando uno comienza, necesita de este tipo de soluciones para bueno, zafar por el momento. Yo lo tomaría como parte del aprendizaje, con las advertencias que he expuesto anteriomente.
Considero que por ej. al decir "un llamado a una función limpieza" has generalizado. En mi opinión muchos problemas se resuelven no con llamadas a funciones que inicializan variables sino a una buena diagramación del software , de las subrutinas y de como va el flujo del programa a medida que algunas condiciones se cumplen o no.Primero que nada una funcion no tiene por que inicializar ningun tipo de variables, segundo por funcion se entiende una rutina de codigo que realiza una funcion especifica. si a vos te gusta tirar todo en un solo main, me parece fantastico pero es una practica que desaconsejo, si bien muchos trabajan en assembler esto no quiere decir que estes restringido al modelo to-down sino creo que las herramientas de hoy en dia permiten incluso hacer un assembler modular, mucho mas limpio y facil de manejar, quiza mas dificil de leer como pasa con la programacion modular, pero ya basta de este tema que da para mucho...
CitarConsidero que por ej. al decir "un llamado a una función limpieza" has generalizado. En mi opinión muchos problemas se resuelven no con llamadas a funciones que inicializan variables sino a una buena diagramación del software , de las subrutinas y de como va el flujo del programa a medida que algunas condiciones se cumplen o no.Primero que nada una funcion no tiene por que inicializar ningun tipo de variables, segundo por funcion se entiende una rutina de codigo que realiza una funcion especifica. si a vos te gusta tirar todo en un solo main, me parece fantastico pero es una practica que desaconsejo, si bien muchos trabajan en assembler esto no quiere decir que estes restringido al modelo to-down sino creo que las herramientas de hoy en dia permiten incluso hacer un assembler modular, mucho mas limpio y facil de manejar, quiza mas dificil de leer como pasa con la programacion modular, pero ya basta de este tema que da para mucho...
Cuando uno quiere resetear un dispositivo, cualquiera no importa, hay una etapa que uno no controla el programa esta ciego ya es imposible intervenir o tomar desiciones, por eso el programador tiene que evitar esto a toda costa, por que uno ya no puede volver atraz y por que no existe ninguna manera de saber que va a pasar uno se queda esperando que retomar el control para dar servicio y eso es una falla tremenda, imaginemos que la condicion X se sucita en una maquina, si la contramedida es reiniciar perdemos conocimiento de lo que X provaca al resto de la maquina, por eso las contramedidas tienen que ser activas, la maquina se tiene que poder defender pero estando viva no muerta, si pensamos que la somucion de algo es perder el control absoluto, estamos cortemos la conversacion y vamos a jugar a las barbis...
Estas siendo extremista maggi, como dije antes, es para zafar de algunas y para que tomara las nuevas configuraciones que el usuario pone y acortar el código a su vez, en el proyecto que realizé, me toco que empezar a depurar en demasía el programa, xque me pasé de la capacidad del 16F84 antes de terminarlo.