Fabrication industrielle
Internet des objets industriel | Matériaux industriels | Entretien et réparation d'équipement | Programmation industrielle |
home  MfgRobots >> Fabrication industrielle >  >> Industrial Internet of Things >> Embarqué

Jusqu'à quelle puissance pouvez-vous baisser ?

Dans mon dernier article, « Principes fondamentaux du mode basse consommation d'Arm Cortex-M », nous avons exploré les principes fondamentaux des modes basse consommation que l'on peut trouver sur chaque processeur Arm Cortex-M et comment nous pourrions tirer parti des instructions WFI et WFE pour mettre un processeur dormir. La question qui demeure cependant est de savoir comment ces modes basse consommation sont implémentés sur un vrai microcontrôleur et comment ces modes affectent-ils notre système embarqué ? Dans cet article, nous allons explorer plus en détail comment mettre un microcontrôleur en veille et voir combien d'énergie cela nous achète.

Expérimentation du mode basse consommation

La meilleure façon d'explorer les modes basse consommation est de sélectionner un microcontrôleur et d'exécuter le processeur dans divers modes basse consommation. Pour cet article, j'ai décidé de dépoussiérer ma carte éprouvée NXP Kinetis-L Freedom que j'ai non seulement expérimentée, mais que j'ai utilisée dans de nombreux produits, applications et cours. J'ai également décidé, à tort ou à raison, de mesurer non seulement la quantité d'énergie que le microcontrôleur puisait, mais l'ensemble de la carte de développement. Le MCU est généralement l'un des appareils les plus énergivores d'une carte, mais j'ai souvent constaté que mesurer l'ensemble du courant du système me rappelle qu'il n'est pas le seul consommateur d'énergie sur la carte. L'optimisation du microcontrôleur peut vous prendre beaucoup de temps, mais ce n'est pas toujours le seul appareil qui peut nécessiter une optimisation énergétique.

Commencez par une mesure de référence

Chaque fois que je travaille sur l'optimisation de la consommation d'énergie d'un produit, je commence d'abord par prendre une mesure d'énergie de base. Cela se fait normalement en profilant la consommation actuelle de l'appareil sur plusieurs secondes ou minutes pour comprendre où nous commençons. Pour mon expérience sur la carte de développement, j'ai laissé le Kinetis-L en mode exécution sans mise en veille, tous les périphériques allumés et j'ai configuré la carte pour activer périodiquement une LED. En utilisant IAR Embedded Workbench avec un débogueur I-Jet et l'I-Scope, j'ai pu profiler une ligne de base simple pour ma carte ~ 16,9 mA lorsque la LED était éteinte et ~ 18,0 mA lorsque la LED était allumée, ce qui peut être vu ci-dessous dans Figure 1. Comme vous pouvez le voir, il est important de noter d'où vous prenez votre mesure, sinon vous pouvez vous tromper considérablement dans votre analyse.

cliquez pour agrandir l'image

Figure 1. Une mesure de courant de la carte de développement avec une LED qui bascule une fois par seconde. (Source :auteur)

Optimisation de l'énergie avec les modes d'attente et de veille prolongée

