Comment utiliser le Serial Monitor sur Arduino pour débugger son code

Le Serial Monitor d’Arduino transforme une carte muette en source d’informations détaillées sur l’exécution du programme. Chaque variable, chaque capteur, chaque branchement logique peut laisser une trace lisible, exploitable, orientée débogage pas à pas.

Encore faut‑il maîtriser la configuration, les bonnes pratiques et les pièges classiques qui provoquent un moniteur série vide, des caractères illisibles ou des mesures faussées. Le reste de l’article remonte tout le flux, du simple Serial.print() jusqu’aux stratégies avancées de diagnostic structuré.

Comprendre le rôle du Serial Monitor dans le débogage Arduino

Le Serial Monitor Arduino sert d’interface texte entre votre carte et votre ordinateur. Par le port USB et l’UART série, la carte envoie des messages, valeurs de variables, états de capteurs ou logs d’exécution. Vous observez en direct ce qui se passe dans le microcontrôleur, sans ajouter de composant matériel complexe.

Le principe repose sur quelques fonctions de base : Serial.begin() pour initialiser la liaison, puis Serial.print() et Serial.println() pour envoyer des données lisibles. Ce flux texte devient votre outil principal de troubleshooting : vous isolez une erreur logique, vous validez une condition, vous contrôlez la cohérence des mesures.

Contrairement à un débogueur matériel pas à pas, le Serial Monitor fonctionne de manière non intrusive et légère. Vous insérez des traces dans votre code, vous observez la sortie, puis vous ajustez la logique. Cette méthode reste particulièrement adaptée aux projets hobbyistes, aux prototypes et aux maquettes pédagogiques.

22 septembre 2026

Code erreur E03 sur un lave-linge Candy : 3 contrôles avant d’appeler un réparateur

0 commentaires

Configuration de base du Serial Monitor dans l’IDE Arduino

Initialiser la communication série avec Serial.begin()

La configuration commence dans le code, dans la fonction setup(). L’instruction Serial.begin(vitesse) fixe la vitesse de communication, appelée baud rate : nombre de bits transmis par seconde. Une valeur très répandue est 9600 bauds, mais les vitesses plus élevées comme 115200 réduisent la latence et fluidifient les flux volumineux.

Exemple minimal :

void setup() {
  Serial.begin(9600);  // Initialisation de la liaison série
}

void loop() {
}

Sans cet appel, aucune donnée n’apparaît dans le Serial Monitor. La liaison reste inactive, même si le moniteur est ouvert côté IDE.

Ouvrir et paramétrer le Serial Monitor dans l’IDE

Dans l’IDE Arduino, le Serial Monitor se trouve dans le menu Outils > Moniteur série ou via l’icône en haut à droite. Une fois la fenêtre ouverte, vous ajustez deux paramètres clés en bas :

• Vitesse (baud rate) : doit correspondre exactement à la valeur configurée dans Serial.begin().
• Fin de ligne : pas de fin de ligne, retour chariot, saut de ligne ou les deux (utile pour certains protocoles de commande).

Une désynchronisation du baud rate provoque des symboles étranges, du « bruit » ou un flux illisible. L’un des problèmes majeurs recensés tient précisément à un baud rate réglé différemment dans le code et dans le Moniteur.

21 septembre 2026

Code erreur sur un lave-linge Bosch : décoder la panne et éviter une réparation inutile

0 commentaires

Exemple complet : message de démarrage lisible

Ce petit exemple assure un message de démarrage clair en début d’exécution puis un compteur régulier :

void setup() {
  Serial.begin(115200);
  delay(500);                 // Laisse le temps au port série de s'initialiser
  Serial.println("Demarrage du systeme de debug...");
}

void loop() {
  static unsigned long compteur = 0;
  Serial.print("Tick : ");
  Serial.println(compteur);
  compteur++;
  delay(1000);
}

Le délai initial apporte un confort de lecture : l’IDE a le temps d’ouvrir le port, et vous ne perdez pas le message de démarrage.

Les fonctions Serial indispensables pour le débogage

21 septembre 2026

Erreur L11-06 sur Livebox 4 : 4 vérifications avant d’appeler Orange

0 commentaires

Serial.print, Serial.println : traces de base

Serial.print() envoie des données sans retour à la ligne, tandis que Serial.println() ajoute un saut de ligne automatique. En combinant les deux, vous construisez des traces structurées lisibles.

Exemple :

int temperature = 24;

Serial.print("Temperature : ");
Serial.print(temperature);
Serial.println(" C");

