Coder votre propre équipement de test en réseau

Introduction

Si vous avez déjà passé du temps à tester manuellement des lots de composants, vous savez à quel point le processus peut être laborieux et chronophage. Chaque test suit les mêmes étapes de base répétées pour chaque article que vous testez. Vous comprendrez également la puissance de l'utilisation d'équipements de test que vous pouvez programmer pour effectuer ces étapes pour vous, il suffit donc de tout configurer et de tout brancher pour pouvoir appuyer sur un bouton pour effectuer un test. Vous pouvez gagner encore plus de temps en automatisant la configuration de tous vos équipements de test en un clic de souris d'ordinateur.

Cependant, que faire si vous souhaitez créer des équipements de test sur mesure pour ajouter à votre suite de tests automatisés ? Ce guide étape par étape vous montrera comment écrire du code qui vous permet de configurer vos équipements de test en réseau depuis le confort de votre ordinateur.

L'automatisation en réseau élimine le besoin de configurer chaque pièce d'équipement de test séparément et permet de gagner du temps si vous devez répéter les mêmes tests à l'avenir. Le bonus est que la restauration des paramètres après une coupure de courant ou une mise hors tension accidentelle de l'équipement est rapide et simple.

Introduction à SCPI

Si vous n'êtes pas familier avec le réseau d'équipements de test, vous devez connaître les Commandes Standard pour Instruments Programmables (SCPI). À l'époque, Hewlett-Packard a proposé le concept d'un bus d'interface standard qui permettrait à tout ordinateur avec l'interface correcte de se connecter à n'importe quel équipement de test. Cette norme HPIB est devenue connue sous le nom de General Purpose Interface Bus (GPIB) avec sa propre désignation de norme IEEE 488. Cette standardisation a permis à chaque pièce d'équipement de test en réseau de répondre aux commandes de l'ordinateur pour effectuer des fonctions telles que produire un signal ou effectuer une mesure.

SCPI a étendu le principe de mise en réseau standardisée des équipements de test en ajoutant une couche supplémentaire pour la norme IEEE-488 afin de réguler les commandes informatiques que l'équipement de test pourrait comprendre. Cette approche signifie maintenant qu'un oscilloscope fabriqué par HP répondra aux mêmes commandes qu'un oscilloscope fabriqué par Keysight. Avant la standardisation des commandes, souvent différents modèles produits par le même fabricant réagiraient à différentes commandes. Cette standardisation signifie que le programme de contrôle de l'équipement de test sur un ordinateur fonctionnera avec toutes les marques et tous les modèles d'équipements de laboratoire, donc changer une alimentation de banc en réseau, par exemple, pour un modèle meilleur ne nécessitera pas de changements dans le programme de contrôle.

Cette standardisation signifie également que tout code écrit pour ce guide étape par étape fonctionnera dans n'importe quel autre laboratoire si vous avez les mêmes types d'équipements de test en réseau liés à un ordinateur approprié.

Introduction à SCPI

Les commandes SCPI sont sous forme de chaînes ASCII simples qui sont assez intuitives à lire et à comprendre. Par exemple, envoyer la commande “*RST” à un appareil de test le réinitialisera ; envoyer la commande “*WAI” lui donnera l'instruction d'attendre.

Les commandes SCPI peuvent instruire l'équipement de test à effectuer une action ou demander des informations selon leur format. Par exemple, la commande “TIM:ACQT 20ms” changera le temps d'acquisition d'un oscilloscope à 20ms, tandis que la commande “TIM:ACQT?” lui fera retourner son temps d'acquisition actuel.

Il est important de considérer que les commandes ne sont pas sensibles à la casse et supportent des formes abrégées, donc, par exemple, “TRIG SOUR CH1” et “Trigger source Channel1” sont deux alternatives valides de la même commande. Vous pouvez également concaténer les commandes, donc par exemple, “TRIG SOUR CH1”, “TRIG LEVEL1 10” et “TRIG POL INV” peuvent être écrits comme “TRIG:SOUR CH1;LEVEL1 10;POL INV” puisque toutes les commandes s'appliquent au même TRIG. Ces commandes définissent le canal source, son niveau en volts, et la polarité. Cet exemple définit le niveau du canal 1 à 10V avec une polarité inversée. Vous n'avez pas à spécifier son déclencheur 1 car cela est supposé, mais vous pourriez utiliser “TRIG1:” pour éviter toute ambiguïté.

Le Projet de Codage

