unitarias - Patrones de prueba unitaria para microcontrolador código C
pruebas unitarias para que sirve (4)
¿Existe tal vez algún tipo de modo de bucle de retorno para que pueda usar el controlador para generar eventos con los que pueda probar?
Aunque hay muchos marcos de prueba de unidad que admiten C, estoy un poco perplejo sobre cómo escribir pruebas de unidad para el código del microcontrolador (PIC en mi caso, pero creo que la pregunta es más general que eso).
Gran parte del código escrito para microcontroladores gira en torno a la escritura de valores de configuración y datos en los registros, la lectura de los datos entrantes de los registros y la respuesta a eventos de interrupción. Me pregunto si alguien puede proporcionar algunos consejos sobre la forma más efectiva de hacerlo.
Escribir versiones simuladas de sus funciones de acceso de registro / macros. Tenga en cuenta que esto supone que su código utiliza un conjunto común de funciones de acceso a registros, y no elementos ad-hoc como *(volatile int*)0xDEADBEEF = 0xBADF00D todas partes.
Llame a sus controladores de interrupción directamente desde su código de prueba (puede ser problemático en algunas arquitecturas¹), una "interrupción de software" si está disponible, o desde un controlador de interrupción de temporizador si necesita que se ejecuten de forma asíncrona. Esto puede requerir ajustar su código de habilitación / deshabilitación de interrupción en las funciones / macros que puede simular.
¹ 8051 viene a la mente: al menos con el compilador Keil 8051, no puede llamar directamente a las funciones de interrupción. Esto podría ser resuelto con el preprocesador C sin embargo.
Usted escribe;
"Gran parte del código escrito para microcontroladores gira en torno a la escritura de valores de configuración y datos en los registros, la lectura de los datos entrantes de los registros y la respuesta a eventos de interrupción".
Estoy de acuerdo en que esto suele ser el caso en la práctica, pero en realidad no creo que sea algo bueno, y creo que repensar un poco las cosas te ayudará con tus objetivos de prueba.
Tal vez debido a que los programadores de microcontroladores pueden alcanzar y tocar el hardware en cualquier momento que lo deseen, muchos (¿la mayoría?) Tienen la costumbre de hacer precisamente eso, a lo largo de su código. A menudo, este hábito se sigue de manera incuestionable, tal vez porque muchas personas que realizan este tipo de trabajo no son expertos en informática por capacitación e inclinación. Lo sé, yo empecé de esa manera yo mismo.
El punto que estoy tratando de hacer es que los proyectos de microcontroladores pueden y deben estar bien diseñados como cualquier otro proyecto de software. Una parte realmente importante de un buen diseño es restringir el acceso de hardware a los controladores de hardware. Particione todo el código que escribe registros, responde a interrupciones, etc. en módulos que proporcionan al resto de su software un acceso agradable, limpio y abstracto al hardware. Pruebe esos módulos controladores en el objetivo utilizando analizadores lógicos, osciloscopios, plataformas de prueba personalizadas o cualquier otra cosa que tenga sentido.
Un punto realmente importante es que ahora el resto de su software, con suerte la gran mayoría, ahora es solo un código C que puede ejecutar y probar en un sistema host. En el sistema host, los módulos de hardware se apagan de una manera que proporciona visibilidad de lo que está haciendo el código bajo prueba. Puede utilizar los métodos de prueba de unidades principales en este código. Esto requiere algunos preparativos y trabajo, pero si está bien organizado, puede crear un sistema reutilizable que pueda aplicarse a todos sus proyectos. Los beneficios potenciales son enormes. Escribí un poco más sobre estas ideas aquí;
[ http://discuss.joelonsoftware.com/default.asp?joel.3.530964.12][1]
Un enfoque para esto podría ser usar un emulador. He estado trabajando en un emulador AVR y una de las ideas para usarlo es, de hecho, a un código de prueba de unidad. El emulador implementa la CPU y registra, interrumpe y varios periféricos, y (en mi caso) los bytes escritos en la UART emulada van a la salida stdout del emulador. De esta manera, el código de prueba de la unidad puede ejecutarse en el emulador y escribir los resultados de la prueba en la consola.
Por supuesto, uno también debe asegurarse de que el emulador esté implementando correctamente el comportamiento de la CPU real, de lo contrario, las pruebas de la unidad no pueden ser confiables.