Cette méthode fournit une trace simple mais déjà très utile pour contrôler des mesures issues d’un capteur, valider une conversion analogique-numérique ou vérifier une formule de calcul.

Formats de sortie et bases numériques

La bibliothèque Serial autorise l’affichage dans différentes bases, ce qui aide au diagnostic de registres, masques de bits ou protocoles binaires :

int valeur = 42;
Serial.println(valeur, DEC);  // 42
Serial.println(valeur, HEX);  // 2A
Serial.println(valeur, BIN);  // 101010

Pour des mesures flottantes, le second argument indique le nombre de décimales affichées :

float tension = 3.14159;
Serial.println(tension, 3);  // Affiche 3.142

Serial.available, Serial.read : interaction et tests manuels

Le Serial Monitor ne sert pas uniquement à afficher. Il permet également d’envoyer des commandes à la carte pour tester un comportement précis.

void loop() {
  if (Serial.available() > 0) {
    char cmd = Serial.read();
    if (cmd == 'a') {
      Serial.println("Commande A recue");
    } else if (cmd == 'b') {
      Serial.println("Commande B recue");
    }
  }
}

Avec cette approche, vous déclenchez une action en tapant simplement une lettre ou un mot dans le Serial Monitor. Le débogage devient interactif, pratique pour tester une séquence sans reprogrammer la carte à chaque variation.

Tableau récapitulatif des fonctions Serial utiles

Résoudre les problèmes fréquents du Serial Monitor

Moniteur série vide : rien ne s’affiche

Un moniteur série vide alors que le code est téléversé représente un cas classique. Plusieurs causes récurrentes existent :

• Absence de Serial.begin() dans setup().
• Erreur de port COM sélectionné dans l’IDE.
• Carte bloquée dans une condition d’erreur ou un while infini avant le premier Serial.print.
• Serial Monitor ouvert après l’exécution du setup(), ce qui fait perdre les messages de démarrage.

Un autre cas identifié : le développeur place ses Serial.print() uniquement dans setup(). Pendant le téléversement et le reset automatique, l’IDE rouvre le port série, et les messages très précoces ne s’affichent pas. La sortie semble vide alors que les instructions se sont exécutées trop tôt.

Une stratégie simple consiste à déplacer les premiers logs dans loop() avec une condition d’initialisation ou à insérer un délai juste après Serial.begin() pour laisser au moniteur le temps de se connecter.

« Mon moniteur série restait noir après chaque téléversement. Le problème venait de mes Serial.print uniquement dans setup(). En ajoutant un délai et quelques logs dans loop(), tous les messages critiques sont enfin apparus. »

Caractères illisibles : problème de baud rate

Des caractères bizarres, des glyphes aléatoires ou une suite de symboles incompréhensibles pointent presque toujours vers un baud rate désynchronisé. Le code et le Serial Monitor ne parlent plus à la même vitesse. Le microcontrôleur envoie des bits à une cadence, l’IDE en attend une autre ; l’interprétation s’effondre.

La solution repose sur une règle stricte : la valeur passée à Serial.begin() doit être identique à la vitesse choisie en bas du Moniteur série. Ce point figure parmi les problèmes majeurs répertoriés lors de l’utilisation du Serial Monitor.

En cas de doute, repassez temporairement en 9600 bauds, qui reste une référence stable. Une fois la liaison validée, remontez la vitesse si nécessaire pour des flux plus denses.

Conflit avec un écran OLED ou un bus I2C

Sur certains montages, l’utilisation simultanée du Serial Monitor et d’un écran OLED sur bus I2C induit un décalage de mesure. Un exemple concret mentionne un offset de 23 W lorsqu’un écran I2C et le Moniteur série affichent en même temps des valeurs de puissance.

Plusieurs facteurs entrent en jeu : temps de rafraîchissement de l’écran, surcharge de la boucle principale, latence d’affichage et gestion des interruptions. Le processeur consacre des cycles au rendu graphique et au flux série, ce qui décale le moment précis de l’acquisition ou modifie le timing d’un calcul.

Pour diagnostiquer ce type de dérive :

• Désactivez temporairement les mises à jour OLED et observez la mesure uniquement dans le Serial Monitor.
• Comparez les valeurs obtenues avec et sans logs série.
• Ajustez la fréquence de rafraîchissement de l’écran ou regroupez les opérations d’affichage dans une routine de mise à jour moins fréquente.

Méthodes structurées pour débugger un code Arduino avec le Serial Monitor

Tester chaque fonction individuellement