La vidéo accompagnant cet article montre comment créer votre propre équipement de test en réseau qui utilise des commandes SCPI. Cela s'appuie sur une vidéo précédente montrant comment communiquer avec l'équipement de test pour l'automatisation.

Cet exercice vise à permettre à du matériel de test personnalisé de s'intégrer parfaitement dans tout logiciel de test existant capable de gérer des commandes SCPI, tel que ceux utilisant les LAN eXtensions for Instrumentation (LXI) ou l'Architecture Logicielle d'Instrument Virtuel (VISA). L'objectif ultime est de développer un dispositif de test intégré complet en incorporant un microcontrôleur dans le matériel de test automatisé.

La carte de développement Infineon XMC4700 Relax Kit, conçue pour les applications industrielles, est au cœur du projet. La carte inclut un microcontrôleur avec mémoire statique et dynamique, horloges, alimentations, interfaces standards, et contrôles de base. Elle inclut également une connexion ethernet embarquée avec une adresse de contrôle d'accès aux médias (MAC) pour le réseau.

Un avantage clé de cette configuration est la disponibilité de l'environnement de développement intégré Digital Application Virtual Engineer (DAVE) qu'Infineon fournit. DAVE est un outil de développement logiciel et de génération de code basé sur C pour les applications microcontrôleur. Il permet de simplifier le processus de codage, en gérant commodément la plupart des tâches de configuration pour que vous puissiez vous concentrer sur l'implémentation des commandes SCPI.

Le code de test que nous allons créer lira la position d'un bouton et contrôlera l'état d'une LED. Ce test simpliste offrira un exemple facile à comprendre et fournira un excellent point de départ pour explorer davantage la puissance et les avantages des tests automatisés.

Guide de codage étape par étape

Configuration du projet :

Lors de l'utilisation de l'outil DAVE pour un nouveau projet, la première étape consiste à créer un nouveau fichier de projet en utilisant la séquence de commandes "Fichier -> Nouveau -> Projet DAVE". Cette action ouvrira une nouvelle fenêtre où vous pourrez sélectionner l'option "Projet DAVE CE" et lui donner un nom approprié.

Vous devrez ensuite choisir votre matériel cible ; dans ce cas, le kit XMC4700 Relax.

À moins que votre projet ne soit contraint par les ressources, il est toujours de bonne pratique d'utiliser la bibliothèque standard newlib complète plutôt que l'option de taille nano.

L'étape suivante consiste à configurer les périphériques pour le projet en utilisant la commande "DAVE -> Ajouter une nouvelle APP".

La première configuration à mettre en place est la connexion réseau, et vous faites cela avec la commande "Ethernet -> ETH_LWIP", qui ajoute une pile de protocole internet (IP) légère au projet pour gérer cette interface.

Vous devez également ajouter les interfaces d'entrée/sortie (IO) pour l'équipement de test, le bouton et l'indicateur LED dans cet exemple. Les deux sont des composants discrets, vous devez donc ajouter deux applications "DIGITAL_IO" sous l'option de commande Système, une pour chaque élément.

Il est de bonne pratique de renommer les applications IO pour identifier leurs fonctions dans leurs noms afin de faciliter la vie et d'éviter d'accéder accidentellement à la mauvaise application. Cette erreur peut être difficile à détecter lorsqu'on essaie de déboguer un programme de test qui se comporte de manière inattendue.

Vous devez également configurer la pile IP pour la connexion Ethernet en cliquant avec le bouton droit sur l'"ETH_LWIP App" et en cliquant sur "Configurer l'instance de l'application". Vous constaterez que le XMC4700 Relax Kit est déjà préconfiguré, ce qui permet de gagner du temps. Vous devrez changer l'adresse IP statique sur la page des paramètres IP pour qu'elle corresponde au sous-réseau de l'ordinateur que vous utilisez pour vos tests automatisés. De plus, le protocole de datagramme utilisateur (UDP) n'est pas requis dans cet exemple, vous pouvez donc le désactiver dans l'onglet des paramètres du protocole.

Enfin, vous devez fournir la correspondance entre les paramètres des broches de l'APP et le matériel du microcontrôleur en utilisant l'option d'allocation manuelle des broches pour chaque composant. Pour configurer le bouton discret, vous cliquez avec le bouton droit sur le bouton et sélectionnez la commande "Allocateur manuel de broches".

