Implementé un retraso de tiempo prolongado con un microcontrolador pequeño (MSP430), sin embargo, necesito probar y verificar que funciona como esperaba.
Mi algoritmo es el siguiente:
main()
{
//Init Timer
//Init Output
//Sleep
}
ISR_Timer()
{
//increment minutes
//if output off and enough time elapsed
//Turn output on
//Reset elapsed time
//else if output on and enough time elapsed
//Turn output off
//Reset elapsed time
}
Debido a que los retrasos son de 21 horas y 3 horas, ¿cómo puedo probar esto ya que no sucede instantáneamente? Cambié las horas a minutos, aunque necesitaré una forma de probar que la salida está apagada durante 21 horas y encendida durante 3 horas, y que no sucede nada dentro del microcontrolador, como el temporizador de vigilancia que reinicia la CPU. El código es lo suficientemente simple como para que, al revisarlo, se pueda ver que nada está realmente mal con la implementación, pero aún debe probarse de alguna manera.
Alimenta un reloj mecánico con la salida del temporizador. O un reloj de red, o uno de estos movimientos de reloj baratos con batería AA que aparecen en todas partes, dependiendo de lo que cambie su sistema de prueba.
Configure el reloj de prueba a las 12:00, registre la hora en que configuró el temporizador. Solo necesita hacer tres visitas más a la configuración de prueba, y sus tiempos son bastante flexibles. Realice la primera visita antes de las 21 horas, para comprobar que el reloj de prueba todavía marca las 12:00. Visite entre 21 y 24 horas después del inicio, para verificar que el reloj de prueba esté funcionando y que el tiempo que se muestra indique que comenzó cuando se esperaba. Realice la próxima visita en algún momento entre 24 y 45 horas, para asegurarse de que está detenido, mostrando un horario de 03:00.
Si desea evidencia documental del funcionamiento de la prueba, fotografíe el reloj de prueba junto a un reloj de hora y fecha que funcione normalmente, y anote la impresión a mano para explicar qué se puede concluir a partir de las horas.
Si guarda la prueba en un armario durante una semana, cuando regrese, el reloj de la prueba debería haber adelantado 3 horas por día de la prueba.
Si tiene un multímetro de registro, puede conectarlo y ejecutarlo durante 24 horas. Una solución de gueto es apuntar una cámara a un multímetro normal y dejar que registre durante 24 horas. El agotamiento de la batería en el multímetro es un problema, por lo que es posible que deba encontrar una solución a esto a menos que tenga un multímetro de banco.
Pero no creo que debas preocuparte por el perro guardián. No hay vigilantes del microcontrolador que duren más de unos pocos segundos y, dado que no está reiniciando el vigilante en el ISR, aún se activará durante una prueba más corta.
Me vienen a la mente dos cosas obvias que pueden salir mal, y puede probar cada una de ellas por separado: la primera es que estropea la configuración del temporizador de hardware para que el ISR se active más rápido o más lento de lo esperado. Puede probar esto acortando el tiempo requerido para voltear las salidas dentro del ISR sin tocar el código de hardware. La segunda es que puede tener problemas con los desbordamientos en los contadores de tiempo. Esto se puede probar manteniendo el ISR como está, pero haciendo que el temporizador de hardware se dispare mucho más rápido.
Estas pruebas son más fáciles con un osciloscopio digital con una base de tiempo muy larga.
Como alternativa a la codificación manual de un esquema de tiempo, puede interactuar con un chip de calendario de reloj en tiempo real. Muchos de estos circuitos integrados incluyen una función de alarma que puede activar el microcontrolador. Lo bueno del RTCC es que funciona constantemente, generalmente con muy poca energía, y está programado con una fecha y hora para activar la "alarma". Una vez probado con un lapso de tiempo más corto, los lapsos de tiempo más largos son casi seguros sin errores.
mcmiln