Ciclo de vida de las pruebas de software para aplicaciones integradas

Question

No tengo JTAG y no me lo puedo permitir para mi chip ARM Cortex M3.

Me pregunto cómo depuran los profesionales sus aplicaciones.

1. ¿Flashea su uC cada vez, con frecuencia, luego ejecuta y prueba, luego cambia? ¿es una mala práctica?
2. ¿Sólo utiliza UART o LCD para escribir los registros en la pantalla?

Necesito consejos y trucos de los profesionales :)

Answer 1

Esto es más bien una entrada del blog, pero ahí va:

Si escribes en C, puedes compilar tu código y ejecutarlo en tu 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 no son deseables, así que podrías compilar la versión de escritorio con Clang/LLVM en su lugar (con el beneficio de mejores mensajes de error).
3. Mi escritorio es un PC con Linux. Nada de este enfoque es específico de Linux. Pero Linux es un buen entorno de desarrollo en C.
4. Utilice 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 cuidado con la promoción integral de C's. Si es posible (está en ARM) utiliza un PC de 32 bits para probar el código ARM de 32 bits.
6. En cuanto a los controladores de hardware, he encontrado dos enfoques beneficiosos.
   1. Haz un prototipo en vivo en el PC. El PC tiene un reloj en tiempo real y una conexión de red, así como una pantalla y entradas, por lo que todo eso está resuelto. (Mi PC tiene incluso un acelerómetro.) Puedes usar libSDL para animar una imagen de tu producto final y recibir las pulsaciones de las teclas. Para otras funciones de tu placa conecta placas de desarrollo, o finge. La ventaja de este enfoque es que puedes usarlo en el sistema en vivo y ahorrarte la molestia de hacer hardware si encuentras que no resuelve el problema que necesitas resolver.
   2. Haz un prototipo muerto que lea los eventos de entrada de un archivo y escriba los eventos de salida en un archivo. Ahora, para las pruebas, puedes grabar (o sintetizar) eventos que correspondan a escenarios específicos que quieras probar. Y entonces puedes verificar que las cosas correctas se escriben en la salida. La ventaja de esto es que deja una suite de pruebas automatizada completa que puedes ejecutar en tiempo de construcción para detectar regresiones.
7. Utiliza las opciones del compilador -Wall -Wextra -Werror y mantén tu código libre de advertencias. Pasarás algo de tiempo Parcheando las advertencias, pero hace que la codificación sea más rápida al reducir el tiempo de depuración.
8. Compilar la versión para PC con guardabarros . Esto atrapa muchas travesuras de los punteros. Algunas personas recomiendan Valgrind, pero no es tan útil para el código que nunca utiliza malloc() o free() .
9. Para la depuración en el PC, utilice GDB o DDD o printf() al gusto. Existe una gran variedad de herramientas de depuración de escritorio maduras y útiles.
10. Incluso si no hago la configuración completa de depuración en el PC, a menudo incluiré una prueba de unidad main() al final de un archivo que es #define se ha ido. Este main() intenta cualquier función complicada en el archivo y devuelve 0 para todos los pases o asserts() para fallar. Luego añado un objetivo "test" en el makefile que compila y ejecuta cada una de las pruebas de los archivos individuales.
11. Hay muchas plataformas de pruebas unitarias que puedes utilizar. Hay muchas porque son muy fáciles de escribir. Yo no las uso. No quiero un bonito informe de "porcentaje de pruebas superadas". Quiero que mi prueba muera al primer fallo. Visual Basic solía tener una característica irrisoria llamada ' en caso de error, reanudar el siguiente '. No sé por qué querrías esa función para las pruebas unitarias.

Si haces pruebas unitarias independientes de esta manera, encontrarás que tienes muy poca necesidad de depuración en el chip. Además, encontrarás que la portabilidad a diferentes plataformas de hardware es mucho más fácil porque la lógica del núcleo y los controladores de hardware están bien separados.

Answer 2

1. Al trabajar con sistemas embebidos sin sistema operativo o consola remota, es bastante común hacer muchos flashes para probar los cambios. Cuando se tiene un sistema basado en Linux, se puede potencialmente cambiar algún código de script de python sobre la marcha.

2. Personalmente encuentro muy valiosa una consola UART para la salida de depuración y la ejecución de comandos de depuración. Es una buena manera de rastrear el flujo del programa y activar ciertas funcionalidades.
   Suelo utilizar diferentes niveles de depuración, para poder cambiar entre mostrar sólo los errores o habilitar el registro verboso para seguir todo en detalle, por ejemplo.

En cuanto a JTAG / en la depuración del sistema: Aunque disponga de JTAG, sólo lo utilizo para rastrear problemas de algoritmos (siguiendo el cálculo) o para comprobar los valores de registro / configuración del hardware. Rara vez lo utilizo para seguir el flujo del programa, lo encuentro más fácil y rápido utilizando la salida de la consola de depuración.

Answer 3

Puedes arreglártelas casi sin IO para depurar, pero la dificultad es inversamente proporcional a la IO disponible - observar un pin de IO con un scope te llevará mucho más tiempo para depurar algo que un depurador JTAG o similar que pueda detener la CPU y examinar todo, pasar por encima, rastrear, etc.

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

Answer 4

Mi 5c. Algunas cosas se hacen más rápidamente con depuradores JTAG: Mirar varias variables a la vez, recorrer el código, añadir breakpoints. Mirar las ubicaciones de memoria más grandes. Detectar errores estúpidos: Esa interrupción que olvidaste desactivar.

Answer 5

Para los sistemas que tenían que ejecutarse a toda velocidad (por ejemplo, controlando algo que no podía ser suspendido en un breakpoint y no debía permitirse que se ejecutara sin control), y no podía tolerar o alcanzar la tasa de datos en serie requerida mientras se ejecutaba, he metido muestras en bruto en una matriz para ser volcado al final de la ejecución e interpretado fuera de línea. Esto añade un tiempo de ejecución mínimo a expensas del espacio de memoria.