Ce qui est plutôt sympa avec arduino et co, c'est qu'il est facile de s'y mettre quand on est débutant et que les progrès sont possible pour passer de trucs basiques à des réalisations plus complexes...
Sauf que complexe et buggé sont souvent synonymes (enfin chez moi)
Comment (et avec quoi) débuggez-vous le code arduino ? L'IDE classique ne permet pas (ou alors j'ai pas vu) les points d'arrêts, le pas à pas ni l'évaluation de variables. Ou alors c'est une limitation intrinsèque à la plateforme ?
malheureusement non l'IDE Arduino ne le permet pas.
Un spécialiste pourrait confirmer, mais je crois que les cartes Arduino ne permet pas d'utiliser la broche de debugge des Atmels.
De plus cela nécessiterai je crois un programmateur spécial, car les cartes Arduinos sont basé sur une puce de conversion USB/port série avec un profile CDC de l'USB côté PC
Salut.
L'AtMega328 dispose du debugWire, qui permet le debug à l'aide d'un boîtier Atmel-lCE par exemple.
En 30 ans de carrière je n'ai eu recours à un debugger qu'à de rares occasions, tout simplement car quand je développe du logiciel je préfère utiliser des traces logicielles, Serial.print() dans le monde ARDUINO, qui permettent de suivre en temps (pratiquement) réel le déroulement du logiciel.
Les traces logicielles alourdissent le code et le ralentissent, mais on peut facilement les activer / désactiver à l'aide de quelques macros :
Dans cet exemple il te suffit de commenter la ligne pour désactiver les traces :
//#define LOGS_ACTIVE
Je pense que les traces logicielles sont le meilleur moyen de juger du bon déroulement d'un logiciel. Un debugger n'est utile que si tu cherches à déboguer des portions de code critiques, interruptions pas exemple, où les traces logicielles sont inutilisables.
Merci pour l'astuce : adoptée !
Néanmoins quand tu dis « alourdissent le code et le ralentissent » ok pour l'alourdissement mais une fois désactivé, compilé et chargé sur l'arduino, il y a encore un effet sur la vitesse d'exécution ?
Une autre méthode que j'utilise fréquemment, spécialement dans les "gros programmes" est la possibilité de modifier des variables, depuis la ligne de commande de l'IDE, ainsi on peut tester des valeurs de variables, sans recharger chaque fois le programme.
Cette partie est à supprimer ou à inhiber avec des #ifdef, une fois le programme au point.
On peut tout imaginer, y compris activer les logs dynamiquement, à l'aide du serial monitor, ou par exemple à l'aide d'une page HTML sur un ESP32, avec des fonctionnalités se rapprochant de LOGGING PYTHON, avec des sorties sur Serial, ou carte SD, socket, Card, avec différents niveaux (info, debug, erreurs, erreurs falates, etc.).
On peut y ajouter une notion de rotation, afin d'éliminer les fichiers les plus anciens.
J'ai développé une librairie reprenant les fonctionnalités principales du logging PYTHON :
Meilleur moyen je ne dirais pas ça, un bon moyen surement.
On en a déjà parlé, mais les logs alourdisse aussi de débogage, car les println à outrance comme l'indique @jpbbricole marche super efficace sur un programme simple, mais perd petit à petit son efficacité avec un programme complexe.
De même le débuguer permet de changer n'importe quelle variable à la volet, à des moments précis, sans l'avoir prévue à l'avance dans ton programme.
De mon point vue les explications de @hbachetti et @jpbbricole sont plus comment t'en passer, puisque ce n'est pas forcément si simple de le mettre en pratique, qu'une bonne raison de ne pas l'utiliser.
Là ou on peut surement ce rejoindre, c'est sur Arduino, le jeu en vaut-il la chandelle.
Personnellement je n'ai jamais fait l'effort, d'étudier la mise en pratique du débogage sur Arduino.
D'autant plus que j'utilise des esp8266, qui semble plus simple à débugger que les Atmel, mais en Lua
Après il y a aussi une histoire d'habitude, j'ai des collègues qui comme @hbachetti n'utilisent jamais le débuggeur, alors que d'autre comme moi, ne voudraient pas s'en passer.
Pour debugger dans les interruptions, j'utiliser des digitalWritFast et un analyseur logique. C'est comme un Serial.print booléen. De toutes façons un analyseur logique est utile même sans interruptions.
Tu pousses le bouchon un peu loin. Je te rappelle que le logiciel embarqué est mon métier. Dans ma vie professionnelle j'ai mis en oeuvre de multiples debuggers, sur ARM7, STM32, et même sur PYTHON.
Cela ne m'a jamais permis de me passer de logs, qui sont indispensables pour tracer le déroulement d'un logiciel. Quand un bug est détecté sur le terrain, se faire envoyer les logs à distance est souvent très utile, et je dirais même indispensable.
Mets-toi à la place d'un intervenant d'un service clients d'une entreprise. Il lui est facile d'envoyer des logs au développeur, après les avoir activés, par mail par exemple, alors qu'il ne saura pas lancer un debugger, forcément, et de plus il ne connait pas le code, ce n'est pas son métier.
Cependant, pour les cas difficiles, le debugger est le moyen par excellence.
Sur les derniers développements auxquels j'ai participé, on pouvait activer les logs à distance, sur certaines parties du logiciel, et les relever également à distance. Aucune intervention humaine n'était nécessaire sur place.
Je ne pense pas non!!!
Je peux moi aussi te rappeler mes 23 expériences dans l'édition de logiciel, donc je n'ais aucun problème à me mettre dans la peau d'un intervenant d'un service client, puisque dans ma société les développeurs font aussi le support, donc la dernière fois c'était vendredi
Si tu as compris que je disais que les logs ne servent à rien et ne doivent pas être utilisées, c'est que tu as mal lu, mes propos
Comme je te l'avais déjà dis dans un autre post, les logs sont pas définitions obligatoire en production, puisque souvent chez le client et que tu ne peux pas mettre en place un débuggeur, ne serait-ce que car je ne compile pas avec les informations de débogage et bien sûre que mon Visual studio n'a pas forcément accés à la machine du client
Je dis simplement, que je ne vois pas l'intérêt de ce passer de cet outil et que je suis malheureux lorsqu'il n'est pas disponible.
Alors que j'ai des collègues qui ne l'utilise jamais!
Je n'ai pas dit ça, je dis simplement que ce propos est déplacé :
Tu supposes, mais tu en as le doit, que la mise en oeuvre d'un debugger est hors de notre portée et que l'on adopte les logs par fainéantise intellectuelle.
Je te rappelle simplement qu'en embarqué le debugger n'est pas aussi simple à installer que sous VisualStudio, et qu'il faut faire un petit effort pour l'utiliser, et en tous cas posséder le bon matériel (JTAG).
C'est simplement ce que je ne comprends pas, je ne vois pas en quoi mes propos ou avis serait déplacer!
Pas du tout, si j'oserais dire, tu suppose que je suppose
Je ne vois pas pourquoi cela serait hors de ta porté?
Je ne pense pas du tout que c'est pas fainéantise intellectuelle, je pense que c'est un choix, peut être motivé par l'habitude.
Comme je l'ai dit, je suis dans l'habitude contraire, je ne dis pas non plus que mon habitude est meilleur que la tienne.
Si je devais me paraphraser, j'ai l'impression(surement à tord ) que votre propos est dit moi de quoi tu as besoin, je te dirais comment t'en penser.
Tu n'a pas besoin de me le rappeler, étant "accroc" au debugger j'en suis pleinement conscient.
C'est pour ça que si STMélectronique faisait des cartes de développement avec le wifi pour un prix plus modérer, j'en serait ravi
Je ne crois pas que les cartes Arduino permettent facilement d'utiliser la broche debugWIRE?
Il n'est pas de la responsabilité du lecteur de lever les ambiguïtés dans les propos d'un rédacteur, c'est bien au rédacteur de rédiger ses phrases de manière à ce que le doute ne subsiste pas.
Je suis content que tu me confirme que c'est à tord et je suis complétement d'accord avec toi, sur la responsabilité du rédacteur.
C'est pour ça que j'ai réagit, lorsque quelqu'un pause la question de comment faire pour faire du pap à pas et que l'on lui répond que ce n'est pas nécessaire et comment faire sans, moi lecteur, trouve ça plus que ambiguë.
Et même si c'est effectivement extrêmement important de savoir utiliser et mettre en place des logs.
Après j'ai aussi noté que tu lui as aussi répondu sur le comment faire
Mais je trouve dommage que du coup on passe, assez vite sur un moyen de faire autrement, plutôt que d'approfondir ce sujet.
Oui, c'est bien ça que j'avais noté, mais malheureusement ce n'est pas forcément en contradiction avec ce que je disais.
Après si ton propos n'est pas de dire que cela existe mais que c'est pour les nazes, la preuve, je ne l'ai jamais utiliser pendant toute ma carrière, pas de soucis, on se sera encore une fois mal compris
(enfin chez moi)
