WATCHDOG SÍ O WATCHDOG NO??

[maunix]

En mis programas largos, suelo tener un bucle principal del programa.  Es ahí donde lo reseteo al watchdog.

No lo hago en el vector de interrupción porque como suelo usar timers para una base de tiempo, me lo estaría reseteando constantemente lo cual no significa que el pic no se haya desviado su rumbo, sino que simplemente cada n milisegundos se resetea el watchdog entonces termina no funcionando para lo que lo quiero hacer funcionar.

Ponerlo 'a cada rato' tampoco es buena idea porque deja de tener efecto.  El watchdog es muy útil cuando el pic enloquece porque se cuelga el pic por alguna razón.  Nunca me pasó lo que comenta Azicuetano así que no soy el más indicado para comentar su técnica.

Si me pasó por ej. es que teniendo algunos pines de A/D al aire, cada N minutos, se colgaba el pic! así sin más, reveldemente.  Se ve que algo tildaba del hardware.  El watchdog en esos casos me salvaba del problema. 

Pero como te decia antes, no lo ejecuto a cada rato, sino solamente en el bucle principal.

[DarkVect]

Gracias Maunix.

Lo tengo funcionando en un programa más bien pequeño (30% en un PIC 16F84A) pero he puesto 4 restarts del watchdog. Uno en el bucle principal (while(TRUE)), otro en una rutina de inicialización de los parámetros que uso y luego otro en cada función de interrupción. Se que es exagerado, pero de momento ahora funciona, iré quitándolos a ver hasta cuando sigue funcionando.

De todas formas, el problema principal es que al usar el timer0 escalado, el watchdog lo tengo que usar a 18ms y me parecen muy pocos para lo que quiero hacer.

Seguiré informando de cómo va la cosa...

Gracias de nuevo!!

[Azicuetano]

Coincido con maunix.

A mi me gusta refrescar el watcdog en el bucle principal (y si es posible sólo una vez) y no recomiendo el refresco en las interrupciones.

Lo que hago es seleccionar un determinado tiempo en el watchdog y pongo un refresco en el bucle principal. Si el micro se está reseteando continuamente lo que hago es aumentar el tiempo del watcdog hasta que el equipo me funciona bien (o viceversa).

Además de todo esto también me gusta hacer lo siguiente:

Si pasamos por el bucle principal cada 10 ms (aproximadamente) configuro el wdt con 18ms y en el bucle principal (si la aplicación me lo permite) hago un retardo de unos 6 o 7 ms para que mi bucle principal tenga una duración de 17 ms (más o menos). Lo que consigo así es ajustar al máximo el wdt. Parece una tontería pero... por no ajustar bien el wdt en varias ocasiones que he tenido problemas de ruido y el wdt no me los ha solventado (porque se me ha refrescado aún sufriendo un salto el contador de programa).


Un saludo desde Alicante!

[DarkVect]

Bueno pués ya funciona con un solo restart_wdt() en el bucle principal. He eliminado algunos delay_ms que tenía por en medio y he usado el timer para contar esos tiempos.

Una pregunta, supongo que un poco tonta pero... cómo mides más o menos lo que tarda en ejecutarse un fragmento?? Me refiero algo a vista, sin usar timers, ni nada más, una cosa aproximada viendo el código.

Gracias!!

[maunix]

DarkVect, son decisiones que uno debe tomar y no puedo opinar si está bien o mal sin conocer tu aplicación.

Como dije antes, nunca me pasó o al menos no noté que el program counter salte como loco, sí me pasó que el pic deje de funcionar o se quede "como tildado", lo cual como dije antes, atribuyo más a un tema de ruido que deje al pic tal vez en un estado de "semi reset" o bien que en realidad afectase al circuito del oscilador del pic y por tanto no siga el curso del programa hasta tanto no se reinicia el pic.  Es entonces donde creo que reanuda el oscilador y por eso mi programa sigue funcionando.

Si tu programa no tiene más que hacer que siempre lo mismo y no importa tanto la secuencia cómo el hecho que lo haga, entonces poner muchos clrwdt no está mal.  Me explico: si tu programa tiene que por ejemplo refrescar unos 7 segmentos entonces lo más importante ahí es que el pic siga su curso en la ejecución entonces funciona tu técnica.  Ahora si se debe seguir cierta secuencia la cual se pierde por algún bug en el código o bien por algún problema externo, entonces si el vector de interrupciones se sigue llamando entonces tu pic no se reiniciará porque justamente es el vector de interrupciones el que lo resetea constantemente.

Cada diseñador embebido debe tomar estas decisiones y responden a tantas variables que es difícil en 2 líneas dar soluciones "generales" a estos problemas más allá de las antes mencionadas.

En mi opinión, hay ciertas cosas que son imprescindibles para un sistema que no deba falla:

- Un buen pcb: si uno la hace en pertinax, es candidato al óxido en unas semanas...
- Un buen circuito de masa: esto aumenta las chances de evitar que cualquier imprevisto de ruido nos afecte en la electrónica de nuestro circuito general
- Un circuito oscilador bien cuidado, tanto en sus conexiones a masa como en evitar las interferencias.
- Un shielding o protección, si es que tendremos o pensamos tener interferencias electromagnéticas, esto sobre todo es importante en el cristal.
- Un buen código: esto es inevitable y si todo lo anterior está bien y esto no, no nos salvaremos de nada 

Si se me ocurre alguna otra, la agrego

Saludos

[DarkVect]

Gracias por los consejos Maunix.

Me refería a algo así como lo que explicas, algunas pautas para poder decir que el "sistema no fallará". La aplicación es muy sencilla, se trata de un sistemita para medir la velocidad del viento, sin extremada exactitud, para ponerlo en casa y subir toldos, etc... cuando haga mucho viento.

Como digo funciona perfectamente con un solo reinicio del watchdog y creo que le sobra bastante tiempo. Probaré a añadir un delay al final del main para ver cuánto tiempo sobra de forma más exacta.

Un saludo!!