Probando un retraso de tiempo prolongado

1

He implementado un retraso prolongado con un pequeño microcontrolador (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 las demoras son de 21 horas y 3 horas, ¿cómo puedo probar esto ya que no sucede instantáneamente? He cambiado las horas a minutos, aunque necesitaré una forma de comprobar que la salida está apagada durante 21 horas y encendida durante 3 horas, y que no pasa nada dentro del microcontrolador, como el temporizador de vigilancia reiniciando la CPU. El código es lo suficientemente simple como para verlo, se puede ver que nada está realmente mal con la implementación, pero aún debe ser probado de alguna manera.

    
pregunta Dean

3 respuestas

2

Alimente un reloj mecánico con la salida del temporizador. Ya sea un reloj de red, o uno de estos movimientos de reloj barato de una batería AA que aparecen en todas partes, dependiendo de lo que cambie su sistema de prueba.

Ajuste el reloj de prueba a las 12:00, registre la hora en que programó el temporizador. Solo necesita hacer tres visitas más a la configuración de la prueba, y sus horarios son bastante flexibles. Haga la primera visita antes de las 21 horas, para comprobar si el reloj de prueba aún muestra las 12:00. Visite entre 21 y 24 horas después de comenzar, para verificar que el reloj de prueba esté funcionando y que la hora que se muestra indique que comenzó cuando se esperaba. Realice la próxima visita entre 24 y 45 horas, para asegurarse de que se haya detenido, mostrando una hora de 03:00.

Si desea que las pruebas documentales de la prueba funcionen, fotografíe el reloj de prueba junto a un reloj de hora y fecha que funciona normalmente, y anote la impresión a mano para explicar qué se puede concluir a partir de los tiempos.

Si guarda la prueba en un armario durante una semana, cuando regrese, el reloj de prueba debería haber avanzado 3 horas por día de la prueba.

    
respondido por el Neil_UK
1

Si tiene un multímetro de registro, puede conectarlo y ejecutar el dispositivo durante 24 horas. Una solución de gueto es apuntar una cámara a un multímetro normal y dejar que grabe durante 24 horas. La descarga de la batería en el multímetro es un problema, por lo que es posible que tenga que armar una solución para esto a menos que tenga un multímetro de banco.

Pero no creo que debas preocuparte por el perro guardián. No hay perros guardianes de los microcontroladores por más de unos pocos segundos, y ya que no está reiniciando el perro guardián en el ISR, aún se activará durante una prueba más corta.

Se te ocurren dos cosas obvias que pueden salir mal, y puedes probar cada una por separado: la primera es que arruinas la configuración del temporizador del hardware para que el ISR se active más rápido o más lento de lo esperado. Puede probar esto haciendo que el tiempo requerido para voltear las salidas sea más corto 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.

    
respondido por el pipe
0

Como alternativa a la codificación manual de un esquema de temporización, puede conectarse a 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 de la RTCC es que se ejecuta constantemente, generalmente con muy poca energía, y está programado con una fecha y hora para "alarmar". Una vez probado con un período de tiempo más corto, los períodos de tiempo más largos son casi sin errores.

    
respondido por el rdtsc

Lea otras preguntas en las etiquetas