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.
