Existe-t-il des méthodes de test standard pour le code bare metal


8

Je veux savoir si le code nu, en particulier des choses comme le code d'initialisation de périphérique / périphérique a des méthodes de test car il y a peu ou rien qui peut mal tourner lors de l'écriture dans les registres (une fois que vous savez que toutes les adresses sont mappées correctement). De plus, ce type de code a généralement très peu de branches / chemins lorsque le périphérique est configuré pour une seule fonction, alors quels types de tests seraient nécessaires ou applicables ici?

Réponses:


11

La première chose que je vérifie sur une nouvelle carte, qu'elle utilise un oscillateur interne ou un cristal externe, c'est que la fréquence d'horloge est correctement configurée. Ceci est important car de nombreux périphériques, tels que UART, SPI, I2C et les temporisateurs en dépendent.

La façon dont je le vérifie est d'écrire un programme avec une boucle courte, soit en langage d'assemblage où je peux compter les cycles manuellement, soit en C tant que vous pouvez obtenir une liste de désassemblage et faire la même chose - et allumer une LED Et hors. J'ai mis en place une boucle pour qu'elle s'exécute une fois par seconde. J'exécute le code et vérifie que la LED clignote 60 fois en une minute.

En ce qui concerne les périphériques, la meilleure façon de les vérifier est d'utiliser un oscilloscope si vous en avez un et de regarder la ligne RX pour UART, les lignes CLK, MOSI et de sélection de puce pour SPI, et les lignes SDA et SCL pour I2C, et vérifiez que les lignes basculent et que le timing semble correct.

Si vous n'avez pas d'oscilloscope, vous pouvez placer des LED sur ces lignes, puis activer ou désactiver les périphériques.Lorsque désactivé, la plupart des lignes seront faibles (LED éteinte), mais certaines seront élevées, comme le fil RX de l'UART (LED allumée). Lorsque le périphérique est activé, la plupart des voyants doivent sombrer, car les lignes basculeront. En exécutant en boucle (désactivé / activé), il est plus facile de voir la différence entre on ou dim.

Pour l'UART, vous pouvez connecter la ligne TX à la ligne RX en boucle. Vous pouvez également vous connecter ensuite à un câble UART vers USB , et sur le PC réel un terminal un programme comme RealTerm . En plus de tester l'interface, cela sera utile pour d'autres débogages plus tard.

Pour d'autres morceaux de code, j'utilise plusieurs LED si nécessaire pour montrer que différents chemins dans le code sont en cours d'exécution. Si l'UART fonctionne et est connecté à un PC, vous pouvez saupoudrer votre code d'appels à un sous-programme pour afficher un message indiquant les points atteints par le programme (ou utiliser printf si vous disposez des bibliothèques C standard disponibles). Mais comme le souligne Vladimir Cravero dans un commentaire ci-dessous, cela peut ralentir votre code (à 115 200 bauds, pas trop, car le temps d'un caractère est <10 µs). Mais dans les ISR et autres codes à temps critique, utilisez simplement des LED.

Comme le souligne Al Bundy dans un commentaire ci-dessous, les débogueurs en circuit peuvent également être utiles, en particulier si l'on peut définir plusieurs points d'arrêt, et encore plus utile si vous pouvez définir un point d'arrêt sur un emplacement de mémoire en cours de modification. Tous les débogueurs n'ont pas cette fonctionnalité.

Cependant, je n'utilise pas beaucoup de débogueurs sauf si je le dois, par exemple pour regarder des bits dans un registre périphérique; ou pour retrouver un bug que je ne trouve pas par inspection; ou à une analyse de couverture de code rudimentaire. Mais en général, j'aime exécuter des programmes à leur vitesse "normale" car de nombreux problèmes apparaissent généralement, ce qui peut ne pas être le cas lorsque le programme est en une seule étape. La plupart de mes programmes utilisent beaucoup d'interruptions, ce qui interfère avec l'utilisation d'un débogueur.


Vous avez dit à peu près tout, j'ajouterais qu'en général, saupoudrer votre code avec fprintf le ralentira beaucoup, c'est une chose que vous devez utiliser si nécessaire et si vous savez ce que vous faites. J'ai vu quelques questions (et eu quelques problèmes) sur un fprintf dans un ISR ou autre.
Vladimir Cravero

@VladimirCravero D'accord - c'est pourquoi comme utiliser des LED.
tcrosley

Merci d'avoir répondu. Avez-vous des conseils sur les outils / la configuration que vous utiliseriez pour la couverture du code au cas où vous n'auriez qu'un simulateur mais pas le matériel réel?
homme des cavernes

Et le débogueur? Ne vaut-il pas la peine de le mentionner?
Al Bundy

2
@AlBundy Je n'utilise pas beaucoup de débogueurs sauf si je dois le faire, par exemple pour regarder des bits dans un registre périphérique; ou pour retrouver un bug que je ne trouve pas par inspection; ou pour effectuer une analyse de couverture de code rudimentaire comme je l'ai mentionné dans mon commentaire au PO. Mais en général, j'aime exécuter des programmes à leur vitesse "normale", car de nombreux problèmes apparaissent généralement, ce qui ne se produit pas lorsque le programme est en une seule étape. La plupart de mes programmes utilisent beaucoup d'interruptions, ce qui interfère avec l'utilisation d'un débogueur. Je vais ajouter certains de ces commentaires dans ma réponse.
tcrosley
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.