Vous pouvez ensuite choisir le numéro de broche approprié pour le bouton sur le Relax Kit dans le menu déroulant, qui fournit commodément des étiquettes pour rendre cela simple. La configuration de la LED et de la connexion Ethernet suit le même processus. Vous constaterez que la fonction d'allocation de broches simplifie ce processus en vous permettant de sélectionner uniquement les broches avec la fonctionnalité nécessaire. L'outil fournit automatiquement toutes les étiquettes du XMC4700 Relax Kit pour rendre cela simple.

Ces étapes complètent la configuration de votre projet de test automatisé, et vous êtes maintenant prêt à écrire le code de test.

Codage de l'application du projet

Vous pouvez générer le code pour les applications en cliquant simplement sur le bouton « Générer le code » dans la barre d'outils DAVE, puis attendre que l'opération se termine.

Avant de coder sérieusement, une étape recommandée est de transférer la console du microcontrôleur vers l'ordinateur, offrant un accès facile à `printf`. Cela vous permettra de formater et d'imprimer des données pour rendre l'écriture et le débogage du code plus rapides et plus faciles. Vous pouvez le faire en activant le « GDB Semi-Hosting » dans les paramètres de configuration. Vous pouvez le faire en naviguant vers les « Propriétés du projet », en procédant à « C/C++ Build », puis en sélectionnant « Paramètres ».

Sous « ARM-GCC, Éditeur de liens C, Divers », vous devrez ajouter « –specs=rdimon.specs » aux drapeaux « Autres ». Cette étape intègre la configuration de semi-hébergement pour l'éditeur de liens.

Vous pouvez ensuite aller à la section « ARM-GCC C Compiler, Préprocesseur » et ajouter un symbole nouvellement défini de « XMC_DEBUG_ENABLE ». Ce paramètre assure la redirection de la console dans la configuration de build de débogage.

Vous devrez dans les paramètres du projet décocher la case qui fournit les « appels système newlib par défaut » sous les paramètres « ARM-GCC C Linker, Général ». Si vous laissez cette option cochée, vous constaterez qu'elle interrompt l'initialisation du gestionnaire de moniteur et provoque l'échec de la construction.

Ensuite, vous devez initialiser la surveillance, ce que vous pouvez faire en ajoutant « extern void initialise_monitor_handles(void); » au début de votre code. Cette fonction doit être appelée après l'appel à DAVE_Init();.

Notez que l'orthographe de « initialise » est la variante en anglais britannique puisque la base ARM est à Cambridge, Angleterre. Utiliser l'orthographe américaine entraînera une erreur qui peut être difficile à résoudre si vous ne remarquez pas la subtile différence d'orthographe. 

Codage Réseau du Projet

La première étape pour faire fonctionner le réseau Ethernet est d'activer la pile IP légère pour vérifier régulièrement les nouveaux messages. Vous pouvez le faire en ajoutant un appel à la fonction « sys_check_timeouts(); » dans votre boucle while infinie qui s'exécute après que l'initialisation soit complète.

Cette fonction aura besoin d'être déboguée pour pouvoir s'exécuter sur le microcontrôleur. Vous pouvez faire cela en créant une nouvelle configuration de débogage. Il est recommandé de désactiver l’option « Mettre un point d'arrêt à : main » pour permettre au code de s'exécuter dès que le microcontrôleur démarre. Sélectionner l'option de débogage chargera votre nouveau code dans le microcontrôleur.

Vous pouvez confirmer que le code fonctionne en ouvrant une console Windows sur votre ordinateur et en envoyant un ping à l'adresse IP de la carte de développement, qui dans cet exemple, est le kit XMC4700 Relax. La carte de développement devrait répondre à chaque ping, confirmant que la carte fonctionne et que la connexion réseau est opérationnelle.

Le code de la pile Lightweight IP gérera automatiquement les fonctions du protocole de messages de contrôle Internet (ICMP). Cependant, vous devez créer du code pour gérer les connexions entrantes et les données du protocole de contrôle de transmission (TCP). Vous pouvez faire cela en utilisant des instructions standard de la pile Lightweight IP qui ne sont pas spécifiques au microcontrôleur.

Maintenant que vous avez terminé la configuration de la connexion réseau, vous pouvez configurer le bloc de contrôle du protocole pour écouter sur le port 5025, que le code SCPI utilise pour les communications. Vous devriez configurer la pile Lightweight IP pour déléguer toutes les nouvelles connexions à une fonction appelée client_accept que vous devrez étendre pour gérer les nouveaux clients. Toutes les données reçues devront être redirigées vers une fonction de traitement séparée qui émettra également un message de débogage pour indiquer la réception d'une nouvelle connexion.

