Test unitaire du langage d'assemblage AVR

Comment testez-vous à l'unité votre code d'assemblage?

Je travaille sur un servocontrôleur série dans le cadre d'un projet de robot hexapode et le code est au point où ça devient compliqué;) Quoi qu'il en soit, j'ai l'habitude d'utiliser des tests unitaires dans mon travail de jour en tant que développeur de serveur C ++ et ont donc essayé d'appliquer les mêmes types de tests à mon code d'assemblage AVR. J'ai trouvé un moyen qui fonctionne bien pour moi (voir ici ) mais je suis intéressé s'il y a des outils ou des techniques standard qui me manquent.

Mise à jour: Pour ceux d'entre vous qui sont intéressés, la source complète du servo-contrôleur et les tests unitaires sont maintenant disponibles ici .

Je décrirais également cela comme élégant, mais je voudrais ajouter le problème, si vous pardonnez mon intrusion.

Je sais qu'il existe des logiciels très coûteux pour gérer des situations comme celle-ci, mais dans l'entreprise où je travaille, nous ne pouvons pas nous permettre le coût à moins d'être sûrs qu'il fait ce dont nous avons besoin.

Le développement piloté par les tests (TDD) est l'un des meilleurs systèmes dont j'ai entendu parler pour le développement, et je l'apprécie, mais les problèmes qui prennent mon temps sont généralement causés par des interruptions complexes et des événements matériels que beaucoup appellent des problèmes. Cela semble être une chose mineure d'avoir un problème toutes les 2 heures lorsque les étoiles s'alignent, mais si votre téléphone gelait une fois par semaine, vous maudiriez le nom de l'ingénieur. Dans notre cas, nous devons marcher dans un lot d'alimentation lorsque les choses se cassent vraiment, ce que, comme vous pouvez l'imaginer, j'aime éviter.

J'ai vu des solutions très intelligentes pour vérifier la fonctionnalité des sous-systèmes, qui, si elles étaient correctement mises en œuvre, me feraient probablement gagner 3 heures sur une semaine de travail de 50 heures, mais s'il y avait un moyen intelligent de trouver des situations de pépin, cela me ferait économiser des semaines de travail à la recherche du "bug" qui se produit occasionnellement sur le terrain sous une lourde charge.

Ce message n'aide probablement pas beaucoup, mais je trouve que tout mettre en lumière rend tout plus facile à résoudre. S'il y avait une méthode TDD pour trouver des situations de pépin, je pourrais obtenir 10s de milliers alloués pour le payer. -Max

Intéressant. Après Noël, je prévoyais de faire un assembleur avec des photos, quand j'aurai un peu plus de temps, j'aurai un bon aperçu de votre système.

Une façon que je pourrais voir serait de scripter une sorte de framework dans un langage différent pour créer et démolir les objets fictifs, etc., mais comment vous interfaceriez cela avec la puce / simulation serait un problème.

Si cela devient trop onéreux, cela l'emportera sur les avantages des tests unitaires et vous rendra moins désireux de l'utiliser.