patrones de pruebas unitarias para el código C microcontrolador

Question

A pesar de que hay un montón de marcos de prueba de unidad que soporta C, estoy un poco perplejo sobre cómo escribir pruebas unitarias para el código de microcontrolador PIC (en mi caso, pero creo que la pregunta es más general que eso).

Gran parte del código escrito para los controladores de micro gira en torno a la escritura de valores de configuración y de datos a los registros, la lectura de los datos de entrada de los registros y la respuesta a eventos de interrupción. Me pregunto si alguien puede dar algunas indicaciones sobre la forma más eficaz para esto.

Answer 1

Usted escribe;

"Gran parte del código escrito para microcontroladores gira en torno a la escritura de valores de configuración y de datos a los registros, la lectura de los datos de entrada de los registros y la respuesta a eventos de interrupción".

Estoy de acuerdo que esto es a menudo el caso en la práctica, pero en realidad no creo que esto es una buena cosa, y creo que replantear las cosas un poco le ayudará con sus objetivos de prueba.

Tal vez porque los programadores de microcontroladores puede alcanzar y tocar el hardware cualquier momento que les gusta, muchos (la mayoría?) De ellos han tomado la costumbre de hacer precisamente eso, a través de su código. A menudo, este hábito es seguido incondicionalmente, tal vez debido a que muchas personas que hacen este tipo de trabajo son las EE no científicos de la computación por la formación y la inclinación. Lo sé, empecé a cabo de esa manera a mí 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 muy importante de un buen diseño es para restringir el acceso al hardware de los controladores de hardware! Compartimentar todo el código que escribe registros, responde a las interrupciones, etc., en los módulos que proporcionan el resto de su software con agradable,, acceso limpio abstraído al hardware. Probar los módulos de los controladores en el destino mediante analizadores lógicos, osciloscopios, bancos de prueba personalizada o cualquier otra cosa que tiene sentido.

Un punto muy importante es que ahora el resto de su software, es de esperar que la gran mayoría de ella, ahora es sólo el código C que puede ejecutar y probar en un sistema host. En el sistema host los módulos de hardware se apagaron de una manera que proporciona visibilidad de lo que el código bajo prueba está haciendo. Puede utilizar los principales enfoques de pruebas unitarias en este código. Esto necesita algunos preparativos y el trabajo, pero si está bien organizado puede crear un sistema reutilizable que se puede aplicar 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]

Answer 2

Un enfoque para esto podría ser el uso de un emulador. He estado trabajando en un emulador AVR y una de las ideas para el uso de hecho es que el código de prueba unidad. El emulador implementa la CPU y registros, las interrupciones y varios periféricos, y (en mi caso) bytes escritos al UART emulado ir al stdout regular del emulador. De esta manera, el código de prueba de unidad se puede ejecutar en el emulador y escribir sus resultados de la prueba a la consola.

Por supuesto, también hay que asegurarse de que el emulador está llevando a cabo correctamente el comportamiento de la CPU real, de lo contrario las pruebas de unidad en la parte superior de la que no se puede confiar.

Answer 3

Escribir versiones simuladas de sus funciones de acceso a registro / macros. Tenga en cuenta que esto supone que el código utiliza un conjunto común de funciones de acceso a registro, y no cosas 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 algunos architectures¹), una "interrupción de software" si está disponible, o desde un controlador de interrupción del temporizador, si los necesita para ejecutar de forma asincrónica. Esto puede requerir envolver el código de habilitación de interrupción / desactivación de funciones / macros que puede maqueta.

¹ 8051 viene a la mente: al menos con el compilador Keil 8051, no se puede llamar directamente a funciones de interrupción. Esto podría ser resuelto con el preprocesador C embargo.

Answer 4

¿Hay acaso algún tipo de modo de bucle para que pueda utilizar el propio controlador para generar eventos que se pueden probar en contra?