Código de prueba para Embedded Application

Question

Antecedentes:

Estoy desarrollando un proyecto bastante grande utilizando al Atmega2560 Atmel AVR. Este proyecto contiene una gran cantidad de funciones basadas en hardware (dispositivos 7 SPI, I2C 2, 2 puertos RS485 MODBUS, un montón de Analógica y Digital I / O). He desarrollado "drivers" para todos estos dispositivos que proporcionan el bucle principal de la aplicación con una interfaz para acceder a los datos requeridos.

Pregunta:

El proyecto que estoy desarrollando con el tiempo tendrá que cumplen con las normas SIL.

Me gustaría ser capaz de probar el código y proporcionar un buen nivel de cobertura de código. Sin embargo no puedo encontrar ninguna información que me refiero a cómo un marco de este tipo de pruebas se debe crear.

La idea es que puedo tener un conjunto de pruebas automatizadas que permitirán correcciones de errores y futuro nuevas características para ser probado para ver si rompen el código. Lo que pasa es que no entiendo cómo el código puede ser probado en el chip.

¿Necesito hardware para controlar la E / S en el dispositivo y emular dispositivos conectados externamente? Cualquier punteros que podrían proporcionarse sería muy apreciada.

- Steve

Answer 1

Esta es una muy buena pregunta - una preocupación común para los desarrolladores de sistemas integrados. Por desgracia, los desarrolladores más implícitos no están tan preocupados como usted es y sólo probar el código en el hardware real. Pero como otra respuesta señaló, esto básicamente se puede probar sólo la funcionalidad nominal del código y no casos de error de la esquina /.

No hay una solución única y sencilla a este problema. Algunas pautas y técnicas existen, sin embargo, para hacer un trabajo relativamente bueno.

En primer lugar, separar el código en capas. Una capa debe ser "agnóstica de hardware" - es decir, Función llamadas . No le pida al usuario escribir en los registros HW directamente. Los otros (inferiores) ofertas de capa con una HW. Esta capa puede ser "burlado" con el fin de probar el nivel más alto. El nivel inferior no puede ser verdad a prueba sin la HW, pero no va a cambiar a menudo y necesita la integración HW profunda, así que no es un problema.

Un "instrumento de prueba" será todo su alto nivel HW código agnóstico con un "falso" nivel inferior específicamente para la prueba. Esto puede simular los dispositivos de HW para la funcionalidad correcta e incorrecta y por lo tanto permite llevar a cabo pruebas automatizadas en el PC.

Answer 2

Nunca se quede en las pruebas unitarias o en contra del hardware real. Siempre burlarse de sus interfaces de E / S. De lo contrario, puede condiciones de error no simula y, más importante, no se puede confiar en la prueba para tener éxito.

Así que lo que necesita es dividir su aplicación en varias piezas que se pueden probar de forma independiente. Simulador (o simulado) todo el hardware que necesita para esas pruebas y los ejecute en su PC de desarrollo.

Esto debe cubrir la mayor parte de su código y te deja con los conductores. Tratar de hacer la mayor cantidad de código del controlador de lo posible el trabajo sin el hardware. Por lo demás, usted tiene que averiguar una manera de hacer funcionar el código en el hardware. Esto generalmente significa que se debe crear un banco de pruebas con dispositivos externos que responden a las señales, etc. Dado que este es frágil (como en "las pruebas no pueden hacer este trabajo de forma automática"), debe ejecutar estas pruebas de forma manual después de preparar el hardware.

Answer 3

Vectorcast es una herramienta comercial para ejecutar pruebas unitarias en el hardware con cobertura de código.

Answer 4

¿Tiene un conector JTAG? Es posible que pueda utilizar JTAG a las condiciones de error simulación activado el chip.

Answer 5

Me gusta separar las tareas. Por ejemplo, cuando hice un buffer circular para mi Atmel AVR escribí todo en Code :: Blocks y compilado con el compilador GCC regulares en lugar del compilador AVR GCC, entonces se crea una unidad de prueba para ello. He utilizado un archivo de cabecera especial para proporcionar los tipos de datos adecuados que quería trabajar con (uint8_t por ejemplo). He encontrado errores en las pruebas de unidad, ellos fijo, luego tomó el código fijo a AVR Studio y lo integró. Después de que he usado escribió funciones de apoyo y los ISR para adaptarse a la memoria intermedia en el código útil (es decir, el pop de un byte de la memoria intermedia, empujarla en el registro de salida de datos UART, anexar una constante de cadena en el búfer para una función printf, etc.). Luego utiliza el simulador AVR para asegurarse de que mis ISR y funciones estaban siendo llamados y que los datos correctos presenté en los registros. Después de eso me programé en el chip y funcionó perfectamente.

Yo prefiero en gran medida las capacidades de depuración de Code :: Blocks en comparación con AVR Studio, así que uso el enfoque anterior siempre que puedo. Cuando no puedo estoy por lo general se trata de único hardware. Por ejemplo tengo un temporizador que automáticamente produce una onda cuadrada. Lo mejor que podía hacer era ver que el bit pin estaba siendo hizo girar en el simulador. Después de eso sólo tenía que enganchar un ámbito de seguridad y asegúrese.

Me gusta usar un enfoque de múltiples niveles para depurar problemas. Por ejemplo, con el reloj de la primera capa es 'Escribe una sonda en el pin de reloj y ver si hay una señal de que hay'. En caso contrario, sondear el pasador en la UC y buscar la señal. Entonces, codifiqué una interfaz de depuración en uno de mis UART donde puedo mirar a los valores de registro específicos y asegurarse de que son lo que deben ser. Así que si no funciona el siguiente paso es 'llamar el valor del registro y asegurarse de que es correcta.'

Trate de pensar en el futuro cuatro pasos más o menos cada vez que usted está planeando su depuración. No debe haber + 5V aquí, pero lo que si no hay? Escribir en la interfaz de depuración una manera de cambiar el pasador y ver si eso cambia ella. ¿Y si eso no funciona? Hacer otra cosa, etc, etc, etc. Se llega a un punto en el que correr en 'No tengo ni idea de por qué DANG así que no funciona !!!!' pero esperamos que pueda averiguar la razón de antemano.