La mise au point d'un système logiciel et matériel

Comment arriver à déboguer un système matériel et logiciel? Il n'y a pas de miracles. Il faut se représenter mentalement le comportement du système tel qu'il devrait fonctionner et anticiper ce qui diffère par rapport au montage réel. Plus facile à dire qu'à faire... Tout à fait vrai. Par contre, avec le temps et la patience, on en arrive à développer des habiletés et un sixième sens qui sont réutilisables dans de nombreux contextes avec divers systèmes informatiques (serveurs de fichiers, base de données, logiciels de comptabilité ou autres).

Les problèmes de mauvais fonctionnement sont tellement variés qu'il est impossible d'arriver avec une méthode qui permet un diagnostic rapide et précis à coup sûr. Par contre, il est bon d'établir quelques points de départ dans toute démarche de recherche de causes de mauvais fonctionnement. La liste qui suit n'a pas réellement d'ordre et elle confond, volontairement un peu d'ailleurs, des aspects logiciels et matériels. Quand on ne connaît pas la nature du problème, il est bien difficile de commencer à un endroit précis de toute façon.

1. Vérifier l'alimentation. On nous dit qu'un fort pourcentage des problèmes électroniques sont reliés de près ou de loin à l'alimentation. C'est encore plus vrai avec un système utilisant des piles! Une petite vérification de la tension d'alimentation avec le multimètre est si rapide qu'elle devrait être l'un des premiers réflexes de mise au point. Des DEL peuvent encore allumer même si la tension devient plus faible. Rien n'est moins certain avec d'autres composants cependant...

2. Vérifier les branchements. Est-ce que les câbles sont bien branchés et dans le bon sens. Demandez à un collègue de faire cette vérification pour vous en cas de doute. À force de passer tellement de temps devant un montage, on oublie les détails les plus bêtes...

3. Vérifier la continuité. Avec le multimètre, il est très facile de savoir si deux endroits du circuit sont bien reliés ou non. Il ne faut pas hésiter à faire des vérifications. On peut penser qu'un signal passe alors qu'il ne se rend pas du tout. Il peut aussi y avoir un court-circuit un peu particulier. Le robot est trimbalé partout et il demeure possible qu'une soudure lâche tout simplement. Par ailleurs, en se promenant avec des sondes sur le circuit, il est possible qu'une idée sur la nature du problème vienne à l'esprit, indépendamment de ce qu'on recherche vraiment!

4. Déverminer un petit nombre de lignes de code à la fois. Il est inutile d'essayer de mettre au point 800 lignes de code quand les 10 premières ne fonctionnent même pas... Il peut s'agir d'une observation assez simpliste, mais elle s'applique plus fréquemment qu'on le pense...

5. Isoler et répliquer le problème. Régler le problème est souvent l'étape la plus rapide d'un cheminement de mise au point. Trouver le problème et l'isoler de manière certaine peut prendre des heures. Il est souvent utile de réduire le problème à sa plus simple expression. En d'autres termes, on débranche les connexions des sous-systèmes qui ne sont pas impliqués dans le problème et on place en commentaires le plus de lignes de code possible. D'une part, on gagne beaucoup de confiance durant la démarche. D'autre part, on peut arriver à former un test unitaire très petit qu'on peut exercer de nouveau au besoin.

6. Attention aux «warnings» du compilateur. Très souvent, les étapes make et make install sont effectuées si rapidement que des détails très importants présentés par le compilateur ne sont même pas regardés. Attention, le compilateur est rarement un idiot...

7. Utiliser Google! Quand un message d'erreur cryptique nous apparaît, il peut être important de le confier à Google. En général, on est rarement le premier à faire face au problème... De manière plus générale, l'interrogation d'un moteur de recherche peut forcer une réflexion qui pourra permettre une certaine ouverture d'esprit aux causes potentielles du problème.

8. Revenir à une étape précédente. Faire un pas vers l'arrière pour mieux repartir vers l'avant. C'est un signe de sagesse. Recharger sur la carte le code du compteur 32 bits des travaux pratiques. Juste pour voir si ça fonctionne encore... On peut découvrir bien des problèmes avec si peu de lignes de code à la portée de la main...

9. S'assurer que le bon fichier est transmis à la carte. Erreur stupide s'il en est une. Hé oui, la fatigue joue souvent un rôle à un moment donné...

10. Lire et relire. Après des heures à suivre les instructions de montage, il devient un peu inutile d'insister sur ce point. Pourtant, on se fait prendre au piège régulièrement...

11. Marcher et aller boire de l'eau! On dit aussi que la nuit porte conseil... On commence à comprendre que l'être humain est bien moins rationnel qu'on le croyait à une certaine époque...

12. Parler à des collègues. Combien de fois a-t-on vu quelqu'un commencer à expliquer son problème sans jamais se rendre au bout de son discours parce qu'en réfléchissant tout haut, les choses deviennent soudainement plus claires...

13. Difficile lorsqu'on n’a pas de débogueur! Vrai. Par contre, on a pas toujours de dévermineur en informatique. De toute façon, le problème n'est pas toujours le code. Il faut parfois prendre du papier et redessiner des schémas qui replacent les éléments dans leur contexte. On peut trouver bien des éléments de réponse même devant une page blanche.

14. À défaut de pouvoir utiliser un débogueur on devrait presque systématiquement penser à la DEL libre et au pont en H comme outils de mise au point. Seulement savoir qu'une lumière prend une certaine couleur parce qu'une condition est respectée dans le code en dit très long sur le déroulement d'un programme.

15. Utiliser la deuxième carte à microcontrôleur. On se demande pourquoi il y a deux cartes par équipe, mais un seul robot. Il serait dommage de se priver d'utiliser la seconde. Elle peut au moins fournir une DEL supplémentaire et générer des signaux pour la première carte au besoin. La seconde carte peut aussi être utilisée à la place de la première pour au moins confirmer que le problème se reproduit, peu importe la carte utilisée.

16. Utiliser des outils pour acquérir de l'information, l'oscilloscope en premier lieu. Il est votre plus fidèle allié, tout simplement parce qu'il voit tout. Cette technique reste applicable du côté logiciel. Plusieurs commandes ou logiciels permettent d'analyser le comportement des processus, de la mémoire ou des entrées/sorties, par exemple.

17. Lire quelques livres à propos des situations les plus courantes pouvant mener à des problèmes lors du développement de logiciels et les meilleures méthodes pour les éviter. Malgré tous les problèmes matériels qui surviennent sur le robot, le plus souvent, les problèmes logiciels sont plus importants et plus difficiles à détecter. De plus, ils tendent à augmenter au fur à mesure que la session progresse et il s'agit, dans bien des cas, de problèmes qui pourraient apparaître dans d'autres situations d'écriture de code (pour site web, pour applications sur PC, etc.) Deux références bien connues:

    1. Steve Maguire, Writing Solid Code: MicroSoft Techniques for Developing Bug-Free C Programs, MicorSoft Press, Richmond, Washington, 1993, 256 p.

    2. Steve McConnell, Code Complete, 2ème édition, MicorSoft Press, Richmond, Washington, 2004, 960 p.