Le moyen le plus rapide de réaliser des économies d'énergie est de mettre en œuvre le mode d'attente ou de veille profonde. Un examen de la fiche technique des processeurs Kinetis-L montre que le mode d'attente consomme entre 3,7 et 5,0 mA à 3 volts. Dans ce mode, les horloges du processeur et des périphériques sont désactivées, mais la mémoire flash est en mode veille, ce qui permet au processeur de toujours se réveiller dans un délai d'interruption (12 à 15 cycles d'horloge). Le mode attente est facile à mettre en œuvre, le code pour entrer en mode attente est visible ci-dessous :

void Sleep_Wait(void)
{
      SCB_SCR &=~ SCB_SCR_SLEEPDEEP_MASK;
      asm("WFI");
}

Faites défiler ou faites glisser le coin de la boîte vers développer au besoin.

Avec seulement ces deux lignes de code, la consommation de courant de la carte de développement passe de 18,0 mA à 15,9 mA. Soit une baisse de 11,6 % de la consommation actuelle ! Si la carte était alimentée par une batterie de 680 mA, l'autonomie de l'appareil serait passée de 37,8 heures à 42,8 heures ! Une augmentation de cinq heures à partir de seulement deux lignes de code !

Ce qui est génial avec ces modes de puissance de haut niveau, c'est que nous pouvons facilement aller plus loin. Au lieu de mettre le processeur en mode d'attente, nous pouvons le faire passer en mode d'attente de sommeil profond à l'aide du code suivant :

void Sleep_Deep(void)
{
      SCB_SCR |=SCB_SCR_SLEEPDEEP_MASK;
      asm("WFI");
}

Faites défiler ou faites glisser le coin de la boîte vers développer au besoin.

Tout ce que nous avons fait a été d'ajuster un seul bit dans le registre SCB_SCR et nous sommes maintenant passés d'un courant d'origine de 18 mA à 14,8 mA. Soit une baisse de 17,8% de la consommation actuelle ! Encore une fois, en supposant que la carte était alimentée par une batterie de 680 mA, la durée de vie de la batterie serait maintenant passée de 37,8 heures à 46 heures ! Ce sont de grosses économies pour seulement quelques lignes de code et ce n'est que la pointe de l'iceberg !

Utilisation des modes Stop et VLLS pour la consommation de courant uA

L'utilisation du mode d'arrêt peut réduire davantage la consommation de courant du MCU jusqu'à deux milliampères supplémentaires en désactivant les horloges principales et système. Ce que vous constaterez, c'est que plus le mode d'alimentation est bas, plus il faut de code pour l'implémenter et plus le code devient complexe pour réactiver le système. Le code pour entrer en mode arrêt sur le Kinetis-L est visible ci-dessous :

void Sleep_Stop(void)
{
      volatile unsigned int dummyread =0;
      SMC_PMCTRL &=~ SMC_PMCTRL_STOPM_MASK;
      SMC_PMCTRL ;
      dummyread =SMC_PMCTRL;
      Sleep_Deep();
}

Faites défiler ou faites glisser le coin de la boîte vers développer au besoin.

Notez que le mode d'arrêt est contrôlé via un registre de contrôle de gestion de l'alimentation et une fois l'état défini, la fonction Sleep_Deep est appelée pour terminer la définition du mode d'alimentation et l'exécution de WFI.

Jusqu'à présent, nous avons parlé du MCU tirant 1 - 2 mA. Un microcontrôleur moderne aura des modes d'alimentation pouvant consommer des microampères ou même des nanoampères ! Le processeur Kinetis-L a fait ses débuts vers 2013 et son mode Very Low Leakage Stop (VLLS) ne consomme que 135 à 496 microampères ! Le code pour initialiser ce mode d'alimentation peut être vu ci-dessous :

void Sleep_VLLS1(void)
{
      volatile unsigned int dummyread =0;
      SMC_PMCTRL &=~ SMC_PMCTRL_STOPM_MASK;
       SMC_STOP_MCTRL |=SMC_PMCTRL |=~
      SMC_VLLSTRL =SMC_VLLSCTRL_LLSM(1);
      dummyread =VLLS_CTRL;
      Sleep_Deep();
}

Faites défiler ou faites glisser le coin de la boîte vers développer au besoin.

À ce stade, le microcontrôleur ne consommerait presque plus d'énergie !

L'effet des modes basse consommation sur la latence de réveil

Comme nous l'avons vu jusqu'à présent, déplacer le processeur dans des modes de consommation de plus en plus faible est un excellent moyen d'économiser de l'énergie, mais ces économies ont un coût. Plus l'état énergétique du processeur est bas, plus le processeur a besoin de temps pour se réveiller et effectuer un travail utile. Par exemple, si je devais utiliser le mode d'arrêt standard, il faudrait 2 nous plus la latence d'interruption pour que le processeur se réveille et recommence à exécuter le code. Pas mal. Cependant, si je devais utiliser l'un des modes VLLS sur le Kinetis-L, j'aurais une latence de réveil du démarrage du processeur plus 53 à 115 microsecondes ! Cela peut ne pas être acceptable selon l'application. La figure 2 montre des transitions supplémentaires entre les modes basse consommation et l'état d'exécution sur le Kinetis-L.

cliquez pour agrandir l'image

Figure 2. Temps de transition des modes basse consommation vers les différents modes sur le Kinetis-L. (Source :fiche technique Kinetis-L)

Conclusion

Les microcontrôleurs Arm auront tous les modes basse consommation standard, mais chaque fournisseur de silicium personnalise les modes basse consommation disponibles pour les développeurs. Comme nous l'avons vu, les fournisseurs de silicium proposent souvent plusieurs modes qui agissent comme des fruits à faible pendaison qui ont un effet minimal sur la latence de réveil. Ils fournissent également plusieurs modes à très faible consommation qui éteignent presque le processeur et ne consomment que quelques centaines de microampères ou moins ! Les développeurs doivent souvent trouver un équilibre entre la quantité d'énergie qu'ils souhaitent puiser et la rapidité avec laquelle ils ont besoin que leur système se réveille et réagisse aux événements. Les compromis sont certainement spécifiques à l'application, alors ne vous attendez pas à pouvoir exécuter le mode d'alimentation le plus bas sur chaque produit et application.


Jacob Beningo est un consultant, un conseiller et un éducateur en logiciels embarqués qui travaille actuellement avec des clients dans plus d'une douzaine de pays pour transformer radicalement leurs logiciels, systèmes et processus. N'hésitez pas à le contacter à [email protected], sur son site Internet www.beningo.com, et inscrivez-vous à sa newsletter mensuelle Embedded Bytes.


Embarqué

  1. Comment tirer parti de la surveillance des imprimantes 3D pour faire évoluer la fabrication additive ?
  2. Comment les données IIoT peuvent améliorer la rentabilité de la production au plus juste
  3. Combien de réalités pouvez-vous avoir en automatisation industrielle ?
  4. Comment une panne de courant peut endommager vos alimentations
  5. Causes du faible facteur de puissance
  6. Apprenez à souder le laiton naval
  7. Comment charger un condensateur ?
  8. Comment l'ajustement du PDP peut vous faire économiser de l'argent
  9. Comment renforcer l'hydraulique ?