Le deep sleep (sommeil profond) est un mode de basse consommation d’un microcontrôleur : le cœur, les horloges rapides et la plupart des périphériques sont coupés, ne laissant qu’une consommation résiduelle de quelques microampères, jusqu’à un réveil déclenché par une minuterie ou un événement extérieur. Ce réveil est, mécaniquement, une interruption.
À quoi ça sert ?
C’est le levier décisif pour un objet sur pile ou batterie, et c’est un levier énorme, parce que trois ordres de grandeur séparent les deux états : un ESP32 actif en Wi-Fi tire 80 à 240 mA, le même en deep sleep descend autour de 10 µA. Un rapport de l’ordre de 10 000. Alterner de brèves phases actives et de longues phases de sommeil ne « grappille » donc pas de l’autonomie : il la change de catégorie, de l’ordre du jour à l’ordre de l’année sur la même pile (calcul dans l’exemple plus bas).
C’est ce qui explique son association naturelle avec les liaisons sobres comme le BLE ou le LoRa : l’objet dort, se réveille pour mesurer et transmettre, et se rendort. Le budget courant de l’objet se chiffre alors sur la consommation moyenne, pas sur la consommation active (→ notion alimentation-electronique).
Comment ça marche ?
Quatre idées structurent le mécanisme.
- Une gradation de modes, pas un interrupteur. Entre « tout allumé » et « tout éteint », les microcontrôleurs offrent des paliers : la veille légère (light sleep — le cœur s’arrête mais l’état est conservé, réveil quasi instantané), le deep sleep (presque tout est coupé, consommation en µA), et parfois un cran ultime (hibernation) qui coupe encore davantage. Plus le mode est profond, plus la consommation baisse, et plus le réveil coûte cher en temps et en état perdu.
- Un petit domaine reste allumé. En deep sleep, tout n’est pas mort : un îlot ultra-sobre (souvent appelé domaine RTC) garde une horloge lente, le contrôleur de réveil et, sur certaines familles, quelques kilooctets de mémoire RTC qui survivent au sommeil. C’est ce veilleur de nuit qui consomme les fameux microamps, et c’est lui qui rallumera le reste.
- Les sources de réveil s’arment avant de dormir. Deux familles principales : la minuterie (l’horloge lente du domaine RTC arrive à échéance — le cas du capteur périodique, cousin du timer) et l’événement extérieur (un niveau ou un front sur une broche prévue à cet effet — bouton, détecteur). Certaines familles ajoutent des réveils tactiles ou par coprocesseur. Le réveil est une interruption : on configure sa source exactement comme on arme une interruption, puis on appelle la mise en sommeil.
- S’endormir est un acte explicite. Le programme prépare l’état à sauvegarder, arme la source de réveil, puis appelle la fonction de mise en sommeil — et l’exécution s’arrête là.
Le réveil n’est pas une reprise — c’est (souvent) un redémarrage
C’est la surprise du premier essai, et elle dépend de la famille. Sur ESP32, sortir du deep sleep est un reset : le programme repart du début (la fonction d’initialisation s’exécute à nouveau), la RAM est perdue, et seules les données placées explicitement en mémoire RTC survivent. Une fonction dédiée permet de savoir pourquoi on s’est réveillé (minuterie ? broche ?). Sur AVR (Arduino classique), au contraire, le réveil reprend l’exécution à l’instruction qui suit la mise en sommeil, état intact.
La conséquence est architecturale : un programme à deep sleep « façon ESP32 » ne s’écrit pas comme une boucle qui s’endort de temps en temps, mais comme un cycle réveil → identifier la cause → agir → se rendormir, où l’état persistant vit en mémoire RTC ou en stockage, une structuration de firmware à part entière. La mise en œuvre : esp32-deep-sleep côté ESP32, arduino-deep-sleep côté Arduino, micropython-deep-sleep côté MicroPython.
Exemple — La sonde sur pile
Une sonde mesure et transmet 2 secondes toutes les 10 minutes (consommation active ~80 mA), et dort le reste du temps (~10 µA). Sa consommation moyenne vaut :
(80 mA × 2 s + 0,01 mA × 598 s) ÷ 600 s ≈ 0,28 mA
Sur une pile de 2 000 mAh : 2 000 ÷ 0,28 ≈ 7 200 heures, soit environ 10 mois. La même sonde sans veille viderait la pile en 2 000 ÷ 80 = 25 heures, soit un jour. Même cycle, même matériel : seul le sommeil sépare l’objet jetable de l’objet autonome. Et le calcul montre où agir : raccourcir la phase active (regrouper les envois, éviter une reconnexion Wi-Fi à chaque réveil) pèse ici plus lourd que gagner quelques µA de plancher.
Pièges
Mesurer la puce, déployer la carte. Les ~10 µA sont ceux de la puce. Une carte de développement ajoute LED d’alimentation, régulateur linéaire et interface USB qui consomment en permanence. Le plancher réel remonte vers le mA, et l’autonomie s’effondre (avec un plancher de 1 mA, la sonde de l’exemple retombe à ~2 mois). La vraie basse consommation exige une carte conçue pour, ou une puce nue.
Oublier les périphériques externes. Le microcontrôleur dort, mais le capteur, le module radio ou le diviseur de mesure branchés sur le rail continuent de consommer. Il faut couper leur alimentation aussi — broche de commande, transistor — sinon le plancher est dicté par eux.
Croire que le programme reprend où il était. Selon la famille, le réveil est un redémarrage (voir plus haut) : tout état non sauvegardé en mémoire RTC est perdu, et le code écrit comme une simple boucle se comporte étrangement.
Sous-estimer le coût du réveil. Se réveiller n’est pas gratuit : démarrage, stabilisation, et surtout reconnexion réseau (un Wi-Fi se renégocie en secondes, à pleine puissance). Des réveils trop fréquents peuvent consommer plus que de rester éveillé : espacer les cycles et regrouper les transmissions.
Se déboguer dans le noir. Pendant le sommeil, la console série est muette et la carte peut sembler morte. Un cycle de sommeil très court peut même gêner le re-téléversement. En développement : tracer au réveil, garder un cycle long, et prévoir un moyen de forcer la carte éveillée.
Voir aussi
- Interruption — le mécanisme du réveil (la source s’arme comme une interruption)
- Timer — le réveil à échéance, cousin du débordement de timer
- Deep sleep sur ESP32 — la mise en œuvre concrète (mémoire RTC, causes de réveil)
- Deep sleep sur Arduino — les modes de veille AVR en pratique
- Deep sleep en MicroPython — la même mécanique côté MicroPython
- Alimentation électronique — le budget courant que le sommeil transforme
- BLE — liaison basse consommation, complément naturel du deep sleep
- LoRa — capteurs distants sur pile, mêmes contraintes d’autonomie
- Microcontrôleur — le circuit qui propose les modes de veille