La mise en œuvre d'une méthode client_recv copiera les données reçues dans un tampon pour traitement. Cette fonction devrait également vérifier les connexions sans données, ce qui indique que l'hôte distant a fermé la connexion. Dans ce cas, le code peut effectuer des actions de nettoyage pour supprimer tout artefact indésirable laissé par la connexion fermée.

Compiler le code générera une construction fonctionnelle s'il n'y a pas d'erreurs de codage à déboguer.

Codage IO du projet

L'étape suivante est la configuration des « Applications IO numériques » pour effectuer leurs opérations requises.

Cliquez avec le bouton droit sur chaque application et sélectionnez l'option « Configurer l'instance de l'application ». Le réglage par défaut pour les composants IO est une entrée tristate, parfaite pour le bouton. Cependant, pour la LED, vous devrez changer les paramètres en « Entrée/Sortie » avec une forte capacité de conduite et une transition douce. Cette configuration de forte capacité de conduite assure que la carte produira suffisamment de courant de conduite pour illuminer la LED. La configuration de transition douce se réfère à la vitesse de transition des bords du pin. Un bord doux atténue tout effet transitoire sur le réseau de distribution d'énergie et réduit le risque d'un impact négatif sur la conformité électromagnétique. Utiliser cette option pour une sortie discrète est une bonne pratique, à moins que vous n'ayez besoin d'un signal avec des taux de transition en nanosecondes.

Régénérer le code mis à jour ajoutera ces nouveaux changements à la construction fonctionnelle. Il est important de se souvenir de toujours régénérer le code après avoir effectué des modifications sur une application DAVE.

Codage SCPI du projet

Avec les fonctions de configuration et d'initialisation complètes, le codage du projet peut enfin passer à la mise en œuvre des commandes SCPI pour les tests. Il n'est pas nécessaire d'implémenter les commandes SCPI à partir de zéro ; une exceptionnelle bibliothèque SCPI-Parser de Jan Breuer est disponible sur GitHub comme point de départ.

Vous pouvez tirer parti de cette ressource en extrayant le dossier libscpi dans le dossier Libraries de votre projet. Ensuite, extrayez les dossiers scpi-def de « exemples -> commun » dans votre dossier de projet. Cette étape importe la bibliothèque SCPI-Parser et fournit un bon point de départ pour implémenter votre projet.

Vous devrez supprimer le dossier test et le makefile dans la bibliothèque libscpi au sein de l'environnement de développement intégré de DAVE, car ils seront incompatibles avec la bibliothèque ARM-GCC utilisée.

Ensuite, revenez à la fenêtre des propriétés du projet sous « Build, Settings, Compiler, Directories » et ajoutez une référence au dossier includes de libscpi.

Vous devrez également ouvrir le fichier scpi-def.c et ajouter une instruction include pour « dave.h » afin de lier vos fonctions IO au fichier scpi-def.

En passant, ce fichier comprend une fantastique démonstration de mise en œuvre d'un multimètre numérique et des fonctions pour les tests automatisés. Malheureusement, ces fonctions sont incompatibles avec le compilateur ARM utilisé pour cet exemple, et doivent donc être supprimées. Cependant, si vous avez besoin d'implémenter vos propres fonctions à l'avenir, vous pouvez vous référer aux fichiers originaux pour référence.

Lors de l'édition du fichier, supprimez toutes les fonctions DMM et de test dans le bloc de configuration des commandes mais conservez le code pour la commande TST et toutes les déclarations suivantes, ainsi que les commandes SCPI standard que la bibliothèque gérera.

Vous pouvez définir les informations d'identification pour la configuration du test dans le fichier “scpi-def.h”, ainsi l'utilisation de la commande SCPI *IDN retournera des informations utiles en réponse à toute demande d'identification.

Vous pouvez configurer les commandes SCPI dans le fichier “main.c” du projet. Vous devrez ajouter le contexte SCPI à la fonction principale en utilisant la propriété user_context pour passer une référence au bloc de contrôle du protocole Lightweight IP permettant l'initialisation de la bibliothèque SCPI. Ensuite, vous devez ajouter vos fonctions pour permettre à libscpi de communiquer via la connexion réseau. Dans cet exemple, les fonctions suivantes doivent être définies :

• La fonction “SCPI_Write” permet à libscpi d'envoyer des données via la connexion réseau.

• La fonction “SCPI_Flush” signale à la pile Lightweight IP d'envoyer immédiatement toutes les données dans le tampon.

