Código de ensayo para Embedded Application

Question

Antecedentes:

estoy desarrollando un proyecto bastante grande utilizando al Atmega2560 Atmel AVR. Este proyecto contiene muchas funciones basadas en hardware (7 dispositivos SPI, 2 I2C, 2 puertos RS485 MODBUS, muchas E/S analógicas y digitales). He desarrollado "controladores" 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 se tienen que cumplir las normas SIL.

Me gustaría poder probar el código y proporcionar un buen nivel de cobertura de código. Sin embargo, no puedo encontrar ninguna información para ayudarme a establecer cómo se debe configurar ese marco de prueba.

La idea es que puedo tener un conjunto de pruebas automatizadas que permitan probar futuras correcciones de errores y adiciones de funciones para ver si rompen el código. El problema es que no entiendo cómo se puede probar el código en un chip.

¿Necesito hardware para controlar las E/S en el dispositivo y emular los dispositivos conectados externamente? Cualquier puntero que se pueda proporcionar sería muy apreciado.

--Steve

Answer 1

Esta es una muy buena pregunta, una preocupación común para los desarrolladores integrados. Desafortunadamente, la mayoría de los desarrolladores integrados no están tan preocupados como usted y solo prueban el código en hardware real. Pero como señaló otra respuesta, esto básicamente puede probar solo la funcionalidad nominal del código y no los casos de esquina/error.

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

Primero, separa el código en capas. Una capa debe ser "independiente del hardware", es decir, llamadas a la función. No le pidas al usuario que escriba directamente en los registros HW. La otra capa (inferior) trata con el HW. Esta capa puede ser "burlada" para probar el nivel más alto. El nivel inferior no se puede probar realmente sin HW, pero no va a cambiar a menudo y necesita una profunda integración HW, por lo que no es un problema.

Un "arnés de prueba" será todo su código agnóstico HW de alto nivel con un nivel inferior "falso" específicamente para la prueba.Esto puede simular los dispositivos HW para la funcionalidad correcta e incorrecta y así le permite ejecutar pruebas automatizadas en la PC.

Answer 2

nunca debe realizar pruebas unitarias sobre o contra el hardware real. Siempre burla tus interfaces de E/S. De lo contrario, no puede simular condiciones de error y, lo que es más importante, no puede confiar en que la prueba tenga éxito.

Así que lo que necesita es dividir su aplicación en varias piezas que puede probar de forma independiente. Simula (o simula) todo el hardware que necesites para esas pruebas y ejecútalas en tu PC de desarrollo.

Eso debería cubrir la mayor parte de su código y lo deja con los controladores. Intente hacer la mayor cantidad posible de código de controlador sin el hardware. Por lo demás, tendrás que encontrar la forma de hacer que el código se ejecute en el hardware. Esto generalmente significa que debe crear un banco de pruebas con dispositivos externos que respondan a señales, etc. Como esto es frágil (como en "sus pruebas no pueden hacer que esto funcione automáticamente"), debe ejecutar estas pruebas manualmente 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? Puede utilizar JTAG para simular condiciones de error en el chip.

Answer 5

me gusta separar las tareas. Por ejemplo, cuando hice un buffer circular para mi Atmel AVR lo escribí todo en Code :: Blocks y lo compilé con el compilador GCC normal en lugar del compilador AVR GCC, luego creé una prueba unitaria para él. Usé un archivo de encabezado especial para proporcionar los tipos de datos adecuados con los que quería trabajar (uint8_t por ejemplo). Encontré errores con las pruebas de la unidad, los solucioné, luego tomé el código fijo en AVR Studio y lo integé. Después de eso utilicé funciones de soporte e ISR para ajustar el búfer en un código útil (es decir, separar un byte del búfer, insertarlo en el registro de salida de datos UART, agregar una constante de cadena al búfer para una función printf, etc.). Luego utilicé el simulador AVR para asegurarme de que mis ISR y funciones estaban siendo llamados y que los datos correctos aparecían en los registros. Después de eso, lo programé en el chip y funcionó perfectamente.

que prefieren en gran medida las capacidades de depuración de Code :: Blocks en comparación con AVR Studio, así que utilizan el enfoque anterior siempre que puedo. Cuando no puedo, generalmente trato solo con el hardware. Por ejemplo, tengo un temporizador que produce automáticamente una onda cuadrada. Lo mejor que pude hacer fue ver que la broca estaba siendo girada en el simulador. Después de eso solo tuve que enganchar un telescopio y asegurarme.

me gusta utilizar un enfoque de múltiples niveles para depurar problemas. Por ejemplo, con el reloj, la primera capa es "Ponga una sonda en el pin del reloj y vea si hay una señal allí". De lo contrario, pruebe el pin en el uC y busque la señal. Luego, codifiqué una interfaz de depuración en uno de mis UART donde puedo ver los valores de registro específicos y asegurarme de que son lo que se supone que son. Entonces, si no funciona, el siguiente paso es 'recuperar el valor de registro y asegurarse de que sea correcto'.

tratar de pensar por delante cuatro pasos más o menos cada vez que usted está planeando su depuración. Debería haber + 5V aquí, pero ¿y si no? Escriba en la interfaz de depuración una forma de alternar el pin y ver si eso lo cambia. ¿Qué pasa si eso no funciona? Haz otra cosa, etc, etc. Llegas al punto en el que te encuentras con 'NO TENGO IDEA, ¡POR QUÉ ESTE PELIGRO NO FUNCIONA!' pero con suerte sabrá la razón de antemano.