Tengo un módulo de manejo de interrupciones que controla el hardware del controlador de interrupción en un procesador integrado. Ahora quiero agregarle más pruebas. Actualmente, las pruebas solo prueban si la anidación de interrupciones funciona al realizar dos interrupciones de software desde un ISR, una con baja prioridad y otra con alta prioridad. ¿Cómo puedo probar este módulo más?¿Cómo se prueba el módulo de manejo de interrupciones?
Sugiero que intente crear otros estímulos también.
A menudo, también las interrupciones de hardware pueden ser activadas por el software (prueba automática) o el depurador mediante el establecimiento de un indicador. O como una interrupción a través de E/S. O una interrupción de temporizador. O simplemente puede configurar el bit de interrupción en un controlador de interrupción a través del depurador mientras está en un solo paso.
Puede agregar algunas comprobaciones de tiempo de ejecución en cosas que no deberían ocurrir. A veces me elegir configurar los pines de salida para controlar externamente (bueno si usted tiene un osciloscopio o analizador lógico ...)
low_prio_isr(void)
{
LOW_PRIO_ISR=1;
if (1 == HIGH_PRIO_ISR)
{ this may never happen. dummy statement to allow breakpoint in debugger }
}
high_prio_isr(void)
{
HIGH_PRIO_ISR=1
}
La desventaja de la interrupción de software es que el momento es fijo; siempre la misma instrucción. Creo que le gustaría ver evidencia de que siempre funciona; punto muerto libre.
Para las rutinas de servicio de interrupción, considero que las revisiones de código son muy valiosas. Al final, solo puedes probar las situaciones que has imaginado y en algún momento el esfuerzo de prueba será muy alto. Los ISR son notoriamente difíciles de depurar.
creo que es útil para proporcionar pruebas para lo siguiente: - ISR no se interrumpe para interrumpir menor prioridad - ISR no se interrumpe para interrumpir la misma prioridad - ISR se interrumpe durante más alta prioridad de interrupción - recuento máximo de anidación dentro de las limitaciones de la pila.
Algunas de las pruebas pueden permanecer en el código como la instrumentación (para que pueda controlar, por ejemplo, el nivel máximo de anidamiento
Ah, y una cosa más:. En general, me las he arreglado para mantener ISR tan corto que lo que pueda abstenerse de anidación .... si puede esta usted ganará simplicidad adicional y más rendimiento.
[EDIT] por supuesto, ISR necesita ser probado en el hardware en el sistema también. Aparte del bit por -bit, paso a paso, es posible que desee probar: - estabilidad del sistema a la máxima carga de interrupción (preferiblemente varias veces e carga máxima prevista; si su controlador serial de 115kbps también puede manejar 2MBps ¡estará bien!) - momento correcto de habilitar/deshabilitar isr, especialmente si el sistema también ingresa en modo de suspensión - # de interrupciones. Puede ser sorprendente si agrega interruptores mecánicos, mecánicos rotativos (cientos de momentos de rotura/contacto antes de alcanzar una situación estable)
No soy un desarrollador integrado, por lo que no sé si esto es posible, pero ¿qué tal desvincular el código que maneja las interrupciones del mecanismo de registro de devolución de llamada? Esto le permitiría escribir el código del simulador eventos de interrupción de incendios como quiera ...
Es probable que no haya un mecanismo de registro de devolución de llamada. Se produce una interrupción y se llama a la rutina de servicio de interrupción apropiada (fija en tiempo de compilación). –
Recomiendo pruebas de hardware real. El manejo de interrupciones es intrínsecamente aleatorio e impredecible.
Utilice un generador de señal y alimente una onda cuadrada en el pin de interrupción apropiado. Use múltiples generadores (o uno con múltiples salidas) para probar múltiples líneas de IRQ y verificar el manejo de prioridad.
Experimente con marcar la frecuencia hasta & en los generadores de señal (varíe las tasas entre ellos), y vea qué pasa. Tener muchos códigos de diagnóstico para verificar el estado del controlador de interrupción en los diferentes estados.
Alternativa: Si su plataforma tiene temporizadores que pueden disparar interrupciones, puede usarlos en lugar de hardware externo.
Absolutamente cierto que los ISR deben probarse en hardware, sin embargo, mi experiencia es que se puede hacer mucho para demostrar su corrección en un entorno conocido. He visto que los ISR fallan a la mitad de un proyecto con síntomas extraños, por razones que no eran visibles durante las primeras pruebas de hardware, pero que se habrían expuesto mediante la revisión del código y las pruebas unitarias. – Adriaan
Para cosas como esta, recomiendo mucho algo como el SPIN model checker. Terminas probando el algoritmo, no el código, pero la prueba es exhaustiva. De vuelta en el día, I found a bug in gdb usando esta técnica.
+1 Buen resumen, especialmente comentarios sobre ISR cortos y evitando la anidación. – DrAl
+1 como dijo Al, y acepto que los ISR son particularmente buenos temas para las revisiones de código. –