Configuración de un Proyecto de Hardware en el Bucle

En Pruebas de Hardware en el Bucle: Una Introducción, revisamos qué es la prueba de hardware en el bucle (HIL), cómo sería una configuración y por qué querríamos integrar esto en el diseño de nuestro proyecto. Este artículo recorrerá un proyecto de ejemplo de una placa diseñada en Altium Designer y ejecutada a través de un flujo de DevOps utilizando pruebas de hardware en el bucle contra su firmware.

Diseño

Antes de configurar cualquier configuración de hardware en el bucle, necesitamos una placa en la que trabajar. Una buena manera de comenzar con un diseño antes de la captura esquemática y el diseño es prototipar con placas de evaluación. La placa de evaluación que utilizaremos para este artículo será la SAM4E XPlained Pro de Microchip (anteriormente Atmel). Para comenzar, necesitarás esta placa de evaluación y también tener instalado Atmel Studio. Una vez que tengas tu hardware y software funcionando, puedes clonar el proyecto de ejemplo de Gitlab. Este proyecto de ejemplo contiene una cantidad mínima de código, solo lo suficiente para demostrar las capacidades de hardware en las pruebas de bucle. Este proyecto también aprovecha algunas bibliotecas del Marco de Software de Atmel (ahora renombrado como “Marco de Software Avanzado”). El ASF proporciona controladores que permiten la comunicación USB en serie, rutinas de retraso y otras bibliotecas que abstraen muchas implementaciones de hardware de bajo nivel que normalmente se escriben para otros microprocesadores. Una vez que hayas extraído el repositorio, compilado y cargado el firmware, estás listo para configurar y ejecutar pruebas de hardware en el bucle.

Configuración

Para el control de versiones y la integración/despliegue continuo (CI/CD), se ha elegido Gitlab como host. Como se demostró en Cómo Crear una Pipeline CI/CD para Tu Diseño de PCB, el control de versiones y CI/CD se integran como una sola herramienta en Gitlab. Este proyecto consta de múltiples etapas de CI/CD (también conocidas como “Pipelines” en Gitlab):

La primera etapa crea los binarios necesarios para cargar los archivos de programación en el microprocesador. Después de esto, se enciende el dispositivo downstream (es decir, la placa de evaluación). Luego, el dispositivo se programa y la unidad está lista para ser probada.

Prueba

Las pruebas de hardware en el bucle pueden ser tan simples o tan complejas como tú decidas. Mientras que muchos sistemas HIL complejos requieren dispositivos externos para emular entornos del mundo real, este ejemplo utiliza un mecanismo básico para emular un estímulo externo: la comunicación serial. La interfaz USB Device CDC de Atmel crea un puerto COM virtual para habilitar la comunicación a través de USB, tal como lo harías con UART a través de RS-232. En esta suite de pruebas nosotros:

1. Configurar un registro enviando un comando
2. Leer el registro (para validar nuestro comando)
3. Limpiar el registro
4. Leer el registro una vez más

Mientras que el firmware para el microprocesador está escrito en C, el software de prueba (que impulsa los comandos y lee la telemetría) está escrito en Python utilizando el framework Pytest. Escribir el software en Python nos permite aprovechar la creación de scripts de alto nivel y bibliotecas que normalmente requerirían mucho más tiempo y esfuerzo para desarrollarse en un lenguaje compilado como C++. Además, podemos ejecutar estas pruebas en cualquier tipo de máquina, independientemente de su sistema operativo o incluso arquitectura de chip. Las mismas pruebas que se ejecutan en un PC con Windows (Windows, x86) también pueden ejecutarse en una Raspberry Pi (Linux, ARM). Abstraer el desarrollo, la compilación y la prueba desde tu máquina es un principio clave en el flujo de trabajo de DevOps. Queremos poder reproducir un nuevo entorno al instante. Además, queremos evitar las horas agotadoras que lleva crear un entorno de desarrollo leyendo páginas y páginas de guías de “Cómo hacer” o “Introducción”. Scripting este proceso (incluidas las pruebas), como se ha hecho en el archivo de definición de pipeline, asegura un entorno reproducible sin complicaciones. Para ejecutar las mismas pruebas manualmente desde la línea de comandos, consulta el archivo del pipeline.

Después de que la prueba se complete, los resultados se escriben en un archivo XML de JUnit, que luego es analizado por Gitlab y mostrado en la interfaz web.

Ahora hemos demostrado una solución completa de extremo a extremo de configuración de hardware en el bucle con Gitlab. Siéntete libre de explorar el proyecto para familiarizarte más con la configuración y el formato.

Conclusión

En este artículo, revisamos cómo configurar tu proyecto para pruebas de hardware en el bucle. Esto incluyó un proyecto de ejemplo alojado en Gitlab que los usuarios pueden clonar y configurar utilizando el archivo de configuración del pipeline (es decir, el archivo .gitlab-ci.yml). También cubrimos la ejecución de las pruebas en Python utilizando el framework Pytest y discutimos cómo se muestra en la interfaz web. Ahora el usuario tiene la capacidad de crear su propia configuración de hardware en el bucle utilizando esta guía y el proyecto de ejemplo alojado en Gitlab.

¿Te gustaría saber más sobre cómo Altium puede ayudarte con tu próximo diseño de PCB? Habla con un experto en Altium y aprende más sobre cómo tomar decisiones de diseño con facilidad y confianza.