Formas correctas de implementar temporizadores de vigilancia incorporados estándar

Probablemente se podría escribir un libro sobre esto. Intentaré cubrir los puntos más importantes.

El WDT es una herramienta que se puede utilizar para ayudar a satisfacer algunos requisitos a nivel del sistema, y ​​esos requisitos son la motivación principal. Pueden estar relacionados con la seguridad o surgir del deseo de reducir algunas molestias para el usuario. Existen otras herramientas, como monitores de reloj, WDT externos, redundancia, interrupciones en el acceso a ubicaciones de memoria inadecuadas, enclavamientos de varios tipos, etc.

Un WDT no evitará nada; se puede usar para ayudar a recuperarse de una alteración del sistema. Cuando se activa un tiempo de espera de WDT, sabe que ha sucedido algo realmente malo, pero no sabe exactamente qué, por lo que debe comenzar algún tipo de operación de recuperación. El procesador podría haberse apagado y hecho todo tipo de cosas: memoria dañada (RAM o EEPROM), reescrito SFR a valores incorrectos, establecer salidas en estados no deseados, etc. Lo primero que debe hacer es poner el sistema en un estado 'seguro' si eso es una preocupación, y si es posible. Por ejemplo, un calefactor de 10kW debe estar 'apagado' en la mayoría de los casos (hay casos en los que 'encendido' es mejor). Algunas cosas (considere el piloto automático de un dron) pueden no tener un estado pasivo seguro, y es posible que deba reanudar la operación e intentar recuperarse.

Antes de reiniciar el WDT (como dices, debería suceder en la rutina principal) debes verificar tantas cosas como sea posible, no solo que llegaste a la rutina de reinicio. Es posible que desee confirmar que los valores conocidos, como los SFR, no han cambiado (o volver a escribirlos si eso no perturba las cosas). Es una mala idea depender de los valores predeterminados de encendido. Es posible configurar banderas que indiquen la finalización sin errores de operaciones importantes; puede hacer que las banderas sean persistentes (marcar un error y nunca restablecerlo) luego, si su rutina de reinicio de WDT encuentra que la bandera se ha configurado, tiene la opción de realizar una recuperación completa. Es una buena práctica tener el WDT reiniciado cercado por saltos para que no pueda toparse con él por accidente (por ejemplo, ejecutando NOP en la memoria no utilizada).

En cuanto al tiempo de espera de WDT, desea que sea lo suficientemente corto como para que no suceda nada malo, o el WDT no será tan útil. En el caso de un sistema térmico, un par de segundos pueden no ser un problema. En el caso del sistema de control de movimiento, los milisegundos podrían ser mejores. Demasiado frecuente y puede tener problemas para restablecerlo con la suficiente frecuencia.

Es mejor tener un WDT que no se pueda deshabilitar desde el firmware y que no se pueda configurar en un tiempo de espera demasiado largo (que es casi lo mismo que estar deshabilitado). Por lo general, los procesadores bien diseñados tienen alguna protección contra un procesador errante que hace ese tipo de cosas.

En el caso de que tenga que restablecerlo con mucha frecuencia, pero tiene un ciclo de control muy lento ejecutándose, puede usar una bandera o un temporizador para indicar un problema en la rutina lenta y restablecer el WDT si se agota el tiempo. Eso, esencialmente, agrega un WDT de software a la rutina lenta. Un ejemplo de eso podría ser un sistema de movimiento que hace un algoritmo de ajuste automático en segundo plano. Necesitas un WDT muy rápido para evitar que el sistema realice movimientos no deseados, pero el autoajuste lleva más tiempo.

Sí, tiene razón en que se usa un temporizador de vigilancia (WDT) para capturar cualquier código que accidentalmente haría que el microcontrolador se bloqueara debido a un bucle infinito.

Por lo general, las rutinas principales en el código incrustado están estructuradas de la siguiente manera:

void main ()
{
    initialization();

    while (1)
    {
       routine_a();

       routine_b();

       // etc.

       CLear_WDT();
    }

    // never get to here
}

Claramente, debe tener una llamada para borrar el WDT al final de este bucle (al que llamo Clear_WDT), como se muestra. Pero a menudo, deberá incluir llamadas adicionales a esta función en las rutinas de nivel inferior, si tienen algún código que puede tardar mucho tiempo en ejecutarse (lo suficiente como para disparar su WDT de todos modos).

A veces, es posible que deba realizar una llamada para borrar el WDT dentro de un ciclo while; por ejemplo, aquí hay un bucle que espera hasta 20 segundos por una respuesta de un dispositivo remoto:

i = 0;
while (i < 20)
{
    if (answer())
    {
        break;
    }
    delay_ms(1000);

    Clear_WDT();

    i++;
}

Aquí tiene que garantizar mediante inspección que el bucle saldrá cuando el tiempo de espera supere los 20 segundos (20 veces a través del bucle). Si falta la llamada a i++, nunca saldrá del bucle, pero tampoco activará el WDT. Tenga en cuenta que los tiempos de espera del perro guardián aún ocurrirán correctamente en cualquier llamada a funciones de nivel inferior (como respuesta ()); es solo el bucle de alto nivel que contiene la llamada Clear_WDT lo que preocupa.

En general, no coloque llamadas a Clear_WDT dentro de ninguna rutina de interrupción, especialmente interrupciones de temporizador, ya que eso anularía el propósito.

Probar un WDT es bastante simple; simplemente cree un bucle infinito que no contenga una llamada a Clear_WDT:

while (1)
{
}

y péguelo en cualquier lugar de su programa (en un lugar que se ejecutará, por supuesto). Cuando llegue a ese ciclo y nunca continúe, iniciará su WDT.

El valor de tiempo de espera para un WDT debe ser lo suficientemente largo para que no tenga que esparcir llamadas a Clear_WDT por todo el código para evitar que se dispare el WDT, y lo suficientemente corto para que sea útil (un WDT de dos minutos no es muy diferente que dejar que el sistema se bloquee). A menudo he usado un valor entre 2 y 8 segundos.