Les abstractions et les bonnes pratiques de code en C ++ intégré peuvent-elles éliminer le besoin du débogueur?
Je suis développeur C pour un système embarqué. YouTube a récemment commencé à recommander des discussions sur le "C++ pour les systèmes embarqués". Après avoir regardé certains d'entre eux, ils piquent mon intérêt, mais aucun d'eux ne répond à la question qu'ils me laissent.
Ces discussions (en particulier C++ moderne dans les systèmes embarqués par Michael Caisse) préconisent un processus de développement par lequel, au lieu de:
- écrire et éditer du code
- le déboguer pour confirmer qu'il fonctionne (ou, plus probablement, le déboguer pour voir ce qui ne va pas et où aller à partir d'ici)
- répéter jusqu'à travailler
... il faut éviter complètement le débogueur, en espérant que le choix de la langue et des bonnes pratiques rendent les bogues moins probables, ce qui élimine alors le besoin du débogueur.
Mais en tant que personne qui écrit le firmware d'un microcontrôleur qui contrôle les circuits analogiques, beaucoup de mes problèmes sont détectés lorsque le matériel présente un comportement inattendu et je trouve que je ne peux enquêter sur ce comportement (en particulier le calendrier des événements) qu'en lançant des points d'arrêt sur tout mon code et en attendant pour voir les événements se produire dans le désordre, ou ne pas se produire du tout.
Cela révélera alors soit un registre mal configuré, soit un comportement inattendu de l'un des périphériques du microcontrôleur, ce qui n'était pas évident dans le manuel de l'appareil et nécessite une petite refonte du code. Ces discussions ont mon attention, mais je ne vois pas comment ces techniques qui sont censées aider des gens comme moi, m'aident réellement avec les problèmes de matériel.
Les abstractions et les bonnes pratiques de code (pour lesquelles je suis tout à fait) peuvent-elles éliminer le besoin du débogueur (quelque chose que je considère comme nécessaire pour résoudre les bogues matériels)?
Je pense que vous déformez le message de la vidéo "Modern C++ in Embedded Systems". Le fait est qu'il y a des gens dans le monde intégré qui écrivent du code puis le testent en exécutant le code dans le débogueur pour vérifier qu'il fait ce qu'ils pensent qu'il fait. Il fait valoir qu'une meilleure alternative consiste à utiliser des abstractions afin que le compilateur puisse vérifier que certaines hypothèses sur le code sont valables.
Cette méthode permet toujours d'utiliser le débogueur pour trouver des bugs, notamment des problèmes matériels. Vous ne devez tout simplement pas utiliser le débogueur pour comprendre le code, il doit être compréhensible et correct en l'écrivant de cette façon.
L'avantage d'utiliser des abstractions plus élevées pour valider les hypothèses est qu'il existe certains types de bogues, par exemple ayant une fonction f(int mode, int value) qui s'appelle f(value, mode), qui peut être complètement évitée. Michael Caisse soutient que l'utilisation des bons outils, par exemple les types forts en C++ atténuent cela et doivent donc être utilisés.
Non pas du tout !
Les abstractions et les bonnes pratiques peuvent bien sûr réduire les risques d'erreurs. Par exemple:
les abstractions de langage permettent au compilateur de générer du code, que vous auriez à écrire vous-même autrement. Par exemple, le modèle d'objet C++ garantit que les objets construits sont détruits comme ils étaient censés l'être, sans plus de soin sur vos épaules;
ces abstractions permettent de construire des constructions plus sûres que vous pouvez utiliser dans votre code, telles que RAII , ou pointeurs intelligents qui atténuent considérablement la tâches liées à la gestion de la mémoire;
une riche bibliothèque de conteneurs et une bibliothèque d'algorithmes puissants évitent en outre que vous ayez à écrire vous-même beaucoup de code sujet aux erreurs en utilisant des implémentations déjà testées et hautement optimisées.
Mais tout cela ne fera que réduire la probabilité de bugs. Il n'éliminera jamais complètement les bugs. Vous continuerez donc à utiliser le débogueur et les fichiers journaux pour les poursuivre.
Cette question se résume à "pouvez-vous écrire du code sans bug la première fois à chaque fois?" La réponse sera toujours non.
Oui, il existe des pratiques qui peuvent vous aider, vous pouvez isoler les modules. Vous pouvez compiler à la fois pour l'embarqué et le bureau, puis tester et développer sur le bureau. Vous pouvez créer des couches d'abstraction matérielle qui aident à isoler ces modules afin que vous puissiez les tester et les déboguer plus facilement sur PC.
Il est certainement utile de réduire l'utilisation des débogueurs sur les plates-formes embarquées, car ils sont généralement beaucoup plus lents que sur PC et votre REPL est donc beaucoup plus lent.
Mais, finalement, quelque chose va apparaître qui nécessite un débogueur quelconque. Parfois, c'est un débogueur JTAG, parfois c'est un oscilloscope ou une LED clignotante.
Il existe deux types de base de bogues logiciels:
- Le code ne fait pas ce que vous vouliez.
- Ce que vous vouliez, c'était la mauvaise chose à faire.
Le choix des langues, etc. peut (ou non) avoir un impact sur le premier type de bogue, mais il n'a aucun effet sur le second. Remarque: par "ce que vous vouliez", j'entends le comportement observable du logiciel dans le monde réel, et non les décisions de conception internes.
Pour un système embarqué du monde réel, la probabilité que vous ayez bien compris tout que le monde réel puisse lancer sur votre logiciel est, de manière réaliste, nulle. Attendez-vous donc à la chasse aux insectes!
Si tout ce que vous faites est parfait, vous n'avez pas besoin d'un débogueur. Personne n'est parfait.
Il y a une classe majeure de bugs que j'ai vu dans ma carrière qui peut être décrite comme l'auteur pensée ils savaient ce que le code faisait, mais en fait, il a fait autre chose. Lorsque cela se produit, vous avez besoin d'un outil qui montre précisément ce que l'ordinateur a fait, plutôt que ce que vous pensiez qu'il a fait. Cet outil est le débogueur (ou une suite d'outils connexes, comme les niveaux de journalisation hyperparanoïdes).
Un cadre qui vous empêche littéralement de confondre le moteur gauche et le moteur droit est probablement trop restrictif pour faire quoi que ce soit d'intéressant. Si vous personnalisez un cadre généralisé suffisamment pour atteindre ce point, vous avez un corps de code de taille décente qui va besoin d'un débogueur. En effet, j'ai rencontré récemment un cas comme celui-ci qui a été résolu avec l'application simultanée d'un débogueur, d'une bonne documentation logicielle et de certains modèles Lego. Je n'aurais pas voulu résoudre le problème avec l'un de ces outils fondamentaux manquant.
Il y a eu des programmeurs qui utilisent l'approche sans débogueur. Donald Knuth était célèbre pour avoir réfléchi à un programme du début à la fin, et alors seulement commencer à écrire le code. D'après ce que je comprends, son code était remarquablement exempt de bogues, souvent compilé et exécuté la première fois! Mais je suis certain qu'il apprécierait un débogueur lorsque votre firmware provoque une exception PCI-e en raison d'un timeout!
Les débogueurs, tout en étant un outil utile pour de nombreuses choses, sont par définition principalement destinés au ... débogage. Votre question se résume donc à savoir si les bonnes pratiques et le recours à du code tiers peuvent éliminer complètement les bogues.
[...] confiant que le choix de la langue et des bonnes pratiques rend les bogues moins probables, ce qui élimine alors le besoin du débogueur.
Comme vous l'avez dit, même si vous croyez que vos langages/cadres et bonnes pratiques rendent les bogues moins probables, vous n'avez pas éliminé tous les bogues, mais réduit le probabilité de leur apparition. Sans débogueur (ou une approche similaire telle que la journalisation), comment diagnostiquerez-vous les bogues qui se produisent encore?
De plus, si tout le monde fait confiance à 100% à ses langages et frameworks, comment découvrir les défauts dans les langages/bibliothèques eux-mêmes? Ouvrez n'importe quel projet grand public sur GitHub et voyez combien de problèmes sont signalés.
Les bonnes pratiques peuvent certainement réduire les défauts logiciels , mais même les meilleures pratiques et les outils n'élimineront jamais l'utilité d'un débogueur.
Je pense que votre réponse est dans votre propre commentaire:
[...] bon nombre de mes problèmes sont détectés lorsque le matériel présente un comportement inattendu
Le problème avec les bugs, c'est qu'on ne les voit jamais venir!
Isoler deux cas d'utilisation spécifiques, dans le cadre d'un développement embarqué:
En tant que outil de développement le débogueur est essentiel pour tester le code et les états d'exécution dans un environnement stérile et contrôlé.
En tant que outil de diagnostic le débogueur est essentiel pour diagnostiquer et comprendre les modes de défaillance d'un firmware intégré.
Donc non , il ne peut pas être éliminé, du moins pas complètement.
Les appareils intégrés interagissent avec les conditions du monde réel, de sorte que les tests finaux d'un micrologiciel intégré sont effectués dans des conditions réelles et non par des contraintes induites par le débogueur (tests de stress environnementaux et d'application). Il existe des "bogues logiciels" qui sont purement du domaine du développement de l'ingénieur logiciel (SE) et des "bogues système" qui sont des bogues qui surviennent lorsque le micrologiciel interagit avec les conditions réelles de son application intégrée.
Pendant le développement embarqué, le SE en collaboration avec l'ingénieur en électronique (EE), l'ingénieur en mécanique (ME) et le chef de projet (PM) définiront les conditions de fonctionnement nominales et la fonction attendue de votre fonctionnalité de micrologiciel. Dans cette activité de développement, le débogueur et le périphérique ICE/SWD sont inestimables pour permettre
- Surveillance du système
- Détection d'erreur de code
- Condition de test contrôlé
Comparé à la journalisation, qui sur un système embarqué peut avoir de nombreux effets secondaires et complexités, il s'agit d'un moyen particulièrement intrusif de développer et de tester avec confiance que les conditions nominales sont proches du monde réel et que tous les bogues "logiciels" immédiats sont éliminés.
Une fois le micrologiciel terminé, un cycle de qualification et de test est requis. Contrairement aux logiciels purs, il existe généralement un composant physique réel dans un périphérique intégré et l'efficacité du micrologiciel associé. L'environnement peut affecter des choses comme
- Taux d'entrées et d'interruptions
- Qualité des données des capteurs externes
- Conditions de fonctionnement et taux d'erreur de base de divers protocoles et interfaces d'E/S
- Autres conditions dépendantes de l'environnement.
Tout cela servira à stresser votre micrologiciel intégré à un point où tous les contrôles de logique et de condition d'erreur seront tous soumis à des tests de stress. Vous êtes pour ainsi dire dans une mer agitée par rapport à votre environnement de développement ...
Ainsi, un cycle de test de périphérique intégré combinera
- Contrainte environnementale (vibration, thermique, électrique)
- Contrainte d'E/S (protocoles et interfaces externes)
- Stress d'application (performances exigeantes)
- Tout autre stress applicable
Afin de tester le système, et à son tour, le firmware intégré.
Dans ce contexte, le débogueur, en combinaison avec ICE/SWD, est un outil de diagnostic précieux pour
- Comprendre la nature d'un bug ou d'un problème
- Mettre le blâme sur l'EE pour visser le matériel
- Diagnostiquer et surveiller le système après l'apparition d'une faiblesse
Donc, même ici, non , le débogueur est un outil précieux.