• La fonction “SCPI_Error” fournit un moyen de gérer les erreurs SCPI. Pour cet exemple basique, vous pouvez contourner cela avec un simple appel à la fonction printf.

• La fonction “SCPI_Control” est une fonctionnalité optionnelle qui vous permet d'écrire sur le canal de contrôle sur le port TCP 5026, ce qui ne sera pas nécessaire pour cet exemple.

• La fonction “SCPI_Reset” est appelée en réponse à la réception d'une commande de réinitialisation, rétablissant tous les instruments de test à leurs paramètres par défaut. Il n'y a pas d'équipement de test connecté pour cet exemple basique, donc vous pouvez contourner cela avec un simple appel à la fonction printf.

Enfin, le user_context doit être défini pour la nouvelle connexion client lors de la connexion à la pile Lightweight IP. Cela permettra de transmettre les données à la bibliothèque SCPI depuis le tampon via la fonction client_recv à “SCPI_Input” pour être traitées. Vous devrez noter que cette mise en œuvre ne gérera pas plusieurs connexions simultanément mais représente une bonne pratique de configuration réseau.

Compiler le code mis à jour et le télécharger sur le microcontrôleur devrait aboutir à un système de test qui non seulement continue de répondre aux pings d'une console Windows mais devrait également répondre aux commandes SCPI.

Test du code SCPI du projet

Ce projet exemple a utilisé une application Rohde & Schwarz VISA Tester pour tester les commandes SCPI.

Après avoir connecté l'application à l'équipement de test, le premier test consiste à émettre une demande d'identité (IDN?). Il s'agit d'une première étape recommandée, et la commande est entièrement gérée par la bibliothèque SCPI, assurant que les communications sont opérationnelles et que vous avez correctement configuré la bibliothèque. Cela signifie que la résolution de tout problème impliquant des tests nécessitant une réponse d'un périphérique ou d'un équipement de test peut supposer que les communications et la bibliothèque ne sont pas en cause dans le processus de débogage.

Tester les périphériques nécessite d'ajouter de nouveaux motifs au tableau `scpi_commands` pour implémenter les fonctions requises. Des appels à la fonction “printf” peuvent être inclus pour déboguer la fonctionnalité, offrant une méthode simple de vérification de l'exécution du code.

Dans l'exemple, le code lit l'état du bouton en utilisant la fonction “scpi_result_t IO_Btn“ dans l'application DAVE précédemment configurée pour le gestionnaire de bouton, l'état étant envoyé en utilisant la réponse “SCPI_ResultBool”. La valeur retournée est inversée car ce bouton est un composant actif à l'état bas.

La fonction de gestion du LED analyse le paramètre d'état du bouton reçu et définit l'état du LED approprié. Si aucun paramètre n'existe, alors aucune action n'est prise pour cet exemple. Cette étape utilise la fonction “scpi_result_t IO_Led” pour réaliser sa fonction.

Avec le microcontrôleur programmé, vous pouvez tester le code en utilisant l'onglet Console dans l'outil DAVE. Cela démontrera la réception de la connexion et le fonctionnement de la commande de demande d'identité.

Vous pouvez vérifier l'état du bouton en envoyant une requête SCPI et tester la fonctionnalité en observant que l'état retourné change lorsque vous appuyez sur le bouton.

Vous pouvez tester la fonctionnalité du LED simplement en envoyant des commandes de marche et d'arrêt, en observant l'état de la lumière et en surveillant l'état de la console.

Avec le bouton et le LED fonctionnant correctement, vous avez la base d'un instrument connecté au réseau entièrement fonctionnel. La connexion à une plateforme d'automatisation de test ou l'écriture de votre code de test vous permettra de vérifier à distance l'état du bouton et de contrôler le LED.

Conclusion

L'article montre comment l'utilisation de l'environnement de test intégré DAVE avec une carte de développement vous permettra de créer et de connecter votre propre équipement de test en réseau pour s'intégrer à votre équipement de laboratoire et automatiser les tests en laboratoire.

Ce guide étape par étape est destiné à une démonstration de preuve de concept élémentaire, mais suivre les étapes et obtenir un système de test fonctionnel vous équipera de tout ce dont vous avez besoin pour créer vos propres instruments de test.

Nous utiliserons les principes que nous avons explorés dans ce projet pour créer un élément pratique d'équipement de test dans un avenir proche, alors restez à l'écoute pour de futurs développements.