Maneras correctas para implementar temporizadores de perro guardián incorporados estándar

1

Soy un poco nuevo con el uso de aplicaciones que usan temporizadores de vigilancia y estoy listo para usar uno por primera vez. Estoy usando pic18f26j50 y tengo un temporizador interno de vigilancia que tiene un límite de 2 ms y se puede ampliar hasta 2 minutos.

Comprendo que todo el propósito de usar los temporizadores internos para perros guardianes es evitar cualquier bloqueo accidental del código. Por lo tanto, me gustaría saber cuáles son las formas en las que se puede probar el temporizador de perros guardianes y demostrar que no es seguro hacerlo. patearlo correctamente sin ningún error.

Confío en que los comentarios de ustedes me ayudarán a escribir rutinas de prueba para que pueda entender sus características y también me gustaría que me informen sobre cualquier posible trampa, si las hay.

  

Y confío en que el perro guardián generalmente se borra dentro de la principal y otra   La pregunta que supongo que tengo es si tengo ciertos módulos A, B, C..N   que se llama en principal. ¿Cuáles son los requisitos para un diseñador?   tal que el reloj temporizador implementado cumple con el estándar y cuáles son   las cosas que el desarrollador debe mirar adecuadamente en tal   caso.

    
pregunta Rookie91

2 respuestas

2

Probablemente podría escribirse un libro sobre esto. Intentaré cubrir los puntos altos.

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

Un WDT no evitará nada, puede usarse para ayudar a recuperarse de un trastorno del sistema. Cuando se activa un tiempo de espera de WDT, sabes que algo realmente malo ha sucedido, pero no sabes exactamente qué, así que debes comenzar algún tipo de operación de recuperación. El procesador podría haberse apagado y haber hecho todo tipo de cosas: memoria dañada (RAM o EEPROM), reescrito SFR a valores incorrectos, establecer salidas a estados indeseables, etc. Lo primero que debe hacer es poner el sistema en una Estado "seguro" si eso es una preocupación, y si es posible. Por ejemplo, un calentador de 10kW se debe apagar en la mayoría de los casos (hay casos en los que "encendido" es mejor). Es posible que algunas cosas (considere un piloto automático de avión no tripulado) no tengan un estado pasivo seguro, y es posible que deba reanudar la operación e intentar recuperarse.

Antes de restablecer el WDT (como usted dice, debería suceder en la rutina principal) debe verificar tantas cosas como sea posible, no solo que llegó a la rutina de restablecimiento. Es posible que desee confirmar que los valores conocidos, como los SFR, no hayan cambiado (o volver a escribirlos si eso no perturba las cosas). Es una mala idea depender de los valores predeterminados de encendido. Es posible establecer indicadores que indican la finalización sin errores de operaciones importantes; puede hacer que los indicadores sean persistentes (marcar un error y nunca restablecerlo) luego, si su rutina de restablecimiento de WDT encuentra que el indicador ha sido configurado, tiene la opción de realizar una recuperación completa. Es una buena práctica tener el reinicio de WDT cercado por saltos para que no pueda ejecutarlo accidentalmente (por ejemplo, ejecutando los NOP en la memoria no utilizada). Algunas implementaciones de WDT tienen una función de ventana que requiere un tiempo mínimo entre reinicios y un máximo, lo que evita que alguna rutina no anticipada se reinicie accidentalmente.

En cuanto al tiempo de espera de WDT, desea que sea lo suficientemente corto como para que no ocurra nada malo, o que la WDT no sea tan útil. En el caso de un sistema térmico, un par de segundos puede 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 frecuencia suficiente.

Es mejor tener un WDT que no se puede desactivar desde el firmware y no se puede configurar a un tiempo de espera demasiado largo (que es casi lo mismo que estar desactivado). 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 una ejecución de bucle de control muy lenta, 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 software WDT a la rutina lenta. Un ejemplo de eso podría ser un sistema de movimiento que realiza un algoritmo de autoajuste en el fondo. Necesita un WDT muy rápido para evitar que el sistema realice movimientos indeseables, pero el autoajuste lleva más tiempo.

    
respondido por el Spehro Pefhany
2

Sí, es correcto que se utilice un temporizador de vigilancia (WDT) para capturar cualquier código que accidentalmente haga que el microcontrolador se bloquee debido a un bucle infinito.

Normalmente, las rutinas principales en el código incrustado están estructuradas de esta manera:

void main ()
{
    initialization();

    while (1)
    {
       routine_a();

       routine_b();

       // etc.

       CLear_WDT();
    }

    // never get to here
}

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

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

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

    Clear_WDT();

    i++;
}

Aquí tiene que garantizar a por 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 disparará el WDT. Tenga en cuenta que los tiempos de espera de los perros guardianes seguirán ocurriendo correctamente en las llamadas a las funciones de nivel inferior (como answer ()); lo que nos preocupa es solo el bucle de alto nivel que contiene la llamada Clear_WDT.

En general, no coloque llamadas a Clear_WDT dentro de las rutinas de interrupción, especialmente las interrupciones con temporizador, ya que esto 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 guárdalo en cualquier lugar de tu programa (en un lugar que se ejecutará, por supuesto). Cuando llegue a ese bucle, y nunca continúe, activará 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 en todo su código para evitar que el WDT se dispare, y lo suficientemente corto para ser útil (un WDT de dos minutos es No es muy diferente que solo dejar el sistema bloqueado). A menudo he usado un valor entre 2 y 8 segundos.

    
respondido por el tcrosley

Lea otras preguntas en las etiquetas