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.

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.

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.

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.

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.