J'ai un module de traitement d'interruption qui contrôle le matériel d'interruption du contrôleur sur un processeur intégré. Maintenant, je veux ajouter plus de tests. Actuellement, les tests ne teste que si la nidification des interruptions fonctionne en faisant deux interruptions logicielles de l'ISR, une avec une priorité faible et une avec une priorité élevée. Comment puis-je tester ce module plus loin?
4 Réponses :
Je ne suis pas un développeur intégré, je ne sais donc pas si cela est possible, mais que diriez-vous de découpler le code qui gère les interruptions du mécanisme de l'enregistrement de rappel? Cela vous permettrait d'écrire un code simulateur d'interruption d'interruption, comme vous l'aimez ...
Les chances sont qu'il n'y a pas de mécanisme d'enregistrement de rappel. Une interruption se produit et la routine de service d'interruption appropriée (fixe au moment de la compilation) est appelée.
Je suggère que vous essayez également de créer d'autres stimuli.
Souvent, également des interruptions matérielles peuvent être déclenchées par logiciel (test automatique) ou le débogueur en établissant un drapeau. Ou comme une interruption via des E / S. Ou une interruption de la minuterie. Ou vous pouvez simplement définir le bit d'interruption dans un contrôleur d'interruption via le débogueur pendant que vous êtes unique.
Vous pouvez ajouter des contrôles d'exécution sur des choses qui ne sont pas censées arriver. Parfois, je choisis de définir des broches de sortie pour surveiller l'extérieur (bien si vous avez un oscilloscope ou analyseur de logique ...) L'inconvénient de l'interruption du logiciel est que le moment est que le moment est le moment fixé; toujours la même instruction. Je crois que vous aimeriez voir la preuve qu'il fonctionne toujours; Image libre. pour interrompre les routines de service je trouve des critiques de code très précieux. En fin de compte, vous ne pouvez tester que les situations que vous avez imaginées et à un moment donné que l'effort des tests sera très élevé. Les ISR sont notoirement difficiles à déboguer. Je pense qu'il est utile de fournir des tests pour les éléments suivants:
- ISR n'est pas interrompu pour une interruption de priorité inférieure
- ISR n'est pas interrompu pour une interruption de la même priorité
- ISR est interrompu pour une interruption de priorité plus élevée
- Nichement maximal dans les limitations de pile. Certains de vos tests peuvent rester dans le code comme instrumentation (afin que vous puissiez surveiller par exemple le niveau de nidification maximal. OH, et une autre chose : J'ai généralement réussi à garder les ISR si courts que je puisse m'abstenir de nichier ... Si vous pouvez cela vous obtiendra une simplicité supplémentaire et une plus grande performance.
+1 Bon résumé, surtout commenter les ISR courts et éviter la nidification.
+1 Comme al, plus, je suis d'accord que les ISR sont particulièrement bons pour les critiques de code.
Je recommande des tests matériels réels. La manipulation d'interruption est intrinsèquement aléatoire et imprévisible.
Utilisez un générateur de signal et nourrir une onde carrée dans la goupille d'interruption appropriée. Utilisez plusieurs générateurs (ou un avec plusieurs sorties) pour tester plusieurs lignes IRQ et vérifier la manipulation de priorité.
Expérience avec la composition de la fréquence en haut et en bas sur les générateurs de signaux (modifiez les tarifs entre eux) et voir ce qui se passe. Avoir beaucoup de code de diagnostic pour vérifier l'état du contrôleur d'interruption dans les différents états.
Absolument vrai que les ISR doivent être testés dans le matériel, mais mon expérience est que cela peut être fait pour prouver que c'est la correction dans un environnement bien connu. J'ai vu des ISR échouant à mi-parcours à mi-parcours avec des symptômes étranges, pour des raisons qui n'étaient pas visibles lors des essais matériels précoces, mais qui auraient été exposés par examen de code et test unitaire.
Pour des choses comme ceci, je recommande vivement quelque chose comme le Vérificateur de modèle de spin . Vous finissez par tester l'algorithme, pas le code, mais les tests sont exhaustifs . De retour dans la journée, J'ai trouvé un bogue dans gdb < / code> en utilisant cette technique.