Programmer sur Arduino sans bloquer la moindre instruction avec delay() change complètement la façon de concevoir un projet. La fonction millis() ouvre la porte à des programmes réactifs, capables de gérer plusieurs tâches en parallèle, du simple clignotement de LED à la domotique multi-capteurs.
Encore faut-il comprendre comment structurer son code autour d’un chronomètre interne, anticiper le débordement au bout de 49 jours et éviter les pièges classiques. La suite pose les bases, décortique les schémas types et montre comment aller plus loin que le simple « blink ».
| Point clé | Synthèse |
| Rôle de millis() | Permet de suivre le temps écoulé sans bloquer l’exécution du code ⏱️. |
| Pourquoi éviter delay() | delay() stoppe tout le programme, empêchant les actions simultanées. |
| Principe d’utilisation | Comparer le temps actuel à un temps sauvegardé pour déclencher une action. |
| Avantages | Gestion fluide de plusieurs tâches, meilleure réactivité, code non bloquant. |
Comprendre millis() sur Arduino : principe, fonctionnement et limites
La fonction millis() renvoie le nombre de millisecondes écoulées depuis le démarrage du programme Arduino. Elle repose sur le timer0, un timer matériel qui s’incrémente en arrière-plan toutes les ~1,024 ms, sans interrompre le reste du code. Cette valeur est stockée dans un entier non signé sur 32 bits (unsigned long).
À chaque appel, millis() donne une sorte d’horloge interne continue. Contrairement à delay(), l’exécution ne s’arrête jamais. La boucle loop() reste active, les capteurs continuent d’être lus, les moteurs restent pilotables et l’interface utilisateur conserve sa réactivité.
Caractéristiques techniques de millis() et débordement après 49 jours
La valeur renvoyée par millis() augmente en permanence jusqu’à atteindre la limite de stockage du type unsigned long. Cette limite correspond à 4 294 967 296 millisecondes, soit environ 49 jours, 17 heures, 2 minutes, 47 secondes et 296 millisecondes.
Au-delà de ce délai, la valeur repart à zéro : on parle de débordement (overflow). Ce comportement ne signifie pas que l’Arduino s’arrête, seule la variable interne utilisée par millis() revient au point de départ. Un code bien structuré continue à fonctionner correctement, même après ce basculement.
| Durée mesurée | Unités | Commentaire technique |
|---|---|---|
| < 1 seconde | 0 à 999 ms | Idéal pour les boucles rapides, lecture de boutons, anti-rebond logiciel. |
| 1 seconde à 1 heure | 1 000 ms à 3 600 000 ms | Clignotements, rafraîchissement d’affichages, mesures périodiques. |
| 1 heure à plusieurs jours | 3 600 000 ms à < 4 294 967 296 ms | Horloges approximatives, tâches de maintenance, logs réguliers. |
| Au-delà de 49 jours | > 4 294 967 296 ms | Débordement, gestion obligatoire avec soustraction sur unsigned long. |
Des utilisateurs ont rapporté des écarts de précision sur plusieurs minutes avec un Arduino Nano, liés à la fréquence réelle du quartz et au fonctionnement du timer0. Ces dérives restent généralement faibles pour les usages standards mais deviennent sensibles sur des systèmes d’horlogerie sans quartz spécifique ou sans RTC externe.
« Sur une période de quelques minutes, l’écart de
millis()reste tolérable pour la plupart des projets. Pour de l’horodatage précis sur plusieurs heures ou jours, une horloge temps réel reste préférable. »
millis() jusqu’en 2020. Pour des retours très récents, les discussions de forums Arduino et les repositories GitHub de librairies temps réel restent des ressources à exploiter.
Pourquoi éviter delay() et passer à millis() sur Arduino
La fonction delay() reste simple à comprendre : elle interrompt le programme pendant une durée donnée. Pendant ce temps, aucune autre instruction de la boucle principale ne s’exécute. Cette approche convient pour un test rapide, mais devient vite problématique dans un système qui doit réagir aux événements externes.
À l’inverse, millis() permet un fonctionnement non bloquant. Le code continue de tourner, les entrées restent écoutées et les sorties restent pilotables pendant que le temps s’écoule. La structure du programme change, mais l’architecture globale gagne en souplesse et en réactivité.
Blocage complet du programme avec delay()
Une portion de code utilisant delay() fige littéralement l’exécution. Aucun autre traitement périodique ou événement ne se produit pendant la pause. Sur un montage simple avec une seule LED, la gêne paraît faible. Sur un système avec plusieurs capteurs, des moteurs et une interface utilisateur, ce blocage devient très visible.
Un cas fréquent concerne l’utilisateur qui souhaite créer une pause de 5 secondes sans bloquer le reste du programme. En utilisant delay(5000), toute la logique applicative se retrouve suspendue, ce qui interrompt la lecture des boutons, la communication série ou la gestion des relais.
- Aucun rafraîchissement d’écran ou d’afficheur pendant la pause.
- Perte d’appuis de boutons rapides non lus à temps.
- Réaction tardive aux capteurs de sécurité ou de fin de course.
- Réactivité médiocre sur des actions utilisateur rapprochées.
« L’utilisation massive de
delay()conduit souvent à un projet qui semble lent, alors que le microcontrôleur exécute très peu d’instructions pendant ces moments morts. »
Précision et comportement temporel : millis() vs delay()
delay() s’appuie lui aussi sur le timer interne, mais la logique reste bloquante. Dans de nombreux cas pratiques, le temps effectif écoulé s’approche suffisamment de la durée demandée, mais l’inconvénient structurel demeure : la fonction monopolise le flot d’exécution.
millis() adopte une approche différente : il fournit simplement une information de temps. Le programme compare cette valeur à une référence stockée pour décider si un intervalle est écoulé. La précision reste liée au quartz et au timer0, mais la structure non bloquante autorise des boucles très rapides, utiles pour la lecture de boutons plusieurs centaines de fois par seconde.
delay() aux phases de test ou à des pauses très courtes dans des sections réellement isolées. Pour les autres besoins temporels, baser toute la logique sur millis() ou sur des timers plus avancés.
Pour des approches alternatives à delay() (intervalles, temporisations déroulantes, attentes conditionnelles), une lecture complémentaire sur les méthodes sans blocage reste utile : remplacer delay() sur Arduino.
Principe de base : mesurer un intervalle de temps avec millis()
Le schéma général pour utiliser millis() repose sur un triptyque clair : mémoriser l’instant de départ, connaître l’intervalle souhaité et comparer régulièrement l’horloge interne à cette référence. Ce mécanisme remplace directement l’usage de delay() dans un code structuré.
Le principe s’exprime avec une simple soustraction sur des entiers non signés :
unsigned long start = millis();à l’instant de départ.if (millis() - start >= intervalle)pour savoir si l’intervalle est dépassé.- Réinitialiser
startaprès traitement si le cycle doit recommencer.
Pourquoi la soustraction gère aussi le débordement
La clé réside dans la nature du type unsigned long. Lors d’un débordement, la valeur de millis() repart à zéro, mais la soustraction millis() - start sur des entiers non signés respecte l’arithmétique modulaire. La différence reste correcte tant que l’intervalle considéré reste inférieur à la période de débordement (49 jours environ).
Concrètement, même si millis() sature au bout de 4 294 967 295 ms, la comparaison millis() - previousMillis >= interval continue à fonctionner, car les bits se réorganisent de manière cohérente pour exprimer la durée écoulée dans ce cadre modulaire.
« Un code bien écrit avec
unsigned longet une soustraction reste robuste même après plusieurs débordements successifs. La clé consiste à ne jamais comparer directement deux valeursmillis()avec un opérateur < ou > sans passer par une différence. »
Schéma type d’un code non bloquant avec millis()
Voici la logique générique intégrée dans la boucle principale :
- Lecture immédiate de l’horloge :
unsigned long currentMillis = millis(); - Pour chaque tâche, comparaison séparée avec son propre
previousMilliset son intervalle dédié. - Exécution de la tâche concernée uniquement lorsque l’intervalle est écoulé.
Ce modèle simplifie la gestion de plusieurs temporisations indépendantes. Une LED peut clignoter toutes les 250 ms pendant qu’un capteur de température se lit toutes les 5 secondes et qu’une requête réseau part toutes les 10 secondes, le tout sans immobiliser le programme.
unsigned long currentMillis = millis(); tout en haut de loop() et réutiliser cette variable pour toutes les tâches limite les appels répétitifs à millis() et rend les comportements temporels plus cohérents.
Structure de programme : du code bloquant au code orienté événements
Passer de delay() à millis() conduit à une autre façon de raisonner. Le programme ne s’enchaîne plus comme un script linéaire, mais comme un ensemble de tâches qui réagissent à des conditions temporelles ou à des événements. Cette approche se rapproche d’une machine à états ou d’un système orienté événements.
Chaque fonctionnalité (lecture de capteur, mise à jour d’affichage, communication série, contrôle de LED) devient une sorte de module autonome, interrogé très souvent, qui exécute son action uniquement lorsque le moment opportun est atteint.
Organisation typique d’une boucle loop() avec millis()
Une boucle loop() structurée autour de millis() suit généralement cette organisation en couches :
- Lecture de l’horloge interne (currentMillis).
- Lecture des entrées utilisateur (boutons, potentiomètres, capteurs).
- Mise à jour des états internes (états de machines, variables, modes de fonctionnement).
- Vérification des temporisations pour chaque tâche temporelle.
- Écriture sur les sorties (LED, moteurs, relais, écrans).
Cette architecture produit un code plus modulaire. Chaque section se concentre sur une responsabilité claire, ce qui facilite la maintenance et l’extension du projet. Ajouter une nouvelle fonctionnalité revient à créer un bloc de logique supplémentaire utilisant son propre previousMillis et son propre intervalle.
Machine à états et gestion séquentielle non bloquante
Pour des scénarios plus complexes, une machine à états améliore encore la lisibilité. Le programme se trouve dans un état particulier (par exemple ETAT_ATTENTE, ETAT_MESURE, ETAT_AFFICHAGE), et la logique transite d’un état à l’autre en fonction du temps et des événements.
Chaque état utilise millis() pour savoir depuis combien de temps il est actif et si la transition vers l’état suivant doit s’effectuer. Ainsi, un cycle de mesure, affichage et repos se conçoit sans aucune instruction bloquante.
Pour bien poser ces bases dans vos premiers croquis, un rappel sur la structure initiale d’un programme reste utile : écrire son premier programme Arduino.
Cas d’usage concrets de millis() en projet Arduino
Les applications pratiques de millis() couvrent la plupart des scénarios où un Arduino doit gérer plusieurs tâches sans geler la boucle principale. La fonction s’impose dès qu’un système doit réagir simultanément à différentes contraintes temporelles.
Les usages suivants illustrent la diversité des contextes dans lesquels millis() remplace avantageusement delay() et permet une logique concurrente rudimentaire mais efficace.
Domotique multi-capteurs sans blocage
En domotique, un Arduino peut surveiller des capteurs de température, d’humidité, de présence, de lumière et piloter des relais, volets ou éclairages. Utiliser delay() pour espacer les mesures conduirait à des temps morts répétés alors que des changements immédiats peuvent survenir (détection de mouvement, action utilisateur).
Grâce à millis(), chaque capteur dispose de son intervalle de lecture propre. Par exemple, la température s’échantillonne toutes les 5 secondes, la présence toutes les 100 ms et la luminosité toutes les 500 ms. L’Arduino reste disponible pour gérer des événements d’urgence, comme l’ouverture d’une porte ou un seuil de sécurité.
- Lecture régulière de plusieurs capteurs sans arrêter le programme.
- Gestion souple des relais selon différents rythmes.
- Possibilité d’interrompre un cycle long si un capteur de sécurité change d’état.
Robots mobiles : moteurs, capteurs et réactivité
Les robots basés sur Arduino combinent souvent moteurs, capteurs de distance, gyroscopes, encodeurs et parfois une communication sans fil. Une logique bloquée avec delay() nuirait fortement à la capacité du robot à réagir à un obstacle ou à corriger sa trajectoire.
Avec millis(), le robot mesure en permanence ses capteurs, met à jour son modèle interne (position estimée, direction) et ajuste la puissance envoyée aux moteurs. Un simple clignotement d’une LED d’état ou une séquence lumineuse ne doit jamais gêner ces tâches prioritaires.
millis() constitue une base de sécurité logique avant même d’ajouter des capteurs supplémentaires.
Affichages LED multiplexés et animations lumineuses
Les projets avec des matrices de LED, bandeaux adressables ou afficheurs multiplexés exigent un rafraîchissement régulier pour éviter le scintillement et maintenir une luminosité visuelle stable. Une temporisation mal gérée casse ce rythme et rend l’affichage inconfortable.
En utilisant millis(), le rafraîchissement des lignes ou colonnes se fait à haute fréquence, tandis que les animations (clignotements, défilements, transitions) se synchronisent sur des intervalles plus longs. Un afficheur peut donc se mettre à jour toutes les 2 ms, pendant qu’un message scrolle toutes les 100 ms.
Enregistrement de données et datalogging
Les systèmes d’enregistrement de données (dataloggers) mesurent périodiquement des valeurs et les stockent sur une carte SD ou les envoient vers un serveur. Utiliser delay() pour espacer les mesures bloque la possibilité de surveiller d’autres événements, comme une erreur de carte SD ou une alerte de capteur.
Avec millis(), plusieurs intervalles coexistent : un pour la mesure, un autre pour l’écriture sur carte SD, un troisième pour l’envoi réseau. Une anomalie détectée à tout moment reste gérable sans attendre la fin d’une pause bloquante.
Interfaces utilisateur réactives (boutons, menus, encodeurs)
Une interface utilisateur basée sur des boutons, encodeurs rotatifs ou claviers matriciels exige une lecture très fréquente pour éviter la sensation de lenteur. En lisant les entrées plusieurs centaines de fois par seconde, l’Arduino capte même les appuis très rapides.
Avec millis(), la boucle scanne les entrées à chaque passage sans délai. Les temporisations concernent uniquement des actions comme le clignotement d’un curseur, un retour sonore ou un temps d’attente avant validation automatique.
« Une interface fluide repose sur une boucle qui tourne rapidement. Les temporisations se gèrent en arrière-plan avec
millis(), pas avec des pauses forcées dans la logique principale. »
IoT : communications réseau non bloquantes
Les projets IoT combinent souvent capteurs, envoi de données vers une API, réception de commandes et parfois mise à jour de firmware. Les piles réseau introduisent parfois des latences ou attentes internes. Ajouter des delay() par-dessus ces délais internes dégrade encore la réactivité.
Avec millis(), le code vérifie régulièrement si un message doit partir, si une réponse est arrivée ou si un timeout est atteint. Les capteurs ne se retrouvent jamais ignorés trop longtemps, même si la communication réseau s’avère lente ou instable.
Contrôle de multiples LED avec intervalles distincts
Une situation classique en apprentissage consiste à contrôler plusieurs LED avec des périodes différentes. Par exemple : une LED clignote toutes les 200 ms, une autre toutes les 500 ms et une troisième toutes les 1 000 ms. Avec delay(), ce scénario devient compliqué et souvent approximatif.
Avec millis(), chaque LED possède son horloge interne : une variable previousMillis dédiée et un intervalle distinct. Le code vérifie pour chacune si l’intervalle est dépassé, puis change son état indépendamment des autres. La boucle reste fluide et chaque clignotement conserve son rythme.
Gestion avancée du temps : millis(), interruptions et timers matériels
Pour certains besoins, millis() ne suffit plus. Les applications qui nécessitent une précision temporelle fine, une fréquence d’échantillonnage stable ou une réaction immédiate à un événement matériel s’appuient souvent sur les interruptions et les timers matériels configurés manuellement.
Comprendre cette hiérarchie d’outils permet de choisir la bonne solution : delay() pour un test, millis() pour des tâches coopératives, timers et interruptions pour des contraintes plus strictes.
Rappel sur les interruptions Arduino
Une interruption déclenche l’exécution d’une fonction spéciale (ISR) lorsqu’un événement survient : front sur une broche, dépassement d’un timer, réception série, etc. Pendant l’ISR, le flot principal s’interrompt brièvement. Ce mécanisme sert à capter des événements qui ne doivent pas être ratés, même si la boucle principale se trouve occupée par d’autres tâches.
Les timers matériels peuvent également générer des interruptions à une fréquence donnée. Cela permet une horloge très régulière, indépendante des aléas de la boucle loop(). Des librairies tirent parti de ces mécanismes pour produire des signaux PWM personnalisés, des comptages de haute précision ou des protocoles de communication spécifiques.
Pour un tour d’horizon structuré sur ces mécanismes, un approfondissement complémentaire reste utile : guide des interruptions sur Arduino.
Quand préférer un timer matériel ou une interruption à millis()
Dans de nombreux cas, millis() reste suffisant. Toutefois, certains scénarios se prêtent mieux à un timer dédié :
- Besoin d’une fréquence d’échantillonnage très stable pour des signaux audio ou des mesures analogiques sensibles.
- Comptage précis d’impulsions à haute fréquence (encodeurs rapides, capteurs de vitesse).
- Génération de signaux temps réel (protocole particulier, pilotage moteur précis).
Dans ces contextes, la boucle principale pourrait introduire des variations de délai qui perturbent les mesures ou génèrent du jitter. Un timer dédié, configuré pour déclencher une interruption à intervalle régulier, fournit un cadre temporel plus strict.
Pièges fréquents et bonnes pratiques avec millis()
La transition entre un code bloquant et un code basé sur millis() amène souvent les mêmes erreurs. Les corriger tôt évite bien des comportements étranges, notamment lors du débordement après plusieurs dizaines de jours de fonctionnement continu.
Les symptômes incluent des LED qui ne clignotent plus correctement, des tâches qui cessent de s’exécuter ou des durées perçues comme erratiques après un certain temps de marche.
Erreur de type de variable : int au lieu de unsigned long
Un problème répandu vient de l’usage du type int au lieu de unsigned long pour stocker le résultat de millis(). Sur la plupart des cartes Arduino AVR, int occupe 16 bits et sature dès 32 767, ce qui ne représente même pas 33 secondes.
Pour suivre un intervalle de plusieurs minutes ou heures, utiliser systématiquement unsigned long pour les variables temporelles :
unsigned long previousMillis;unsigned long interval;unsigned long currentMillis = millis();
Comparaison directe au lieu de soustraction
Comparer directement deux valeurs de millis() avec > ou < conduit à des erreurs dès le débordement. Par exemple : if (millis() > futureTime) cesse de fonctionner correctement lorsque millis() repasse par zéro.
La bonne pratique consiste à stocker un instant de départ et à utiliser la soustraction : if (millis() - start >= interval). Cette forme préserve la cohérence temporelle, y compris après plusieurs cycles d’overflow.
« Toute logique basée sur
millis()devrait systématiquement reposer sur une soustraction entre le temps actuel et un temps précédent, jamais sur une comparaison directe de deux horodatages. »
Sections de code trop longues dans loop()
Une autre difficulté survient lorsque la boucle loop() contient des traitements très longs. Même sans delay(), une fonction qui dure plusieurs centaines de millisecondes rend l’usage de millis() moins pertinent, car la boucle perd sa fréquence de rafraîchissement rapide.
La solution consiste à fractionner les traitements longs en étapes plus petites, éventuellement orchestrées par une machine à états. Chaque passage dans loop() réalise une petite portion de travail, puis se termine rapidement, ce qui laisse la place aux autres tâches et maintient un contrôle temporel fin.
loop() met plus de quelques millisecondes à s’exécuter, inspecter le code pour isoler les sections coûteuses et les rendre progressives. L’objectif consiste à garder une boucle légère et répétitive.
Manque de tests sur longue durée
Beaucoup de projets fonctionnent correctement pendant quelques minutes ou heures, puis manifestent des dysfonctionnements après plusieurs jours. Sans tests longs, ces problèmes restent invisibles. Dans le cas de millis(), le comportement lors du débordement ne se révèle qu’après plus de 49 jours de fonctionnement continu.
Organiser des tests de longue durée, même sur quelques jours, permet de repérer des variables mal typées, des comparaisons incorrectes ou des surcharges mémoire. Sur des installations domotiques ou IoT destinées à rester actives en continu, ces tests deviennent un passage logique obligatoire.
Stratégies de conception pour un temps maîtrisé sur Arduino
Maîtriser millis() ne se limite pas à savoir l’utiliser, mais aussi à concevoir une architecture adaptée. Une poignée de stratégies aide à garder un code clair, extensible et stable dans le temps.
En combinant variables globales bien nommées, fonctions dédiées par fonctionnalité et gestion centralisée des intervalles, le projet reste lisible, même lorsque les tâches temporelles se multiplient.
Centraliser les intervalles et les états
Une bonne approche consiste à définir, en haut du croquis, toutes les constantes d’intervalle et les variables de temps associées. Par exemple :
const unsigned long INTERVAL_LED = 200;const unsigned long INTERVAL_TEMP = 5000;unsigned long previousLedMillis = 0;unsigned long previousTempMillis = 0;
Cette centralisation simplifie l’ajustement des rythmes sans devoir fouiller dans tout le code. La logique dans loop() reste plus lisible, chaque bloc faisant référence à ces constantes clairement identifiées.
Décomposer le projet en fonctions non bloquantes
Plutôt que de concentrer toute la logique dans loop(), chaque fonctionnalité peut être isolée dans une fonction dédiée : gererLed(), gererCapteur(), gererAffichage(), etc. Ces fonctions utilisent currentMillis et leurs propres variables previousMillis, mais ne contiennent aucune instruction bloquante.
La boucle principale se résume alors à un simple enchaînement d’appels de fonctions, ce qui simplifie la lecture et réduit le risque d’oubli :
void loop() {-
unsigned long currentMillis = millis(); -
gererBoutons(currentMillis); -
gererLed(currentMillis); -
gererCapteur(currentMillis); -
gererCommunication(currentMillis); }
Prendre en compte les limites de précision de millis()
Pour des tâches qui s’étalent sur plusieurs heures ou jours, millis() introduit une dérive légère liée au quartz interne et aux arrondis de timer0. Sur des périodes courtes, cette dérive reste souvent négligeable. Sur de longues durées, elle finit par représenter plusieurs secondes d’écart.
Pour un simple arrosage toutes les heures ou une ventilation régulière, la précision de millis() répond déjà à l’objectif. Pour un système qui doit fournir un horodatage exact ou synchroniser des événements avec une heure officielle, un module RTC (Real Time Clock) ou une synchronisation réseau complémentaire se justifient.
«
millis()fournit une base temporelle pratique pour orchestrer les tâches internes d’un microcontrôleur. Pour mesurer le temps absolu au sens humain (heures, minutes du jour, calendrier), une horloge dédiée ou un service réseau devient la référence. »
Vers des projets Arduino plus robustes sans delay()
Remplacer delay() par millis() transforme la façon de concevoir un programme Arduino. Les projets gagnent en réactivité, en fiabilité et en évolutivité, notamment dans les contextes domotiques, robotiques et IoT. En structurant le code autour d’intervalles, de variables unsigned long et d’une boucle rapide, l’Arduino reste constamment à l’écoute de son environnement.
Cette maîtrise du temps ouvre la voie à des architectures plus élaborées : machines à états, tâches coopératives, synchronisation avec des interruptions ou des timers matériels. En combinant ces outils avec un code discipliné et des tests sur la durée, un projet Arduino franchit un cap important vers un comportement stable et prévisible dans des conditions réelles.