Une approche méthodique consiste à isoler chaque fonction ou module. Le Serial Monitor devient alors le témoin d’entrée et de sortie :

• Affichez les paramètres reçus par la fonction.
• Affichez les valeurs intermédiaires clés.
• Affichez le résultat final avant le retour.

Exemple :

int calculePuissance(int tension, int courant) {
  Serial.print("[calculePuissance] U=");
  Serial.print(tension);
  Serial.print(" I=");
  Serial.println(courant);

  int puissance = tension * courant;
  Serial.print("[calculePuissance] P=");
  Serial.println(puissance);

  return puissance;
}

Cette granularité évite de chercher à l’aveugle. Chaque appel produit un log clair, qui guide vers la portion fautive.

Élimination progressive : commenter sections par sections

Face à un comportement incompréhensible, la technique d’élimination progressive reste efficace. L’idée : commenter temporairement des blocs de code pour réduire la zone suspecte.

• Commencez par commenter les parties non critiques (affichages, animations, fonctions secondaires).
• Ajoutez des Serial.println() aux frontières entre sections.
• Rétablissez les blocs un à un, en observant le point exact où le bug réapparaît.

Le Serial Monitor fournit alors une chronologie d’exécution : vous voyez que le programme atteint telle section, puis se bloque avant la suivante. Le diagnostic se resserre naturellement.

Stratégie de logs dans la boucle loop()

Inonder la boucle loop() de logs série dégrade la lisibilité et perturbe parfois le timing. Une stratégie plus structurée consiste à :

• Définir un niveau de log (par exemple via une constante DEBUG_LEVEL).
• Limiter la fréquence d’affichage (toutes les X millisecondes).
• Regrouper les informations clés dans un message synthétique.

const bool DEBUG = true;
unsigned long dernierLog = 0;

void loop() {
  unsigned long maintenant = millis();
  // ... votre logique principale ...

  if (DEBUG && (maintenant - dernierLog >= 500)) {
    dernierLog = maintenant;
    Serial.print("t="); Serial.print(maintenant);
    Serial.print(" ms, capteur="); Serial.println(lireCapteur());
  }
}

Ce rythme stabilisé évite de saturer la fenêtre du moniteur et reste suffisant pour analyser l’évolution d’une variable dans le temps.

Impact mémoire et performance du débogage série

Poids du code de débogage dans le binaire

Chaque message de débogage occupe de la mémoire programme (flash). Ajouter de longues chaînes de caractères et de nombreux appels Serial.print augmente la taille du binaire, ce qui pose des limites sur des cartes à faible capacité comme l’UNO.

Un exemple concret montre une réduction nette après désactivation du débogage : de 7318 bytes à 6398 bytes, soit une diminution de 920 bytes, environ 12,6 %. Ce différentiel illustre l’effet d’un bloc de logs importants sur la taille finale du programme.

Sur un projet déjà dense en bibliothèques (OLED, WiFi, capteurs divers), chaque kilooctet compte. Mettre en place un mécanisme simple pour activer ou désactiver le débogage devient alors très utile.

Activer / désactiver proprement les traces de debug

Une méthode consiste à utiliser des macros ou des constantes de compilation :

#define DEBUG_SERIAL 1

#if DEBUG_SERIAL
  #define DEBUG_PRINT(x)   Serial.print(x)
  #define DEBUG_PRINTLN(x) Serial.println(x)
#else
  #define DEBUG_PRINT(x)
  #define DEBUG_PRINTLN(x)
#endif

void setup() {
  #if DEBUG_SERIAL
    Serial.begin(115200);
    DEBUG_PRINTLN("Debug actif");
  #endif
}

Dans le reste du code, vous remplacez les appels directs à Serial.print par DEBUG_PRINT. En changeant une seule valeur, vous compilez une version avec ou sans logs, tout en conservant une base de code propre.

Combiner Serial Monitor et autres outils de développement Arduino

Lien avec le premier programme Arduino

Lors de vos premiers pas avec Arduino, l’exemple Blink se contente de faire clignoter une LED. En intégrant le Serial Monitor dès ce stade, vous apprenez à suivre l’exécution temporelle et les délais.

Un tutoriel détaillé sur la structure de base d’un sketch, les fonctions setup() et loop(), ainsi que la logique de téléversement se trouve dans la ressource :
/arduino-premier-programme/. En y ajoutant des logs série, vous posez immédiatement un socle solide pour vos futurs débogages.

Serial Monitor et communication série avancée

