Implementar un watch-dog con Netduino

¿Qué pasa si usted crea su propia aplicación Netduino, y un error lo  detiene de forma inesperada?
Primera respuesta: no hay problema, estoy en frente del depurador, y voy a tener el seguimiento de la pila completa de la excepción.
Segunda respuesta: es una pesadilla! Estoy en vacaciones de fin de semana, y mi sistema de rociadores basado en  Netduino se ha colgado de modo que tengo que pedirle  a mi vecino que resetee mi Netduino

Obviamente estamos interesados ​​en la segunda respuesta, o-mejor-la forma de evitar, como situación.

Cuando el hardware está dañado o el software está libre de errores, no hay muchas maneras de rescatar el control de la placa. Sin embargo, hay muchas, muchas situaciones donde nuestra placa funciona perfectamente (tal vez por semana) sin ningún problema en absoluto y tn pronto se mueve «en el lugar», el primer problema que ocurre…
Dado que ninguno de utilización gustaría ser despertar a las 3 am para una parada del sistema, u obligarnos a volver a casa porque el rociador basado con Netduino no funciona correctamente, entonces podríamos hacer cumplir la fiabilidad mediante la adición de un así llamado «perro guardián».
Es una forma muy sencilla de proteger el sistema de paradas no deseadas y  nos resuelve toda esta problematica pues  una buena práctica de programación, junto con un buen hardware, es el deber-tiene redundancia para la mayoría de la fiabilidad de cualquier sistema.

WatchDog externo

No sé quién inventó este nombre WatchDog … «perro guardián» … pero suena claro (al menos para mí) que hay dos temas diferentes:
  • el perro, que es el controlador;
  • la casa está vigilada por el perro.
Ahora, el sistema que falla potencial es la casa, y el perro vive respeto «externa» de la casa.
Eso es obvio, ya que si el sistema se bloquea se podría hacer la misma en el rescate?
Es tan obvio, que muchas personas están pidiendo una solución de software pura, tal vez usando un hilo separado como un controlador.
Hay taaaan muchas situaciones que pueden obtener un MCU para colgar, que llevarían a alguien de inmediato a una solución externa.
Algunos ejemplos:
  • sub o sobre-temperatura;
  • picos de tensión (tanto por encima de la oferta y por debajo del suelo);
  • fuerte ruido en general (especialmente cuando los cables largos están conectados directamente a los pernos de MCU);
  • errores de software;
  • la inestabilidad de hardware (por ejemplo, el cristal se detiene oscilante);
  • muchos otros.
Podría haber usado un chip personalizado para un perro guardián. El chip Atmel del Netduino incrusta un perro guardián, pero no ha sido impulsado por el firmware.
En su lugar, me gustaría mostrar un circuito muy simple diseñado por Mario Vernari , cuyo objetivo es principalmente intentar resolver este problema en particular.

Usaremos un simple contador: el 74HC4060 . Es un contador binario de 14 etapas, que incrusta también un oscilador RC básica. Todo esto para obtener una re-activable, de largo periodo del temporizador.
La palabra «timer» llama inmediatamente en mi mente la increíble » 555 «chip: una obra maestra en el diseño del hardware de los ’70. BTW, tenemos un tiempo de reacción relativamente largo: al menos varios segundos.Eso es porque el Netduino tarda un par de segundos para completar el proceso de restablecimiento completo, entonces debemos tener en cuenta la lentitud del programa. Un organismo de control normales reacciona en milésimas de segundo, mientras que aquí estamos considerando docena de segundos, tal vez más. Durante un largo tiempo como el 555-temporizador normal no es confiable, porque se basa en la carga de los condensadores. Además, necesitaríamos un gran condensador bonita.
El 74HC4060 es mucho más simple para tiempos largos. Me desconecté el oscilador de frecuencia de alrededor de 60 Hz, que es el uso de:
  • Rt = 2.7k
  • Ct = 100n
Nota: consulte las 74HC4060 especificaciones.
Entonces, opté por la salida de la 10 ª etapa (es decir, Q9) como «tiempo de espera de señal», que desencadena el reinicio Netduino después de unos 10 segundos. Ahora, diez etapas binarias producen una división de frecuencia de 1024 (= 2 ^ 10), ¿por qué 60 Hz dividido por 1024 no cede 10 segundos, pero 20?
Debido a que el reinicio ocurre tan pronto la salida Q9 resulta alta, que es después de sólo la mitad del tiempo total.
Así que, ¿cuál es el papel de la Netduino, tener miedo de poner a cero desde el 74HC4060?
Bueno, sí … el programa se ejecuta en el Netduino debe «refrescar» constantemente el contador, por lo que no será nunca llegar al Q9 alta. Básicamente tenemos que cualquiera de las salidas Netduino generando un impulso positivo a corto, que tiene que reiniciar el contador. Hasta la aplicación Netduino está funcionando correctamente, el pulso se mantendrá el contador en un valor relativamente bajo, y Q9 nunca le des alta. Por cierto, cuando el programa se cuelga, no hay generación de impulsos más reset, y el contador se puede ejecutar para alcanzar el Q9 alta. Esa señal se restablecerá la Netduino.

Un programa de prueba simple.

El programa siguiente se utiliza como una prueba para el organismo de control.
Esto hace que el LED intermitente durante un período determinado, a continuación, genera una excepción. Eso es un «bug» simulado, que en realidad cuelga todo el tablero. Bajo tales circunstancias, usted tiene sólo dos opciones: pulsar el botón «reset», o desconecte y conecte la alimentación nuevamente. Dado que ninguno de ellos es adecuado funcionamiento para un contexto remoto, nos introducimos un poco de «ayuda», que «presione el botón de reinicio para nosotros».
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoPlus;
namespace NetduinoWatchdog
{
    public class Program
    {
        public static void Main()
        {
            //define the led port
            var led = new OutputPort(Pins.ONBOARD_LED, false);
            //just a long loop to make the led blinking
            for (int i = 0; i < 1000; i++)
            {
                //call the critical section
                Freezer(i);
                //wait for a while, then toggle the led status
                Thread.Sleep(100);
                led.Write(
                    !led.Read()
                    );
            }
        }
        static void Freezer(int count)
        {
            //this is just to simulate an unexpected event
            if (count == 20)
                throw new Exception();
            //keep the dog awaken
            Watchdog();
        }
        //define the watchdog port
        static OutputPort wdt = new OutputPort(Pins.GPIO_PIN_A5, false);
        static void Watchdog()
        {
            //generate a positive pulse to reset the external counter
            wdt.Write(true);
            wdt.Write(false);
        }
    }
}

Esta claro que el código, se centra principalmente el circuito externo mediante el 74HC4060 por lo que una fuente similar colgará cada vez que se inice este programa por lo que no tiene sentido en un contexto real. Una aplicación más realista debería ser mucho más «a prueba de excepción-libre», y tal vez ser capaz de «corregirse» en un cierto fracaso. Por ejemplo, considere la posibilidad de su aplicación está escribiendo un archivo en la tarjeta SD, pero el usuario saque la tarjeta. Es un poco difícil de escribir un procedimiento a prueba de balas que escribe los datos sin ninguna excepción. Sin embargo, una vez que el Netduino se ha restablecido, puede analizar la presencia en SD, y evitar cualquier operación relacionada

Fuente  Mario Vernari

solo-electronicos por Carlos Rodriguez Navarro se encuentra bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 3.0 Unported.

Deja una respuesta