Aplicaciones integradas Software Ciclo de vida de prueba

Esto es más una publicación de blog, pero aquí va:

Si escribe en C, puede compilar su código y ejecutarlo en su escritorio. Esto no probará los controladores de hardware de bajo nivel, pero puede probar todo el código lógico.

Recomendaciones sobre este enfoque:

1. Si estás en ARM, puedes usar el mismo compilador (gcc) para ambos propósitos. Entonces, cualquier extensión específica del compilador seguirá funcionando.
2. Pero las extensiones específicas del compilador son indeseables, por lo que puede compilar la versión de escritorio con Clang / LLVM (con el beneficio de mejores mensajes de error).
3. Mi escritorio es una PC con Linux. Nada en este enfoque es específico de Linux. Pero Linux seguro hace un buen entorno de desarrollo en C.
4. Use stdint.h y tipos como uint64_t , en lugar de " unsigned long int ". Esto le permite obtener el mismo comportamiento cuando se compila en diferentes sistemas.
5. Pero ten cuidado con la promoción de enteros de C. Si es posible (está en ARM) use una PC de 32 bits para probar el código ARM de 32 bits.
6. Con respecto a los controladores de hardware, he encontrado dos enfoques que son beneficiosos.
   1. Haz un prototipo en vivo en la PC. La PC tiene un reloj en tiempo real y una conexión de red y una pantalla y entradas, por lo que se cuidan. (Mi PC incluso tiene un acelerómetro). Puede usar libSDL para animar una imagen de su producto final y recibir pulsaciones de teclas. Para otras funciones de su placa, conecte las placas de desarrollo o falsifíquelas. La ventaja de este enfoque es que puede usarlo en el sistema en vivo y ahorrarse la molestia de hacer hardware si encuentra que no resuelve el problema que necesita resolver.
   2. Cree un prototipo muerto que lea los eventos de entrada de un archivo y escriba los eventos de salida en un archivo. Ahora, para la prueba, puede registrar (o sintetizar) los eventos que corresponden a los escenarios específicos que desea probar. Y luego puedes verificar que las cosas correctas están escritas en la salida. La ventaja de esto es que deja un conjunto de pruebas totalmente automatizado que puede ejecutar en el momento de la creación para capturar regresiones.
7. Use las opciones del compilador -Wall -Wextra -Werror y mantenga su código libre de advertencias. Pasará algún tiempo parchando advertencias, pero hace que la codificación sea más rápida al reducir el tiempo de depuración.
8. Compile la versión para PC usando mudflaps . Esto atrapa un montón de travesuras puntero. Algunas personas recomiendan Valgrind, pero no es tan útil para el código que nunca usa malloc() o free() .
9. Para la depuración de PC, use GDB o DDD o printf() , para probar. Hay una gran variedad de herramientas de depuración de escritorio maduras y útiles disponibles.
10. Incluso si no hago la configuración completa de depuración de PC, a menudo incluiré una función de prueba de unidad co2de% al final de un archivo que está main() 'd out. Este #define intenta cualquier función complicada en el archivo y devuelve 0 para all-pass o main() para fallar. Luego agrego un objetivo de "prueba" en el makefile que compila y ejecuta cada una de las pruebas de los archivos individuales.
11. Hay muchas plataformas de prueba de unidades que puedes usar. Hay tantos porque son muy fáciles de escribir. Yo no los uso. No quiero un informe bonito de "pruebas de porcentaje aprobadas". Quiero que mi prueba muera en el primer fracaso. Visual Basic solía tener una función risible llamada ' en el resumen de error siguiente '. No sé por qué querría esa característica para las pruebas unitarias.

Si realiza la prueba de unidad independiente de esta manera, encontrará que tiene muy poca necesidad de depuración en el chip. Además, encontrará que portar a diferentes plataformas de hardware es mucho más fácil porque la lógica central y los controladores de hardware están bien separados.

1. Trabajar con sistemas embebidos sin SO o consola remota, es bastante común hacer muchos flashes para probar cambios. Cuando tiene un sistema basado en Linux, puede simplemente cambiar un código de script de Python sobre la marcha.

2. Personalmente encuentro una consola UART para la salida de depuración y la ejecución de los comandos de depuración de un valor incalculable. Es una buena manera de rastrear el flujo del programa y desencadenar cierta funcionalidad.
   Tiendo a usar diferentes niveles de depuración, por lo que puedo cambiar entre mostrar solo errores o habilitar el registro detallado para seguir todo en detalle, por ejemplo.

Con respecto a JTAG / en la depuración del sistema: incluso si tengo JTAG disponible, solo lo uso para rastrear problemas de algoritmo (después del cálculo) o verificar los valores de configuración de registro / hardware. Raramente lo uso para seguir el flujo del programa, lo encuentro más fácil y rápido usando la salida de la consola de depuración.

Mi 5c. Algunas cosas se hacen más rápidamente con los depuradores JTAG: Observando las variables del servidor a la vez, repasando el código, agregando puntos de interrupción. Mirando ubicaciones de memoria más grandes. Atrapando errores estúpidos: esa interrupción que olvidaste inhabilitar.

Usted puede arreglárselas sin casi ningún IO para depurar, pero la dificultad es inversamente proporcional al IO disponible: ver un pin IO con un alcance tomará mucho más tiempo en depurar algo que un JTAG o un depurador similar que puede detener la CPU &erio; Examinar todo, paso a través, trazar, etc.

Para cosas básicas no necesitas mucha depuración, para cosas muy complejas, cuanto más mejor, realmente.

Para los sistemas que tenían que funcionar a toda velocidad (por ejemplo, controlar algo que no podía suspenderse en un punto de interrupción y no debería permitirse que se ejecutara sin control), y no podía tolerar ni alcanzar la velocidad de datos en serie requerida mientras se ejecutaba He rellenado muestras en bruto en una matriz para ser volcado al final de la ejecución e interpretado fuera de línea. Agrega un tiempo de ejecución mínimo a expensas del espacio de memoria.