Introduction
Vous allez obligatoirement être confronté à des difficultés lors de chaque mise en pratique et la résolution de ces problèmes fait partie des apprentissages à faire. La difficulté avec le développement embarqué est que les problèmes peuvent être logiciels ET matériels.
Pour les problèmes logiciels, vous avez à votre disposition les outils suivants :
Le debugger de MRS
printf() vers le terminal de MRS
Connecter des LED à des lignes de GPIO et les allumer à des points précis de votre code (dans certains cas, il se peut que printf() soit trop lent pour être utilisable).
Pour les problèmes matériels, vous avez votre cerveau et quelques instruments :
Votre multimètre vous permettra de vérifier tensions, courants et continuité.
Un analyseur logique bas de gamme couplé avec le logiciel libre PulseView peut rendre de grands services pour diagnostiquer des problèmes avec les protocoles SPI, UART, I2C, ou encore remplacer les LED évoquées plus haut pour analyser des problèmes de timing dans votre code.
Un oscilloscope devient incontournable dès que vous sortez du cadre des travaux pratiques bien délimités de ces cours. Il vous aidera à diagnostiquer des problèmes invisibles autrement tels qu'une ligne de GPIO endommagée ou mal configurée, un temps de montée trop long sur un signal d'entrée, etc.
Choix du matériel
N'investissez dans un analyseur logique et/ou un oscilloscope que si vous sentez que vous accrochez vraiment au développement embarqué et que vous souhaitez aller plus loin que ces cours. Ne dépensez pas non plus une fortune, vous n'auriez pas l'usage d'un matériel haut de gamme.
Pour l'analyseur logique, un clone de Saleae Logic dénommé "24MHz 8 canaux" sur AliExpress tel que celui-ci ou celui-là fera parfaitement l'affaire pour environ 5€.
Si vous voulez 16 canaux au lieu de 8, vous pouvez opter pour un "EZ-USB FX2LP CY7C68013A" comme celui-ci pour à peu près le même prix.
Ces 3 analyseurs logiques sont parfaitement supportés par Sigrok/PulseView (driver fx2lafw).
Pour l'oscilloscope, si vous avez un budget très serré et êtes prêt à accepter une utilisation malaisée, vous pouvez opter pour un Hantek 6022BE pour environ 60€. Il est parfaitement supporté par Sigrok/PulseView (driver hantek-6xxx) et peut être utilisé plus confortablement avec le logiciel libre OpenHantek6022.
Si vous avez un budget plus important, optez pour un modèle de table 100MHz 2 canaux autour de 400€. Un appareil de table offre un confort d'utilisation infiniment supérieur à celui d'un oscilloscope USB comme le 6022BE. Quand vous avez déjà affaire à un problème récalcitrant, vous appréciez de ne pas avoir besoin de vous battre aussi contre votre matériel. :)
Pour vous donner une idée de l'intérêt d'investir dans un oscilloscope, sachez que j'utilise le mien plus souvent que mon multimètre. Sans lui, je suis sourd et aveugle.
La marque RIGOL offre un excellent rapport qualité/prix. J'utilise un RIGOL DS1102Z-E et j'en suis pleinement satisfait, mais dans la même gamme de prix, vous trouverez maintenant chez RIGOL des modèles encore plus performants.
A un niveau de qualité moindre mais un prix divisé par deux, le Hantek DSO2D10 est aussi une bonne affaire. Ce peut être un compromis intéressant entre le 6022BE et un RIGOL.
Par contre, évitez les marques (autres que Hantek) proposant des prix très bas - jusqu'à un peu plus de 100€ pour un appareil de table - c'est encore trop cher pour la piètre qualité de ces produits.
Certains recommandent un oscilloscope 4 canaux car ils l'utilisent comme analyseur logique. Je ne suis pas de cet avis car ça gonfle encore le prix et j'en trouve l'utilisation comme analyseur logique peu pratique. De plus, que faites-vous si vous avez besoin de 5 canaux ? Vous achetez un analyseur logique ? Donc autant le faire dès le départ.
Enfin, si vous voulez pouvoir emporter votre matériel avec vous en déplacement, vous pourriez préférer acquérir un Digilent Analog Discovery. C'est un produit d'excellente qualité qui combine oscilloscope, générateur de signaux et analyseur logique. Il a l'inconvénient (de mon point de vue) de nécessiter l'utilisation d'un logiciel plutôt que de manipuler des boutons, mais en déplacement, c'est le top du top !
Conseils pour le dépannage et exemples
La plupart des pannes ont des causes très simples, très souvent liées aux problèmes posés par le câblage "volant". C'est à ce genre de pannes que vous serez confronté dans ces cours.
Les DuPont jumpers
Pour commencer, sachez que les DuPont jumpers sont la pire des calamités. Il faut souvent écraser un peu le connecteur femelle pour qu'il fasse vraiment contact - mais pas trop écraser quand même pour qu'il reste utilisable...
D'autre part, ils ont une fâcheuse tendance à se débiner sans prévenir, spécialement quand ils ont besoin d'un petit écrasement et que ça vous a échappé. Du coup, vous cherchez une erreur dans votre code alors qu'une connexion manque simplement à l'appel.
Ce peut être le cas par exemple quand vous ne voyez rien dans le terminal de MRS : un des jumpers peut tout bêtement être débranché ou ne pas faire contact.
L'alimentation
Quand quelque chose ne marche pas et que l'inspection visuelle ne révèle pas de jumper débranché, commencez par utiliser votre multimètre pour vérifier la tension d'alimentation.
Un exemple simple pour en démontrer l'utilité&bnsp;: supposons que vous ayez relié la sortie 3V3 de votre WCH-LinkE à votre carte CH32V003. La plupart des cours ne poseront aucun problème et vous ne vous en rendrez pas compte. Par contre, lorsque viendra le cours sur I2C et l'afficheur LCD, vous ne verrez strictement rien sur ce dernier car il a besoin d'une tension d'alimentation de 5V.
Il se peut aussi que suite à un problème de jumper, une partie de votre système ne soit pas du tout alimentée. Votre code ne fonctionnera donc pas, mais c'est normal...
La breadboard
Rien ne ressemble plus à un trou que son voisin. Si ça ne fonctionne pas, ce peut être parce que vous avez inséré la patte d'un composant dans le mauvais trou. Ça peut aussi être parce que la patte s'est un peu pliée au moment de l'insertion et qu'elle n'est pas rentrée dans le trou.
D'autre part, les pin headers des modules et cartes de développement sont un peu plus gros que des DuPont jumpers et beaucoup plus gros que des pattes de composants. Cela signifie qu'au bout d'un moment, vous aurez des faux contacts dans certains trous de la breadboard.
Moralité : avant de chercher un bug dans votre code, vérifiez le câblage avec votre multimètre en position testeur de continuité. Mais avant de faire cette vérification, offrez vous un café ou changez-vous les idées d'une autre façon. Certaines erreurs sautent aux yeux quand on les regarde avec un esprit frais. Ça vaut aussi pour les bugs dans le code.
Les maladresses et leurs conséquences
Il se peut qu'à la suite d'erreurs de câblage, vous ayez endommagé l'une ou l'autre ligne de GPIO. Il serait franchement bizarre que ça ne vous arrive pas au moins une fois.
Le symptôme en est alors que, bien que votre code envoie le bon niveau sur une sortie (et qu'elle soit bien configurée - je pense à la subtile différence entre GPIO_Mode_Out_PP et GPIO_Mode_AF_PP, par exemple), l'électronique connectée à cette sortie ne réagit pas.
Pour vérifier l'état de la sortie, déconnectez ladite électronique, faites un minuscule programme qui mettra la sortie à un niveau logique haut constant et mesurez la tension présente sur cette broche. Si elle diffère fortement de la tension d'alimentation, c'est que la sortie est grillée. Vous devrez alors modifier votre code pour en utiliser une autre si possible, ou remplacer la carte.
Par contre, si la tension est normale, ça signifie que le problème est dans l'électronique connectée à la sortie. Dans ce cas, vérifiez son câblage, en particulier la polarité de composants comme les diodes et transistors.
Si le problème concerne une entrée, déconnectez l'électronique qui y est reliée et mettez à la place une résistance pull-up (ex. 10kΩ), puis mesurez la tension sur l'entrée. Si elle est très différente de la tension d'alimentation, c'est que l'entrée est grillée. Même chose que pour la sortie, utilisez-en une autre si c'est possible ou remplacez la carte. Si la tension est normale, comme pour la sortie, vérifiez le câblage de l'électronique en amont de l'entrée.
Il peut aussi s'agir de maladresses logicielles. Un exemple : vous avez copié-collé le code gérant un périphérique I2C dans un nouveau source pour gérer un autre périphérique, mais vous avez oublié de changer l'adresse I2C. Résultat : votre code va bloquer dès l'envoi de l'octet qui suit le Start puisque le périphérique avec l'ancienne adresse n'est pas présent sur le bus...
Ce que vos yeux ne peuvent pas voir
Dans certains cas, les yeux et le multimètre ne suffisent pas pour diagnostiquer le problème. Voici quelques exemples.
Vous envoyez un message en utilisant le protocole de télécommande infrarouge NEC mais le récepteur ne réagit pas. Vous devez donc vérifier la fréquence de la porteuse, le rapport cyclique des impulsions et le respect du format du message. Pour cela, vous avez besoin d'un oscilloscope.
Vous voulez vous interfacer avec un capteur de température DS18B20 utilisant le protocole 1-Wire, mais votre code réagit comme si le capteur n'était pas connecté. Vous ne pourrez comprendre que vous avez configuré la sortie du GPIO en mode push-pull au lieu de open drain que si vous visualisez le signal avec un oscilloscope.
C'est la même chose si vous avez utilisé une résistance pull-up trop élevée sur un bus I2C, vous ne pourrez voir son impact sur les temps de montée qu'avec un oscilloscope.
Enfin, si un MCP23S17 (I/O expander SPI) ne réagit pas correctement aux commandes que vous lui envoyez, un analyseur logique vous permettra de voir si vous avez paramétré correctement le périphérique SPI de votre CH32V003 en comparant les chronogrammes relevés à ceux de la documentation du MCP23S17.
De même, les périphériques SPI utilisent le front montant de CS# pour charger les données reçues dans un registre. Si CS# remonte trop tôt, rien ne se passera, mais vous ne comprendrez pourquoi qu'à l'aide d'un analyseur logique.