Question:
Cycle de vie des tests logiciels des applications embarquées
Ahmed Saleh
2014-03-26 13:34:10 UTC
view on stackexchange narkive permalink

Je n'ai pas de JTAG et je ne peux pas me le permettre pour ma puce ARM Cortex M3.

Je me demande comment les professionnels déboguent leurs applications?

  1. Flashez-vous votre uC à chaque fois, fréquemment, puis vous exécutez et testez, puis changez-vous? est-ce une mauvaise pratique?
  2. Utilisez-vous uniquement UART ou LCD pour écrire des journaux à l'écran?

J'ai besoin de conseils et astuces de professionnels :)

Cela dépend de ce dont vous disposez. Un JTAG, c'est bien. UART fonctionne également. Un simple clignotement de LED peut être utilisé. Tout ce qui fait le travail.
@PeterKarlsen Je n'ai que LCD, UART ne peut pas être utilisé, il est partagé avec le bus LCD FSMC. Je n'ai pas non plus de JTAF, je pense que JTAG faciliterait le processus?
Un JTAG faciliterait probablement les choses. Vous êtes dans la même situation que moi auparavant. Pendant de nombreuses années, je n'avais pas de JTAG. J'avais un oscilloscope, si souvent je l'ai connecté à quelques ports de rechange sur l'appareil sur lequel je travaillais. Ensuite, je basculerais les bits de port sur certains événements de mon code pour avoir une idée de ce qui se passait. Vous pouvez probablement utiliser l'écran LCD, mais il n'est pas facile de comprendre le timing lors de l'utilisation de l'écran LCD.
@PeterKarlsen Le problème est que je crée une application graphique, comme un moteur de rendu 3D, et qui nécessiterait beaucoup de tests: /
Quelque chose comme un moteur de rendu 3D doit être bien testé avant de s'approcher du processeur intégré.
@BrianDrummond +1 C'est un bon point, j'écrirai une application SDL qui pourra accéder au frame buffer, .. etc. en utilisant ANSI-C puis la porter directement sur l'uC. En fait, je l'ai fait et cela a fonctionné pour une pixellisation triangulaire.
Pas directement sur le sujet, mais ... de nombreuses commissions d'évaluation ont intégré JTAG / SWD. La carte d'évaluation STM32F4 Discovery, par exemple, comprend un module JTAG USB STLINK v2 intégré et ne coûte que 15 USD environ. Le JTAG / SWD est lent mais parfaitement fonctionnel et peut être redirigé de la carte d'évaluation vers un autre périphérique cible. Cela pourrait au moins résoudre votre problème de «ne pas se permettre».
Cinq réponses:
#1
+9
markrages
2014-03-26 22:18:36 UTC
view on stackexchange narkive permalink

Ceci est plus un article de blog, mais voici:

Si vous écrivez en C, vous pouvez compiler votre code et l'exécuter sur votre bureau. Cela ne teste pas les pilotes matériels de bas niveau, mais peut tester tout le code logique.

