Configurer un projet de matériel en boucle

Dans l'article "Hardware in the Loop Testing: An Introduction", nous avons passé en revue ce qu'est le test hardware in the loop (HIL), à quoi ressemblerait une configuration et pourquoi nous souhaiterions l'intégrer dans la conception de notre projet. Cet article présente un exemple de projet d'une carte conçue dans Altium Designer et passant par un flux DevOps utilisant les tests hardware in the loop contre son firmware.

Conception

Avant de configurer un test hardware in the loop, nous avons besoin d'une carte sur laquelle travailler. Une bonne manière de commencer une conception avant la capture schématique et la disposition est de créer un prototype avec des cartes d'évaluation. La carte d'évaluation que nous utiliserons dans cet article est la SAM4E XPlained Pro de Microchip (anciennement Atmel). Pour commencer, vous aurez besoin de cette carte d'évaluation, ainsi que d'installer Atmel Studio. Une fois que votre matériel et votre logiciel sont en place, vous pouvez cloner le projet exemple depuis Gitlab. Ce projet contient une quantité minimale de code - juste assez pour démontrer les capacités des tests hardware in the loop. Ce projet utilise également certaines bibliothèques issues du Atmel Software Framework (maintenant renommé "Advanced" Software Framework). L'ASF fournit des pilotes qui permettent la communication USB série, des routines de temporisation et d'autres bibliothèques qui abstraient de nombreuses implémentations matérielles bas niveau habituellement écrites pour d'autres microprocesseurs. Une fois le dépôt récupéré, compilé et le firmware chargé, vous êtes prêt à configurer et à exécuter les tests hardware in the loop.

Configuration

Pour le contrôle de version et l'intégration continue/déploiement continu (CI/CD), Gitlab a été choisi comme hôte. Comme le montre l'article Comment créer une pipeline CI/CD pour votre conception de PCB, le contrôle de version et le CI/CD sont intégrés en un seul outil dans Gitlab. Ce projet se compose de plusieurs étapes CI/CD (également appelées " pipelines" dans Gitlab):

La première étape crée les binaires nécessaires pour charger les fichiers de programmation sur le microprocesseur. Une fois cela terminé, le dispositif en aval (c'est-à-dire la carte d'évaluation) est mis sous tension. L'appareil est ensuite programmé et l'unité est maintenant prête à être testée.

Test

Les tests hardware in the loop peuvent être aussi simples ou complexes que vous le concevez. Bien que de nombreux systèmes HIL complexes nécessitent des dispositifs externes pour simuler des environnements réels, cet exemple utilise un mécanisme de base pour simuler un stimulus externe : la communication série. L'interface USB Device CDC d'Atmel crée un port COM virtuel pour permettre la communication via USB, tout comme vous le feriez avec UART via RS-232. Dans cette série de tests, nous :

1. Configurer un registre en envoyant une commande
2. Lire le registre (pour valider notre commande)
3. Effacer le registre
4. Lire à nouveau le registre

Bien que le firmware du microprocesseur soit écrit en C, le logiciel de test (qui gère les commandes et lit la télémétrie) est écrit en Python en utilisant le framework Pytest. Écrire le logiciel en Python nous permet de tirer parti des scripts de haut niveau et des bibliothèques qui nécessiteraient normalement beaucoup plus de temps et d'efforts pour être développés dans un langage compilé comme le C++. De plus, nous pouvons exécuter ces tests sur n'importe quel type de machine, indépendamment de son système d'exploitation ou même de son architecture de processeur. Les mêmes tests qui s'exécutent sur un PC sous Windows (Windows, x86) peuvent également s'exécuter sur un Raspberry Pi (Linux, ARM). L'abstraction du développement, de la compilation et du test de votre machine est un principe clé du flux de travail DevOps. Nous voulons pouvoir reproduire un nouvel environnement en un clin d'œil. De plus, nous voulons éviter les heures fastidieuses qu'il faut pour mettre en place un environnement de développement en lisant des pages et des pages de guides « Comment faire » ou « Pour bien commencer ». Scriptant ce processus (y compris les tests), comme cela a été fait dans le fichier de définition du pipeline, nous assurons un environnement reproductible sans tracas. Pour exécuter les mêmes tests manuellement depuis la ligne de commande, consultez le fichier du pipeline.

Après la fin du test, les résultats sont écrits dans un fichier XML JUnit, qui est ensuite analysé par Gitlab et affiché dans l'interface web.

Nous avons maintenant démontré une solution complète de bout en bout de configuration hardware in the loop avec Gitlab. N'hésitez pas à explorer le projet pour vous familiariser davantage avec la configuration et le format.

Conclusion

Dans cet article, nous avons vu comment configurer votre projet pour les tests hardware in the loop. Cela incluait un projet exemple hébergé sur Gitlab que les utilisateurs peuvent cloner et configurer en utilisant le fichier de configuration du pipeline (c'est-à-dire, le fichier .gitlab-ci.yml). Nous avons également abordé l'exécution des tests en Python en utilisant le framework Pytest et discuté de la manière dont les résultats sont affichés dans l'interface web. L'utilisateur a désormais la possibilité de créer son propre environnement de test hardware in the loop en utilisant ce guide et le projet exemple hébergé sur Gitlab.

Souhaitez-vous en savoir plus sur la manière dont Altium peut vous aider avec votre prochaine conception de PCB ? Parlez à un expert chez Altium et apprenez-en plus sur la façon de prendre des décisions de conception avec aisance et confiance.