Quels facteurs prendre en compte lors de la sélection d'un microcontrôleur Wi-Fi intégré pour un appareil périphérique de faible puissance?

La motivation de cette question vient du fait qu'il y a quelque temps, j'ai créé un périphérique de périphérie IdO (PoC) simple à l'aide d'un microcontrôleur et d'un processeur réseau Wifi CC3100 . L'un des problèmes de ce prototype était que la configuration nécessitait une puissance considérable. Ainsi, il ne pouvait pas surmonter les avantages du dispositif existant de faible puissance qui pouvait durer plus de 2 à 10 ans selon le choix de la batterie et la fréquence d'utilisation.

Selon l'application, le produit actuel utilise une batterie 6V DC d'une capacité comprise entre 1400 mAh et 2400 mAh. Le dispositif possède un élément de détection de faible puissance et un mécanisme d'actionnement. La charge utile sera probablement d'environ 100 octets. La fréquence de communication sera d'environ toutes les deux minutes pendant l'activité maximale. Avec les progrès de l'IoT et les demandes du marché, ce PoC a gagné une certaine attention.

Selon la suggestion de quelques fournisseurs de plates-formes IOT, je regarde le microcontrôleur sans fil CC3200 de Texas Instrument, principalement parce qu'il est le successeur du CC3100. Au niveau du système, lorsqu'elle n'est pas utilisée, l'alimentation du CC3100 peut être complètement coupée. Il s'agit d'un avantage significatif pour une faible puissance au niveau des systèmes. Lorsqu'une activité est détectée, l'élément de détection réveille le microcontrôleur via une interruption. Il existe d'autres microcontrôleurs wifi intégrés tels que ESP8266 , BCM43362 , ATWINC1500B , 88MC200 et bien d'autres. J'utilise scores ULPBench pour faire une première analyse d'ordre de microcontrôleurs de faible puissance suivie d' une analyse telle que décrite dansComment sélectionner un microcontrôleur pour une application basse consommation? pour aider à sélectionner un microcontrôleur de faible puissance. J'ai utilisé des paramètres tels que la consommation de courant en mode actif par fréquence et la consommation de courant en différents modes de faible puissance pour effectuer une sélection éclairée. Donc, afin de maintenir l'option basse consommation et d'ajouter la capacité IoT, quels sont les paramètres critiques (liés à la communication sans fil) auxquels je dois prêter une attention particulière lors de la sélection d'un microcontrôleur wifi intégré?

Les références:

• Gestion de l'alimentation du sous-système de réseau Internet sur puce Wi-Fi SimpleLink ™ CC3100 / CC3200
• Comment sélectionner votre module Wi-Fi?

Comme votre contrainte la plus importante est d'avoir une faible consommation d'énergie, je pense que vous faites déjà attention aux 2 paramètres les plus importants: la consommation de courant en mode actif par fréquence et la consommation de courant aux différents modes de faible puissance.

