TODOPIC
Microcontroladores PIC => Todo en microcontroladores PIC => Mensaje iniciado por: pibe en 29 de Julio de 2010, 05:23:20
-
Pues eso.
Me gustaría saber cuánta gente lo utiliza y cuánta no. Ya que debo instalarlo en un código larguiiiiiiiiiiiiiiisimo que aparentemente no tiene "parones", pero me preguntaba si realmente valía la pena semejante esfuerzo.
-
Yo creo que es imprescindible en cualquier aplicación que aspire a ser robusta.
-
Tienes mucha razón.
Algunos consejos me puedas dar para no dejarme la vida en ello? Son 174kb de asm... un programa muy extenso.
Tenía pensado activar el stopwatch para ir paso a paso por todo el programa y poder rastraer donde debería refrescar el WD.
Se te ocurre alguna mejor idea?
-
Es que de ASM no tengo ni idea. En CCS es tan sencillo como metérselo al #use delay para que se refresque automáticamente en cualquier delay del programa, y a los bucles que tengas, que por muchos que sean resultan fácilmente localizables.
-
He contestado con un "Si, siempre" pero deseo haceros una (creo que interesante) reflexión sobre el tema.
El mejor programa, el mas elaborado, el mas perfecto y revisado del mundo, el mas libre de bugs y limpio de inconsistencias y redundancias puede contener en su entrañas la posibilidad remota de que, bajo ciertas circunstancias totalmente impredecibles, extrañas y recónditas pero reales a fin de cuentas, se cuele en ese limbo indefinido del que nunca sale.
Podemos llegar a la conclusión de que nuestro mas preciado programa es fiable en un 99%. Es ese 1% restante es el que nos puede joder la vida.
Siempre es bueno colocar esta salvaguarda última para que nuestro programa no entre en una situación de bucle infinito sin salida posible. El Wachtdog es la solución. Si no es refrescado en el lapsus de tiempo que definimos reseteará el PIC y nuestro programa comenzará a ejecutarse de nuevo. La situación imponderable, no medible, inimaginable ha sido salvada y nuestra aplicación vuelve por sus fueros y comienza de nuevo a caminar.
Esto lleva a dos consideraciones:
1ª.- El Watchdog debe ser activado solo cuando hayamos alcanzado ese 99% de fiabilidad de nuestro programa.
En caso contrario nos va a ser muy difícil detectar nuestras propias inconsistencias e incongruencias, nuestros fallos de diseño, nuestra falta de imaginación (revivir en nuestra cabeza lo que debe estar ocurriendo en el núcleo del PIC) serán ocultados, enmascarados, diluidos por el funcionamiento del Watchdog.
Tenemos que poner todo nuestro empeño en que nuestro programa funcione sin Watchdog. Cuando estemos seguros de ello podremos activarlo para prevenir aquello que no hemos sido capaces de prever. Prevenir lo imprevisto (curiosa frase)
2ª.- Una vez decididos a activar el Watchdog hay que ser muy precavidos (ó listos ó inteligentes ó despiertos ó cautos) sobre dónde colocar los refrescos del Watchdog.
Por un lado no podemos poner refrescos sin ton ni son, a tontas o a locas, en cualquier sitio porque nos parece bien, sin tener en cuenta su potencial riesgo de bucle sin salida.
En este caso el Watchdog no nos serviría de nada ya que si acertamos a colocar el refresco justo dentro de un proceso realmente infinito y sin salida (es posible hacerlo: yo lo hice una vez y me dio dolores infinitos de cabeza) el bucle sería definitivamente infinito ya que al ser refrescado precisamente en él, nuestro Watchdog no nos sacaría nunca de él.
Por otro lado hay que prever lo contrario, cualquier proceso normal y válido de nuestro programa cuya duración supere (o pueda superar) el del vencimiento del Watchdog. Es de cajón darse cuenta de que en estos procesos potencialmente largos debe tenerse prevista la posibilidad de que se nos desborde el Watchdog y nos lo dejemos a medio realizar. Debemos por tanto colocar en él un refresco.
Un ejemplo típico y tópico de esto es cuando están involucrados procesos de comunicaciones en las que estamos esperando recibir algo que, por vaya usted a saber qué circunstancias, no nos llega.
Mi consejo final: No debemos abusar de los refrescos y hay que colocarlo/s en aquel/llos puntos en que se den las dos siguientes circunstancias:
a.- Si el programa pasa por allí es que todo va bien.
b.- Si el programa pasa por allí el Watchdog puede desbordar.
Yo usualmente empiezo por activarlo sin refresco alguno y compruebo que efectivamente se resetea el PIC.
Después coloco un solo refresco, en el punto de inicio o vuelta al bucle infinito normal de mi programa (En C sería justo detrás de mi while(true)) y compruebo si los distintos procesos "caben" en el tiempo de desborde.
Y por último coloco un refresco en cada uno de los que se que consumen mas tiempo.
Con esta forma me aseguro de que he ajustado al mínimo indispensable los puntos de refresco con tal de que el Watchdog me sirva para algo en lo que realmente se me ha escapado y no he sido capaz de prever.
Así lo he vivido y así os lo he contado. Espero que os sirva.
Un saludo a todos.
Referencia: ¿Qué es el Watch Dog Timer? Evitando que se nos "cuelgue" nuestro PIC (http://www.todopic.com.ar/foros/index.php?topic=24982.0)
-
Red, te agradezco mucho tu aporte y paciencia para explicar detalladamente tus consejos y experiencia. Muchas gracias.
Mi programa está en el punto donde no se cuelga. Llevo meses probándolo en laboratorio, así que creo que podría decir que es 99% confiable y ahora le he activado el WD.
Mis rutinas de retardo/espera son las únicas que poseen el refresco y hasta el momento sigue funcionando sin desborde de WD.
Veremos que pasa.
-
Un interesante complemento a una buena implementación del Watchdog, como la que nos ha deleitado del maestro Redpic, es poner al inicio del programa un chequeo del Reset.
En función del tipo de reset que haya ocurrido, incrementamos un valor en la eeprom del micro, y así cuando queramos podemos leer su contenido para llevar una estadística del tipo de reseteos que han ocurrido.
-
Yo creo que es imprescindible en cualquier aplicación que aspire a ser robusta.
Estoy con Manolo! :lol:
Saludos!
-
Vaya pues... estoy usando un 18f6621. He habilitado el WDT con CONFIG WDT = ON, le he puesto un loop infinito sin refresco para probarlo y nada... no salta el simulador del MPLAB.
He mirado el setting del simulador y está habilitado para hacer un break cuando desborde el WDT.
He grabado el pic, lo he debugeado con el REAL ICE y tampoco salta.
Lo he grabado como RELEASE , sin el debugger y nada.
Qué me estoy olvidando?
-
Mira si por las dudas no se genera codigo automatico que resetee el watchdog.
Vote por la segunda opcion porque es lo mas sincero que se puede hacer, pero estoy en un todo de acuerdo con los conceptos vertidos por Diego.
-
Mira si por las dudas no se genera codigo automatico que resetee el watchdog.
He puesto el trace , pero al parecer al llegar al loop sólo hace NOP y GOTO loop infinito.
LIST P=18F6621 ;Directiva para definir el procesador
#include <P18F6621.INC> ;Definicion de SFRs para el procesador
CONFIG OSC = HS ;Osc por XTAL 20mhz
CONFIG BOR = OFF
CONFIG PWRT = OFF
CONFIG OSCS = OFF
CONFIG WDT = ON ;Watchdog habilitado
CONFIG LVP = OFF
CONFIG DEBUG = OFF
CONFIG CP0 = OFF
CONFIG CP1 = OFF
CONFIG CP2 = OFF
CONFIG CP3 = OFF
CONFIG CPB = OFF
CONFIG CPD = OFF
CONFIG WRT0 = OFF
CONFIG WRT1 = OFF
CONFIG WRT2 = OFF
CONFIG WRTB = OFF
CONFIG WRTC = OFF
CONFIG WRTD = OFF
CONFIG EBTR0 = OFF
CONFIG EBTR1 = OFF
CONFIG EBTR2 = OFF
CONFIG EBTR3 = OFF
CONFIG EBTRB = OFF
CONFIG MCLRE = ON
loop goto loop
end
-
Hola, yo sólo he usado el watchdog en una aplicación USB en donde hacía falta tener el pin de detección USB pero el hardware ya estaba armado, sin posibilidad de agregar tal pin. Usé el watchdog para detectar si el envío de un endpoint tardaba más de 1s. Si sucedía era porque el cable USB había sido desconectado, por lo que entonces se reseteaba el micro, apagaba el hardware USB y todo como si nada.
Yo no soy usuario del watchdog ya que si el programa se traba, el pic se resetea; y si es un proceso vital, considero que es igual si el programa estaba trabado o si echó a perder su objetivo.
-
Es cierto. Porque si algo va mal y salta el watchdog el micro reseteará y volverá al inicio, pasando otra vez por la rutina maldita y volverá a saltar y así estará todo el tiempo.
En algunas aplicaciones he utilizado un timer TIMEOUT para salir de dicha rutina y volver a reintentar sumando un contador que a una cierta cantidad de veces entonces salía de la rutina maldita y volvía al programa principal.
PD: Aún no consigo activar el chuchoguardián :5]
-
nunca lo uso, pero por no saber donde usarlo, y espero no tener que usarlo tampoco ya que mis desarrollos son 101% confiables :mrgreen:
Naaa, te pasaste con la explica Redpic, todavia tengo pendiente pegarle una miradita completa a tu web.
-
Si para eso es, es un perro guardián que le da la alarma al PIC, y bien nombrado es, porque vigila a nuestro PIC, mientras nosotros no lo hacemos.
Apoyo todas las ideas, un equipo para venderse o usarse por mucho tiempo debe incluir un WDT ON
saludos.
-
También estoy de acuerdo con lo que ha dicho RedPic. Pero también considero que, a la hora de utilizar dicho "perrito", hay que armar un programa adecuado para tal. Lo que quiero decir es que, a la hora de un reset, el contador de programa pueda continuar por donde se reseteo o lo más cerca posible (obviamente, primero deberá configurar al pic para el trabajo, Puertos, comunicaciones, diferentes timer y todo lo que se vea afectado en un reset del perro guardián).
-
nunca lo uso, pero por no saber donde usarlo, y espero no tener que usarlo tampoco ya que mis desarrollos son 101% confiables :mrgreen:
Eso supone todo programador! :D :D Pero cuando uno realiza un proyecto que queda en el campo de aplicación sin supervisor no puede darse el gusto que falle, y para protegerse de ello está el Watchdog ;-)
Saludos!
-
es como cuando te vas de casa, ahi queda el pichicho para proteger tus cosillas :D
No he tenido la suerte de hacer algun dispositivo que no sea para uso personal, ya que me dedico a esto de puro guapo y hobby ;-)
Pero con lo rompehuevos que soy para que las cosas me salgán bien, creo que no llegaria nunca a largar algo al mercado y antes me ahorcaria con la piola del pichicho guardian :D
No entendí mucho la aplicación de migsantiago por lo del USB, yo tengo hecha una aplicación que cuando desconecto el cable vuelve al programa inicial, es decir, si no tiene comunicación USB tiene otras cosillas que hacer y no necesito el WDT.
Salvo que tu digas que el programa se quede clavado en la rutina de envio del endpoint.
Luego en casa lo estudio un poco mas el tema, seguro se me esta pasando algo por alto :oops:
-
Hola, mi opinion. Para todos los proyectos que realizo el uso del watchdog es una condición necesaria. En mi caso diseños los fimrwares de manera tal que la comunicación con dispositivos externos ( eeprom, uart, rtc, etc ) son siempre con time-outs controlados por un timer. Si algún error acontece en el acceso a los mismos lo reporto a niveles superiores. El uso del watchdog solo se limita a protejer el equipo ante un evento extraño ( ruido, emi, esd, etc ) que fuerzen al firmware a volver a un punto conocido de ejecución ( en este caso el Reset ). Nunca uso el watchdog para corregir errores de programación, para eso uso los intensivos unit-test. Como ultimo punto trato de elegijr en lo posible watchdog que esten alimentados por un oscilador independiente del clock principal del sistema, hoy por hoy es una recomendacion que los mismos tengas varias fuentes de clock. Y en el peor de los casos y en ambientes muy hostiles utilizo watchdogs externos.
Saludos !
-
RICHI777 Como haces los unit-test? nos podes dar una pequeña idea? busco un poco por la web y parecen algo interesante
gracias
-
No entendí mucho la aplicación de migsantiago por lo del USB, yo tengo hecha una aplicación que cuando desconecto el cable vuelve al programa inicial, es decir, si no tiene comunicación USB tiene otras cosillas que hacer y no necesito el WDT.
Salvo que tu digas que el programa se quede clavado en la rutina de envio del endpoint.
Luego en casa lo estudio un poco mas el tema, seguro se me esta pasando algo por alto :oops:
En efecto, programé un par de cosas a nivel casi ASM y obligué al PIC a esperar indefinidamente a que el endpoint fuera transmitido. De esa forma es como logré transmitir datos a 64kB/s de parte del USB.
-
Hola, basicamente nuestro firmware se divide en muchas funciones, la idea de los unit-test es escribir explicitamente funciones especiales que se encargan de probar las funciones de nuestro firmware. Obvio que despues para produccion estas funciones que prueban nuestras funciones no se incluyen en la imagen binaria. Basicamente esa es la idea de los unit-test
Saludos !