Watch dog timer consulta!!!

hola que tal ;

referente al wdt sabrian explicarme el porque de poner un wdt en un programa
por ejemplo en un programa cualquiera que funcion tiene poner un perro guardian
esque no termino de entender para que utilizarlo si un programa funciona igual sin el

y la cuestion es que en la mayoria de progrmas que he visto se pone

si bien se puede usar para cuando el micro este cierto tiempo sin trabajar que entre en modo sleep
pero no veo para que mas ponerlo

gracias por la ayuda
un saludo a todos
 
Yo no lo utilizo, se supone que una de sus aplicaciones es resetear el micro cuando entras en un bucle infinito. Es decir, si se "pasmó" tu programa por alguna razon imprevista o dependiente de un evento quizas externo que ya tardó demasiado en acontecer. Para esto tu programa debe limpiar continuamente el wdt asegurandote de que no pasara mas del tiempo configurado para que se llene este timer. Y si alguna funcion o bucle sale de control (o tarda demasiado) el wdt se desborda y resetea el micro.

No lo uso porque trato de tener el control de los bucles programandolos de tal manera que si el evento o condicion esperada tarda mucho, el mismo programa tome el control y ejecute alguna accion para evaluar y/o corregir el motivo de que la condicion no llegue.
 
Hola:

Regularmente cuando pruebas un código lo haces en un periodo de tiempo corto, en aplicaciones en los que tu micro tiene que operar por tiempos prolongados pueden existir condiciones que no contemplabas.
Ejemplo: tenía yo un programa de adquisición en los que una función llamaba a otra y esta función a otra y al final no retornaba a la función que la llamó originalmente. El micro va almacenando las direcciones a las que tiene que retornar en cada llamada(contador de programa). Al rebasar la capacidad del contador de programa, el micro modificaba parte de los datos de la ram(por estar juntos) y se perdía.
En la misma aplicación ocurrió que transitorios provocaban errores en el código y el micro se perdía.

Parte de lo anterior se resolvió con el uso del watchdog.
espero que les sea de utilidad.

saludos
 
Nuevamente aquí dando lata, lo que pasa es que en mi clase de instrumentación estamos viendo algo de PIC's y también vimos algo del perro guardián (watchdog) y nadie (ni el profesor) lo sabemos usar, quisiera que alguien explicara un poco ya que no hay mucha información de eso, desde ya muchas gracias !!
 
Hola, mendek. Lo cierto es que yo tampoco utilizo el watchdog. Lo desactivo por sencillez, ya que procuro que mi programa funcione bien, y ninguno de mis proyectos está expuesto a ambientes industriales llenos de transitorios, etc.

El funcionamiento, como ya te han comentado, se basa en un temporizador cuyo valor puedes configurar. Si lo tienes activado, este temporizador está siempre en funcionamiento intentando llegar al final de la cuenta. Pero antes de que llegue a ese final, tú lo vas a reiniciar, con lo que consigues que no llegue nunca. ¿Por qué? Porque es la forma de decirle al watchdog que todo va bien. En el caso de que tu programa no sea capaz de reiniciar el temporizador (porque se ha quedado bloqueado), este temporizador llegará al final de la cuenta. ¿Qué sucede entonces? Que el watchdog produce el reset del PIC.

A fin de cuentas es lo mismo que harías tú (o yo, o cualquiera) al ver que, por ejemplo, el PC se ha quedado bloqueado. Al pasar un tiempo sin ver actividad pulsaríamos RESET.

Casi todos los programas que se realizan constan de un bucle principal que se repite indefinidamente, produciendo las acciones que hayamos previsto. Una de esas acciones tiene que ser, precisamente, reiniciar el watchdog.



Dependiendo del tiempo que tarde tu programa en realizar un ciclo completo, tendrás que configurar el valor inicial de la cuenta del watchdog. Por ejemplo, si tu programa tarda un máximo de un milisegundo en hacer un ciclo, el tiempo de un ciclo del watchdog tendrá que ser mayor. De lo contrario, el PIC se reseteará cuando menos lo esperes.
 
