Testing Code pour l'application Embarqués

Question

Contexte:

Je développe un projet à l'aide largish ATmega2560 Atmel AVR. Ce projet contient beaucoup de fonctions matérielles (7 périphériques SPI, 2 I2C, 2 ports MODBUS RS485, beaucoup d'E/S analogiques et numériques). J'ai développé des "pilotes" pour tous ces périphériques qui fournissent à la boucle principale de l'application une interface pour accéder aux données requises.

Question:

Le projet que je développe finira par répondre à des normes SIL. Je voudrais pouvoir tester le code et fournir un bon niveau de couverture de code. Cependant, je suis incapable de trouver des informations pour me lancer sur la façon dont un tel cadre de test devrait être mis en place.

L'idée est que je peux avoir une suite de tests automatisés qui permettront de tester de futures corrections de bugs et ajouts de fonctionnalités pour voir si elles cassent le code. La chose est que je ne comprends pas comment le code peut être testé sur puce. Ai-je besoin de matériel pour surveiller les E/S sur l'appareil et émuler les périphériques connectés de l'extérieur? Tous les pointeurs qui pourraient être fournis seraient très appréciés.

--Steve

Answer 1

Ceci est une très bonne question - une préoccupation commune pour les développeurs intégrés. Malheureusement, la plupart des développeurs embarqués ne sont pas aussi concernés que vous et ne testent le code que sur du matériel réel. Mais comme une autre réponse l'a fait remarquer, cela peut tester simplement la fonctionnalité nominale du code et non les cas de coin/erreur.

Il n'existe pas de solution unique et simple à ce problème. Certaines lignes directrices et techniques existent, cependant, pour faire un travail relativement bon.

Commencez par séparer votre code en couches. Une couche doit être "agnostique matérielle" - c'est-à-dire appels de fonction. Ne demandez pas à l'utilisateur d'écrire directement dans les registres HW. L'autre couche (inférieure) traite du HW. Cette couche peut être "raillée" afin de tester le niveau supérieur. Le niveau inférieur ne peut pas vraiment être testé sans le HW, mais il ne va pas changer souvent et nécessite une intégration matérielle profonde, donc ce n'est pas un problème. Un «harnais de test» sera tout votre code agnostique HW de haut niveau avec un «faux» niveau inférieur spécifiquement pour les tests.Cela peut simuler les appareils HW pour une fonctionnalité correcte et incorrecte et ainsi vous permettre d'exécuter des tests automatisés sur le PC.

Answer 2

Ne faites jamais fonctionner des tests unitaires sur ou contre le matériel réel. Toujours se moquer de vos interfaces d'E/S. Sinon, vous ne pouvez pas simuler des conditions d'erreur et, plus important encore, vous ne pouvez pas compter sur le test pour réussir. Donc, ce que vous avez besoin est de diviser votre application en différentes parties que vous pouvez tester de façon indépendante. Simulez (ou simulez) tout le matériel dont vous avez besoin pour ces tests et exécutez-les sur votre PC de développement.

Cela devrait couvrir la majeure partie de votre code et vous laisse avec les pilotes. Essayez de faire en sorte que le code du pilote fonctionne le plus possible sans le matériel. Pour le reste, vous devrez trouver un moyen de faire fonctionner le code sur le matériel. Cela signifie généralement que vous devez créer un banc d'essai avec des périphériques externes qui répondent aux signaux, etc. Comme cela est cassant (comme dans «vos tests ne peuvent pas faire ce travail automatiquement»), vous devez exécuter ces tests manuellement après avoir préparé le matériel.

Answer 3

Vectorcast est un outil commercial pour exécuter des tests unitaires sur le matériel avec une couverture de code.

Answer 4

Avez-vous un connecteur JTAG? Vous pouvez utiliser JTAG pour simuler des conditions d'erreur sur la puce.

Answer 5

J'aime séparer les tâches. Par exemple, quand j'ai fait un tampon circulaire pour mon AVR Atmel, j'ai tout écrit dans Code :: Blocks et je l'ai compilé avec le compilateur GCC normal au lieu du compilateur AVR GCC, puis je crée un test unitaire pour celui-ci. J'ai utilisé un fichier d'en-tête spécial pour fournir les types de données appropriés avec lesquels je voulais travailler (uint8_t par exemple). J'ai trouvé des erreurs avec les tests unitaires, les ai corrigés, puis j'ai pris le code fixe sur AVR Studio et je l'ai intégré. Après cela, j'ai utilisé des fonctions de support et ISR pour adapter le tampon en code utile (par exemple, retirer un octet du buffer, le pousser dans le registre de sortie UART, ajouter une constante chaîne au buffer pour une fonction printf, etc.). Ensuite, j'ai utilisé le simulateur AVR pour m'assurer que mes ISR et fonctions étaient appelées et que les bonnes données apparaissaient dans les registres. Après cela, je l'ai programmé sur la puce et ça a fonctionné parfaitement. Je préfère grandement les capacités de débogage de Code :: Blocks par rapport à AVR Studio donc j'utilise l'approche ci-dessus chaque fois que je le peux. Quand je ne peux pas, je ne traite généralement que du matériel. Par exemple, j'ai une minuterie qui produit automatiquement une onde carrée. Le mieux que je pouvais faire était de voir que l'on pinçait la broche dans le simulateur. Après cela, je devais juste accrocher une lunette et m'assurer. J'aime utiliser une approche multi-niveau lors du débogage des problèmes. Par exemple, avec l'horloge, la première couche est "Mettez une sonde sur la broche de l'horloge et voyez s'il y a un signal". Si ce n'est pas le cas, sondez la broche sur l'UC et recherchez le signal. Ensuite, j'ai codé une interface de débogage dans un de mes UARTs où je peux regarder des valeurs de registre spécifiques et m'assurer qu'elles sont ce qu'elles sont censées être. Donc, si cela ne fonctionne pas, l'étape suivante consiste à appeler la valeur du registre et à vérifier qu'elle est correcte. Essayez de penser à quatre étapes ou plus chaque fois que vous planifiez votre débogage. Il devrait y avoir + 5V ici, mais s'il n'y a pas? Ecrire dans l'interface de débogage un moyen de basculer la broche et voir si cela change. Et si ça ne marche pas? Faire quelque chose d'autre, etc etc etc Vous arrivez à un point où vous rencontrez «Je n'ai aucune idée pourquoi ce DANG CHOSE NE FONCTIONNE PAS !!!!" mais j'espère que vous comprendrez la raison à l'avance.