Quand un projet évolue vers des échanges complexes entre plusieurs cartes, un PC ou des modules série (GPS, Bluetooth, capteurs industriels), la compréhension fine de la communication série devient stratégique. Le Moniteur série sert alors autant à analyser qu’à simuler un équipement distant.

Pour approfondir toute la mécanique des ports série, de la configuration des vitesses, des protocoles et des buffers, référez-vous à :
/arduino-serial-communication/. Les concepts abordés se combinent directement avec les techniques de débogage via le Serial Monitor détaillées ici.

Diagnostic d’erreurs avec l’IDE Arduino

Le Serial Monitor ne remplace pas les messages d’erreur de compilation ou les alertes de l’IDE. Une bonne habitude consiste à croiser :

• Les erreurs de compilation et d’upload fournies par l’IDE.
• Les logs d’exécution en temps réel envoyés au Moniteur série.

Lorsque le code compile mais ne se comporte pas comme prévu, le Moniteur série prend le relais. À l’inverse, quand l’IDE signale une erreur lors du téléversement ou une configuration de carte incorrecte, le problème se situe en amont, avant même l’exécution.

Pour un tour d’horizon des outils de diagnostic fournis par l’IDE, y compris les options de verbosité, les messages détaillés de compilation et les paramètres avancés, consultez :
/arduino-debug-ide/. La combinaison de ces fonctions avec des logs série structurés renforce nettement la qualité de votre démarche de débogage.

Cas pratiques : scénarios de débogage typiques avec le Serial Monitor

Capteur qui renvoie des mesures incohérentes

Face à un capteur qui renvoie des valeurs aberrantes, le Serial Monitor sert de banc de test minimal :

• Affichez la valeur brute lue sur l’entrée analogique ou numérique.
• Affichez la valeur convertie après votre formule (par exemple tension, température, distance).
• Affichez la valeur attendue de référence (mesurée avec un multimètre ou issue de la datasheet).

Cette triple trace aide à repérer une erreur de conversion, une mauvaise référence de tension, un câblage inversé ou une surcharge du bus de données.

Programme qui semble bloqué ou figé

Lorsque la carte semble bloquée, sans réaction apparente, quelques lignes de logs série suffisent à localiser la zone de blocage :

Serial.println("Point A");
// ... bloc de code ...
Serial.println("Point B");
// ... autre bloc ...
Serial.println("Point C");

Si le moniteur affiche « Point A » mais jamais « Point B », la section entre ces deux traces contient la cause : boucle infinie, attente bloquante, appel de fonction qui ne retourne jamais, accès matériel non disponible.

Interactions complexes avec plusieurs périphériques

Dans un système intégrant plusieurs périphériques (OLED I2C, capteurs analogiques, communication série externe), les interactions deviennent plus délicates. Le Serial Monitor aide à tracer chaque étape :

• Initialisation des périphériques un par un.
• Ordre de lecture des capteurs.
• Moment exact des mises à jour d’affichage.

En étiquetant clairement vos logs ([I2C], [SENSOR], [OLED], [SERIAL]), vous obtenez une chronologie d’exécution utile pour repérer un conflit de timing, un appel trop fréquent ou un périphérique qui ralentit toute la boucle.

« Après avoir ajouté des tags dans chaque message de debug, j’ai vu que mon affichage OLED monopolisait la boucle principale. En espaçant les rafraîchissements et en allégeant les logs série, le système a retrouvé un comportement stable et des mesures cohérentes. »

Bonnes pratiques générales pour un débogage efficace avec le Serial Monitor

Structurer les messages de log

Un log utile possède plusieurs éléments :

• Un préfixe clair ([INIT], [ERROR], [INFO]).
• L’instant de l’événement (millis() ou un compteur).
• Les valeurs réellement utiles au diagnostic.

Exemple :

Serial.print("[INFO]");
Serial.print(millis());
Serial.print("ms capteur=");
Serial.println(valeurCapteur);

Cette rigueur de format vous évite de perdre du temps à interpréter un flux de messages hétérogènes.

Nettoyer le code avant mise en production

Conserver un grand volume de logs série dans un code destiné à un usage final rend le comportement moins prévisible, surtout en temps réel. Une fois le problème résolu, plusieurs actions sont recommandées :

• Supprimer les messages temporaires purement exploratoires.
• Conserver uniquement quelques logs de diagnostic pertinents.
• Désactiver les traces via un drapeau de compilation pour la version « release ».

Cette démarche garde un code plus lisible, réduit la taille binaire et limite l’impact sur les performances tout en préservant une base de débogage réactivable en cas de besoin futur.