Recommandations sur cette approche:

  1. Si vous êtes sur ARM, vous pouvez utiliser le même compilateur (gcc) dans les deux cas. Ensuite, toutes les extensions spécifiques au compilateur continueront de fonctionner.
  2. Mais les extensions spécifiques au compilateur ne sont pas souhaitables, vous pouvez donc compiler la version de bureau avec Clang / LLVM à la place (avec l'avantage de meilleurs messages d'erreur).
  3. Mon bureau est un PC Linux. Rien dans cette approche n'est spécifique à Linux. Mais Linux crée un bel environnement de développement en C.
  4. Utilisez stdint.h et des types comme uint64_t , au lieu de " unsigned long int ". Cela vous permet d'obtenir le même comportement lorsque compilé sur différents systèmes.
  5. Mais méfiez-vous de la promotion des entiers de C. Si possible (c'est sur ARM), utilisez un PC 32 bits pour tester le code ARM 32 bits.
  6. En ce qui concerne les pilotes matériels, j'ai trouvé deux approches avantageuses.
    1. Make un prototype live sur PC. Le PC dispose d'une horloge en temps réel et d'une connexion réseau et d'un écran et d'entrées, donc ceux-ci sont pris en charge. (Mon PC a même un accéléromètre.) Vous pouvez utiliser libSDL pour animer une image de votre produit final et recevoir des pressions sur les touches. Pour les autres fonctions de votre carte, connectez des cartes de développement ou faites semblant. L'avantage de cette approche est que vous pouvez l'utiliser dans le système en direct et vous éviter d'avoir à fabriquer du matériel si vous trouvez qu'il ne résout pas le problème dont vous avez besoin.
    2. Créez un prototype mort qui lit les événements d'entrée d'un fichier et écrit les événements de sortie dans un fichier. Maintenant, pour le test, vous pouvez enregistrer (ou synthétiser) des événements qui correspondent à des scénarios spécifiques que vous souhaitez tester. Et puis vous pouvez vérifier que les bonnes choses sont écrites dans la sortie. L'avantage de ceci est qu'il laisse une suite de tests entièrement automatisée que vous pouvez exécuter au moment de la construction pour détecter les régressions.
  7. Utilisez les options du compilateur -Wall -Wextra -Werror et conservez vos code sans avertissement. Vous passerez un certain temps à corriger les avertissements, mais cela accélère le codage en réduisant le temps de débogage.
  8. Compilez la version PC à l'aide de garde-boue. Cela attrape beaucoup de méfaits du pointeur. Certaines personnes recommandent Valgrind, mais ce n'est pas aussi utile pour le code qui n'utilise jamais malloc () ou free().
  9. Pour le débogage PC, utilisez GDB ou DDD ou printf () , au goût. Il existe une grande variété d'outils de débogage de bureau matures et utiles disponibles.
  10. Même si je ne fais pas la configuration de débogage complète du PC, j'inclurai souvent un test unitaire main () à la fin d'un fichier qui est #define 'sorti. Ce main () essaie toutes les fonctions délicates du fichier et retourne 0 pour tous les pass ou asserts () pour échec. Ensuite, j'ajoute une cible "test" dans le makefile qui compile et exécute les tests de chacun des fichiers individuels.
  11. Il existe de nombreuses plates-formes de tests unitaires que vous pouvez utiliser. Il y en a tellement parce qu'ils sont très faciles à écrire. Je ne les utilise pas. Je ne veux pas d'un joli rapport sur les "tests de pourcentage réussis". Je veux que mon test meure au premier échec. Visual Basic avait une fonctionnalité risible appelée " sur la reprise d'erreur suivant". Je ne sais pas pourquoi vous souhaiteriez cette fonctionnalité pour les tests unitaires.

Si vous effectuez des tests unitaires autonomes de cette manière, vous constaterez que vous avez très peu besoin de débogage sur puce. De plus, vous constaterez que le portage vers différentes plates-formes matérielles est beaucoup plus facile car la logique de base et les pilotes matériels sont bien séparés.

#2
+4
Rev1.0
2014-03-26 14:01:02 UTC
view on stackexchange narkive permalink
  1. Travailler avec des systèmes embarqués sans OS ni console distante, il est assez courant de faire beaucoup de flashage pour tester les changements. Lorsque vous avez un système basé sur Linux, vous pouvez potentiellement simplement changer du code de script python à la volée.

  2. Personnellement, je trouve une console UART pour la sortie de débogage et l'exécution de commandes de débogage inestimable. C'est un bon moyen de suivre le déroulement du programme et de déclencher certaines fonctionnalités.
    J'ai tendance à utiliser différents niveaux de débogage, de sorte que je puisse basculer entre l'affichage des erreurs uniquement ou l'activation de la journalisation détaillée pour tout suivre en détail, par exemple.

Concernant le débogage de JTAG / dans le système: Même si JTAG est disponible, je ne l'utilise que pour traquer les problèmes d'algorithme (suite au calcul) ou vérifier les valeurs de configuration du registre / matériel. Je l'utilise rarement pour suivre le déroulement du programme, je trouve cela plus facile et plus rapide en utilisant la sortie de la console de débogage.

#3
+1
Dejvid_no1
2014-03-26 18:05:57 UTC
view on stackexchange narkive permalink

Mes 5c.Les choses sont plus rapides avec les débogueurs JTAG: regarder les variables serveur à la fois, parcourir le code, ajouter des points d'arrêt, regarder des emplacements mémoire plus grands, détecter des erreurs stupides: cette interruption que vous avez oublié de désactiver.

#4
  0
John U
2014-03-26 20:10:33 UTC
view on stackexchange narkive permalink

Vous pouvez vous débrouiller avec presque pas d'E / S à déboguer, mais la difficulté est inversement proportionnelle à l'E / S disponible - regarder une broche d'E / S avec une portée prendra beaucoup plus de temps pour déboguer quelque chose qu'un JTAG ou un débogueur similaire qui peut arrêter le processeur & examine tout, pas à pas, trace, etc.

Pour les choses de base, vous n'avez pas besoin de beaucoup de débogage, pour les choses très complexes, plus on est de fous.

#5
  0
JRobert
2014-03-27 01:15:43 UTC
view on stackexchange narkive permalink

Pour les systèmes qui devaient fonctionner à pleine vitesse (par exemple, contrôler quelque chose qui ne pouvait pas être suspendu à un point d'arrêt et ne devrait pas être autorisé à fonctionner de manière incontrôlée), et qui ne pouvaient pas tolérer ou atteindre le débit de données série requis lors de l'exécution, J'ai bourré des échantillons bruts dans un tableau pour les vider à la fin de l'analyse et les interpréter hors ligne. Cela ajoute un temps d'exécution minimal au détriment de l'espace mémoire.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...