En maintenant la communication constante (c'est-à-dire le même protocole de communication et la même fréquence EM), puis en choisissant le meilleur MCU, il suffit d'agréger correctement ces deux paramètres. Et voici comment je créerais une seule valeur numérique que je pourrais comparer entre toutes les options:

1. Créez un profil d'activité projeté pour l'appareil (à quelle fréquence communique-t-il et pendant combien de temps) sur une période - disons sur une semaine.
2. Calculer le tirage actuel à la fréquence EM utilisée pour les périodes de la période sélectionnée où la communication est active - c'est-à-dire un tirage de 10 uA (à une fréquence de 900 MHz) pour une durée de 2 s à 1000 x activité dans une semaine signifierait 20 000 uA-s / la semaine.
3. Calculer le tirage actuel pour les durées de la période sélectionnée lorsque l'appareil est en mode basse consommation par défaut - c'est-à-dire un tirage de 10 nA à [7 jours x 24 h x 60 min x 60 s - 1000 x 2 s d'activité] signifierait 6 028 uA -s / semaine.
4. L'ajout des 2 donne 26 028 uA-s / semaine de tirage actuel pour cette hypothétique MCU.
5. Ce tirage hebdomadaire actuel calculé peut ensuite être comparé pour tous les MCU.

Je sais que c'est une façon très simpliste de voir l'activité MCU - c'est-à-dire que l'on considère seulement 2 états: inactif et communicant ... mais je crois que tous les autres états auront des contributions proportionnelles et mineures à l'un de ces 2. Par exemple, la puissance consommée pour les calculs (cycles d'instruction) peuvent être regroupés avec l'état de communication et auront très probablement une très faible contribution en termes de puissance par rapport au sous-système de communication. Le fait est que regarder ces 2 états est suffisant pour le processus de sélection.

Il n'y a pas de solution miracle, donc je pense que le conseil sera douloureusement évident. Commencez par réduire les plus gros consommateurs d'énergie en premier.

Etes-vous vraiment hors tension toutes les puces et circuits quand il est inactif? Je sais que certaines des planches et des boucliers amateurs ne désactivent pas toujours complètement tout ce que vous attendez.

Si c'est l'actionneur, pouvez-vous utiliser un moteur plus léger ou réduire la friction dans la transmission? Plus grande image, pouvez-vous réorganiser la charge entraînée pour avoir moins de masse ou pour être mieux équilibrée?

Si c'est la communication, commencez par regarder la fréquence des communications. Quels facteurs ont motivé la décision "deux minutes" existante? Pouvez-vous faire des sacrifices pour communiquer moins souvent? Pouvez-vous passer à un modèle pub-sub et répondre avec moins d'octets lorsque les conditions le permettent?

Réévaluez le protocole. Chaque octet que vous rasez représente une économie de 1% de votre budget actuel de puissance RF. Envoi de valeurs booléennes? Utilisez des indicateurs de bits, pas un «Y» ou «N» ASCII. Assurez-vous que vous utilisez le plus petit conteneur possible - ne transmettez pas un entier de 16 bits si le nombre a une plage autorisée de seulement 0-99. La plupart des protocoles alimentés par batterie essaient de le comprimer autant que possible; Par exemple, si vous faites un rapport sur un tableau d'éléments 5x5, l'adresse doit uniquement être un champ de 5 bits, pas un octet de 8 bits. L'utilisation de cycles CPU pour une logique liée à la compression entraîne une consommation d'énergie globale beaucoup plus faible que la transmission de bits inutiles.

Si le gros tirage est le CPU (douteux, mais possible), pouvez-vous faire des astuces comme des tables de recherche précalculées, ou même décharger une partie du travail sur un service distant?

Il n'y a pas un seul ensemble définitif de paramètres que vous pouvez utiliser pour sélectionner un appareil intégré comme celui-ci, mais je pense qu'en première approximation, les appareils nouvellement conçus pourraient être nettement meilleurs que quelque chose d'il y a quelques années. Bien que le concept ne soit pas nouveau, ce niveau d'intégration et les objectifs de puissance agressive en font un marché en évolution.

Portez une attention particulière aux états de puissance proposés, vus du point de vue de l'ensemble de votre système (régulateurs, oscillateurs, conditionnement du signal des capteurs). Il est possible (peu probable) que votre état actif de 2 minutes bénéficie d'un sommeil moins profond que l'état de fonctionnement normal.

L'état utile le plus faible devrait représenter la majorité de votre consommation d'énergie. La façon exacte dont cela se déroule pour vous dépend de choses comme si vous pouvez fonctionner directement hors tension sans régulateur, tension de fonctionnement minimale, etc.

Pour l'état actif, tenez compte de la plupart de vos opérations RAM ou de calcul intensif et comparez-les en utilisant les pièces standard équivalentes les plus proches que vous pouvez trouver (en fonction de l'architecture du processeur, de la vitesse et de la mémoire). Dans votre application, il semble que la préparation de la charge utile et du chiffrement puisse être assez simple, mais en général, ce n'est pas une hypothèse évidente. Les états de rétention peuvent permettre l'intégration du capteur sans enregistrement / restauration d'état par exemple.

Adaptez la vitesse d'horloge et l'architecture aux exigences de votre application. En mode veille, vous économisez de l'énergie de fuite. Des vitesses d'horloge cibles plus faibles pour un périphérique peuvent signifier qu'il doit rester dans un état actif plus longtemps, mais également entraîner une conception qui atteint de meilleures performances de fuite (ainsi qu'une tension de fonctionnement peut-être plus faible).

Vous ne connaîtrez pas le meilleur design absolu tant que vous n'aurez pas répété plus d'un design - il y a juste trop de paramètres (et à ce moment-là, votre produit commencera à vieillir), donc les aspects de niveau supérieur du flux de conception sont toujours important. Si vous pouvez optimiser votre architecture pour réduire les événements de réveil de 5%, cela devrait être perceptible dans la durée de vie de la batterie.