Se réveiller des modes de sommeil profond

La plupart des microcontrôleurs (par exemple AVR, MSP430, PIC, etc.) prennent en charge un certain nombre de modes de sommeil différents. Le mode de veille "le plus profond" est celui qui prétend la plus faible consommation d'énergie (par exemple "Power Down", "Shut Down"), mais tous les systèmes d'horloge sont généralement arrêtés dans ces modes et il me semble que le seul moyen de " se réveiller "d'eux est via un stimulus externe (par exemple les interruptions de changement de broche, réinitialisation de la puce). Suis-je en train de manquer quelque chose? Existe-t-il des méthodes de puissance incroyablement faible pour générer un signal de réveil périodique pour un MCU?

En supposant que mon objectif est de minimiser la consommation d'énergie (c'est-à-dire dormir profondément aussi longtemps que possible, rester éveillé aussi brièvement que possible), tout en se réveillant périodiquement pour exécuter une fonction, quelle est la façon la plus courante d'obtenir ce type de comportement? Pour simplifier davantage les choses, supposons que ma fonction est sans état (je n'ai pas besoin de me rappeler quoi que ce soit du passé pour l'exécuter).

J'ai eu un certain succès en utilisant le WDT sur le MSP430 pour obtenir cet effet. Je viens de faire ma routine principale être ma fonction, avec la dernière ligne permettant au temporisateur de chien de garde d'expiration après une certaine période et de passer en LPM4.5 ou quel que soit le mode "sommeil profond". Le résultat net est que la fonction est exécutée, le MCU se met en veille, le WDT expire et la puce se réinitialise, ad nauseum. Semble fonctionner, vous vous demandez simplement s'il existe un moyen "meilleur" ou "plus élégant" ou "plus économe en énergie" pour obtenir ce type de comportement?

Je n'ai pas encore essayé cette approche avec un AVR, mais je pense que le WDT est plus "énergivore" dans les AVR que sur le MSP430, il peut donc être moins attrayant pour un travail à faible puissance. Peut-être n'y a-t-il pas une approche «universelle» de la basse consommation, et vous devez utiliser les outils offerts par une gamme de produits donnée? Je sais que la nouvelle gamme picoPower possède de nombreuses fonctionnalités fantastiques comme le système d'événements et la marche en veille qui, dans certains cas, ne nécessitent pratiquement pas que le processeur soit éveillé si vous pouvez adapter votre application à cette structure ...

Ok assez de mon errance, laisse ici ce que tu vas devoir dire :)

Modifier des exemples concrets illustrant des techniques seraient également cool!

La plupart des micros prennent en charge un oscillateur à cristal de montre de faible puissance de 32,768 kHz avec une sorte d'interruption de mise à l'échelle et de temporisation. Réglez le prescaler de sorte que la minuterie compte lentement et que l'interruption se produise à la période souhaitée.

Certains micros ont également une minuterie RC basse consommation intégrée si le timing exact n'est pas critique.

La fiche technique de tout micro de faible puissance répertorie la puissance avec un oscillateur 32,768 (et rien d'autre) en cours d'exécution. C'est assez proche de zéro. Vous pouvez faire le calcul pour voir si cela est acceptable et le comparer au courant consommé par le chien de garde.

OK, par exemple sur le msp430f2013, regardons la puissance dans la fiche technique.

0,5 μA est presque nul, bien qu'il soit cinq fois le véritable mode OFF.

Pour plus de détails, nous pouvons regarder à l'intérieur de la fiche technique.
Passer de LPM4 (tout éteint) à LPM3 (en faisant fonctionner l'oscillateur) est la différence entre 0,5 μA et 1 μA.

Supposons que la batterie soit CR2032 avec une capacité de 225 mAh. La mise en veille dans LPM4 est d'environ 50 ans et dans LPM3 est d'environ 25 ans. 25 ans est assez long pour de nombreuses applications, car le courant ON (pendant la mesure elle-même) domine la consommation.

Certaines pièces ont des oscillateurs de faible puissance (quelques uA) pour le réveil, et certains PIC ont également du matériel pour permettre à une tension qui monte très lentement sur une broche de se réveiller - cela peut provenir d'un condensateur externe configuré avant de dormir pour charger sur le période de réveil requise.

Les PIC avec RTC peuvent avoir le RTC réglé sur un état d'alarme, donc il réveillera le MCU à un moment donné, avec un cristal externe de 32,768 kHz. Ils consomment ~ 450 nA IIRC en mode RTC + sommeil, mais seulement 20 nA avec RTC désactivé.

Les minuteries de surveillance AVR ne sont pas aussi mauvaises que vous ne le pensez. Selon la fiche technique ATTiny13A, la consommation de courant en mode hors tension à 3 V est de 2 μA sans le WDT activé et de 4 μA avec. Bien sûr, c'est 2x de plus, mais le courant lui-même est assez petit pour environ 6,2 ans de fonctionnement, ce qui correspond à peu près au même temps qu'il faut à la batterie pour se dégrader d'elle-même de toute façon (source: la date de péremption).

De plus, pratiquement tout ce que vous connectez autour du μC attirerait beaucoup plus. En fait, la partie la plus délicate de la conception d'un tel circuit à faible puissance est de couper tout courant dans le reste du schéma pendant la période de sommeil.

Le délai de réveil est également bien configurable, de ~ 12 ms à 8 s, si la mémoire est bonne. La fréquence réelle ne fait aucune différence notable si de courtes routines d'interruption sont utilisées: je me suis débrouillé avec l'allumage de l'ADC, l'échantillonnage d'un pot 1K, le calcul de certaines choses à partir des résultats et le retour au sommeil sans changement notable de la consommation globale ( lissée avec un grand condensateur pour compenser la lenteur de mon multimètre).

Notez que le WDT n'est pas un outil de chronométrage précis, vous pouvez donc vouloir connecter un RTC externe. Ceux-ci peuvent consommer de simples nanoampères, donc cela devrait être un bon appariement. En fait, si le RTC en question peut générer des impulsions régulières, vous pouvez l'utiliser comme source de réveil au lieu du WDT au prix d'utiliser une broche.