Última edición:
Cualquier cosa semi-seria debe de llevar al menos uno. Los equipos que yo montaba llevaban dos y aún así...
El watchdog tan solo es un timer que al desbordarse resetea el micro. Lo programas todo lo ajustado que puedas para que si le pasa algo al programa resetee el sistema.
Lo complicado es poner las instrucciones justas en el bucle de tu programa para ir reseteando el timer para que nunca se dispare y nunca se resetee el micro.
Se basa en que si se cuelga el sistema o salta a algún sitio raro y tarda mas de la cuenta vuelve a empezar.
Como poco hace falta además un verificador del oscilador, el micro que yo usaba tenía un segundo comprobador que si detectaba que fallaba el oscilador funcionaba con un resonador interno a baja velocidad "para salvar los muebles", claro, activa una interrupción o el reset y activa un flag para que lo sepas.
Su uso no es complicado si no te hinchas a hacer bucles vacíos para temporizar, restauras siempre bien la pila y demás tonterías. Y te puede salvar de problemas serios.

Lo mas parecido en otros temas mas cotidianos es el freno de hombre muerto; todos los trenes llevan un pedal que si se deja de pulsar para el tren. Antes bastaba con poner "la caja de herramientas" sobre él, pero ya hace años que es una palanca o pulsador que hay que ir accionando, al pasar por cada señal también se pulsa una confirmación etc, si se muere el maquinista el tren se para.
 
Última edición:
Resumiendo un poco, es muy difícil que un proyecto complejo salga funcionando de una y muchas veces el código tiene bugs que se van corrigiendo sobre la marcha.

Esos bugs pueden ir desde olvidarse de un flag, hasta como dicen arriba provocar que el programa se "cuelgue" en algún punto. El watch dog es simplemente un "seguro" de que en caso de fallar volvés a empezar y además podés usarlo como identificador de problemas.

Yo particularmente el usó que le doy es para evitar el "cuelgue" por un tema de sencillez, le doy un tiempo prolongado (ej. 2Seg) y cada tanto refresco el timer. Pero un uso más inteligente para detectar errores puede ser el que menciona Scooter arriba, asignar pequeños intervalos de tiempo para asegurarse de que todo va bien en ciertas partes del código.

Para más información acá tenés una nota de aplicación que puede ser útil, independientemente del uC que uses.

http://www.atmel.com/Images/doc2551.pdf
 
Para cosas de poca seguridad no hace falta watchdog, pero según de que sea el sistema que estés controlando, con dos segundos de hacer lo que le de la gana igual ya hay muertos...
Los bugs deberían de estar depurados, pero siepre pude hacer un salto inpredecible por ruido eléctrico o algo. El problema no es que se pare en un bucle, el problema es que se ponga a hacer lo que le de la gana...
 
Para cosas de poca seguridad no hace falta watchdog,

Yo creo que si querés asegurarte que todo vaya bien, no está de más usar el watchdog, independientemente de que la aplicación sea o no por un tema de seguridad.

pero según de que sea el sistema que estés controlando, con dos segundos de hacer lo que le de la gana igual ya hay muertos...

En mi caso, por suerte la vida de nadie depende de la aplicación y me da igual 2, 5 o 10 segundos, mientras garantice que el equipo pueda recuperarse a la larga.

Los bugs deberían de estar depurados, pero siepre pude hacer un salto inpredecible por ruido eléctrico o algo.

No siempre se puede depurar al 100% una aplicación, sino preguntale a linksys y sus 1eros routers, en mi caso recién en la 3 actualización del firmware se solucionaron un montón de problemas.
 
¿El WDT solo resetea en los PIC? por que en un ejemplo de los MSP430 el WDT envía a una rutina de interrupción y en este caso se programa para hacer el típico ejemplo de destellar un LED, lo veo bastante útil desde ese punto, usarlo como otro timer adicional para llamar funciones mientras mantienes los otros para generar señales PWM.
 
Atrás
Arriba