Comment choisir un nouveau microcontrôleur

En raison de leur faible prix et de leurs capacités étonnantes, les microcontrôleurs se retrouvent dans presque toutes les applications, des énormes systèmes sur puce (SoC) dans les automobiles aux minuscules dispositifs 8 bits dans les capteurs. Une fois que vous avez trouvé une famille de microcontrôleurs qui répond à vos besoins, vous allez probablement vous y tenir aussi longtemps que possible pour tirer le meilleur parti des connaissances acquises sur le processeur, l'environnement de développement et les outils de débogage. Cependant, un jour, un besoin d'application surgira et exigera quelque chose de différent. Nous vous proposons ici une approche pour évaluer rapidement l'offre actuelle de microcontrôleurs modernes !

Besoin d'un microcontrôleur ?

En matière de microcontrôleurs, nous ne manquons pas de choix. Et ce n'est pas surprenant. Le marché mondial étant estimé à plus de 20 milliards de dollars d'ici 2027, la concurrence est forcément très forte. Cette situation est considérée comme positive pour ceux qui recherchent des micros. Elle encourage les fournisseurs à innover leurs produits, offrant une riche palette de dispositifs aux capacités, fonctions et caractéristiques diverses. Cependant, face à l'abondance de choix, comment choisir le meilleur microcontrôleur pour votre application ?

Il est facile de se laisser emporter par les largeurs de mots, les mégahertz et les tailles de mémoire, mais ces paramètres à eux seuls rendent difficile la comparaison de différents produits. En outre, de nombreuses applications ont une caractéristique spécifique qui les définit : une longue durée de vie des piles, une intégration élevée, une sécurité sans faille ou une sécurité fonctionnelle. Il vaut la peine de prendre le temps d'examiner l'ensemble de vos besoins avant de vous lancer dans la recherche du microcontrôleur idéal.

Définissez clairement les besoins de votre usage

La première étape consiste à examiner les cas d'utilisation du produit que vous essayez de fabriquer. Cela couvre des éléments tels que :

• L'interface homme-machine (IHM) : voulez-vous des boutons-poussoirs mécaniques ou une touche capacitive (Figure 1) ; un écran monochrome ou couleur ; un son polyphonique, ou peut-être un simple buzzer ?
• Consommation d'énergie : l'appareil doit-il fonctionner pendant des années avec une pile CR2023, ou doit-il utiliser une alimentation par prise murale ?
• Interfaces : devez-vous être compatible avec les protocoles existants (USB, Ethernet, Modbus, CAN, I²C et SPI) ?
• Entrées et sorties : avez-vous besoin de signaux analogiques et, si oui, quelle est la précision requise ? Combien d'entrées/sorties numériques sont nécessaires ? Des temporisateurs et des compteurs sont-ils nécessaires ?
• Capacité en temps réel : la commande des moteurs sans balais et les alimentations numériques exigent des temps de réponse mesurés en nanosecondes, notamment dans des conditions de court-circuit. Cela peut nécessiter des périphériques dédiés sur votre microcontrôleur.
• Taille : la taille de votre carte sera-t-elle limitée, ce qui restreindra la taille et le type de boîtier de CI utilisé ?
• Fabriquabilité : êtes-vous en mesure de souder les boîtiers proposés, notamment lors du prototypage ?
• Sécurité : Un environnement de programmation sécurisé est-il nécessaire pour manipuler des secrets cryptographiques ?

  L'étape suivante consiste à examiner cette liste afin de déterminer ce qui doit absolument se trouver à l'intérieur du microcontrôleur et ce qui pourrait éventuellement être hors puce. Si votre produit est limité par l'espace, vous allez vouloir un dispositif hautement intégré. Toutefois, supposons que vous ayez de la place sur votre carte ainsi que des contreintes importantes en ce qui concerne le chemin du signal analogique. Dans ce cas, vous serez probablement prêt à envisager un convertisseur analogique-numérique ou numérique-analogique externe.

Le prix du microcontrôleur joue évidemment un rôle dans le choix. Cependant, il faudra le contrebalancer avec le coût des dispositifs externes permettant de mettre en œuvre des fonctions non disponibles sur le microcontrôleur. En outre, le coût du temps de développement peut l'emporter sur les économies réalisées sur le micro s'il devient trop compliqué de mettre en œuvre une fonction déjà intégrée dans celle d'un autre fournisseur.

Combien de bits et de MHz ? Quel cœur de microcontrôleur ?

Il y a une dizaine d'années ou plus, le nombre de bits et le cœur précis faisaient probablement la différence pour une application de microcontrôleur, principalement au niveau de son prix. Toutefois, avec la prolifération des micros ARM à 32 bits, les dispositifs Cortex-M0 bas de gamme sont aussi bon marché que certains microcontrôleurs à 8 bits (Figure 2). Et, bien que les transistors soient de plus en plus petits, les cellules utilisées pour mettre en œuvre la mémoire flash ne se réduisent pas très bien. Ainsi, c'est la taille de la mémoire flash qui détermine souvent le prix de la puce, et non la taille et la complexité du processeur et de ses périphériques.
 

Une méthode pour déterminer si un microcontrôleur peut gérer l'application prévue consiste à créer un projet simple qui exécute les sections de code critiques. Après compilation utilisez le débogueur pour voir combien de mémoire flash et SRAM il requiert. En basculant une broche GPIO pendant l'exécution et en surveillant cette sortie à l'aide d'un oscilloscope ou d'un analyseur logique, il est possible de déterminer le temps d'exécution de certaines sections du code.

Avant de perdre du temps à apprendre un environnement de développement que vous n'avez jamais utilisé, vous pouvez comparer les options de microcontrôleurs potentiels en utilisant les benchmarks CoreMark de l'EEMBC. CoreMark est un ensemble de programmes de test qui fournit des mesures de performance comparables du processeur. Comme les paramètres de configuration peuvent faire une différence, les résultats sont enregistrés avec l'emplacement du code (flash ou SRAM), la version du compilateur utilisée et les options de compilation, ainsi que d'autres informations pertinentes (Figure 3). Les benchmarks ne sont pas parfaits, mais ils aident à établir une liste de présélection.
 

Quelle quantité de mémoire pour les microcontrôleurs ?

La consommation de mémoire dépend entièrement de l'application. Idéalement, tout code existant devrait être compilé pour déterminer la quantité nécessaire. Les besoins en SRAM sont plus difficiles à déterminer car l'utilisation de la pile ne peut être déterminée qu'au moment de l'exécution. Heureusement, les environnements de développement logiciel d'aujourd'hui permettent de le faire rapidement et facilement. Il est également intéressant d'examiner toute la famille du microcontrôleur choisi pour voir si, plus tard, une variante compatible au niveau des broches, avec moins de mémoire flash et de SRAM, pourrait être utilisée au cas où il faudra baisser les coûts.

Les consommateurs d'aujourd'hui s'attendent à pouvoir mettre à jour le logiciel de leurs produits. La plupart des appareils offrent une zone protégée pour un chargeur d'amorçage. Quoi qu'il arrive, ce dernier sera toujours disponible et fournira une méthode pour intégrer un micrologiciel dans l'appareil. Si l’ancienne version du microprogramme doit être conservée comme solution de repli, au cas où la mise à niveau du microprogramme se passerait mal, il faudra peut-être doubler la quantité de mémoire flash pour accueillir jusqu'à deux versions de votre code.

Enfin, la mémoire flash ou mémoire de programme, est déstinée au code et s'use à chaque fois qu'elle est écrite. Elle peut généralement supporter des dizaines de milliers de cycles d'écriture. Si elle est uniquement utilisée pour le code, c'est parfait, mais si elle est utilisée pour stocker des données ou des informations de configuration, l'usure doit être prise en compte. Si les données sont stockées dans une mémoire non volatile, il faut utiliser l'EEPROM interne si disponible, sinon une EEPROM externe (Figure 4). 

Quelle sera la consommation d'énergie de mon MCU ?

Si votre application doit offrir une excellente autonomie, il est essentiel d'examiner en détail la consommation d'énergie et les modes d'économie d'énergie offerts par chaque microcontrôleur. Cela dépend de nombreux facteurs, et chaque fabricant a développé des modes basse consommation astucieux qui permettent d'économiser de l'énergie mais qui ont également un impact sur la fonctionnalité du microcontrôleur. Par exemple, le réveil d'un mode veille peut utiliser un oscillateur à basse fréquence jusqu'à ce que l'oscillateur principal soit stabilisé. Cela ralentit l'exécution du code, ce qui, dans le grand schéma des choses, peut entraîner une consommation d'énergie plus importante que prévu. La sélection d'un mauvais dispositif à ce stade peut entraîner une réduction de 10% ou plus de l'autonomie réelle de la batterie (d'après une expérience amère !).

Encore une fois, la meilleure approche consiste à tester les bases de votre application sur une carte réelle. Cependant, cela est plus facile à dire qu'à faire. De nombreuses cartes de démonstration et kits de développement rendent difficile l'isolation du microcontrôleur des périphériques et puces environnants. La meilleure approche consiste à construire une carte simple avec uniquement le microcontrôleur, des condensateurs de découplage et, si nécessaire, un quartz. La consommation d'énergie étant de l'ordre du nano-ampère, mais atteignant des niveaux de micro et de milliampères lorsqu'elle est active, il est difficile de trouver un dispositif de mesure qui soit précis à l'extrémité inférieure avec une large gamme dynamique. Qoitech s'est spécialisé dans ce domaine avec son Otii Arc. Leur outil de mesure de la puissance peut également simuler la décharge des batteries, ce qui peut être très utile (Figure 5).

Il ne faut pas non plus oublier l'impact de la température, de la fréquence d'horloge et de la tension d'alimentation sur la consommation de courant. Plus la température et la fréquence d'horloge sont élevées, plus la consommation de courant est importante. Cependant, la tension d'alimentation a un impact de puissance deux sur la consommation de courant. Lors du fonctionnement à la tension la plus basse autorisée, la stabilité de l'alimentation doit être soigneusement prise en compte. Si l'on la laisse chuter trop bas, le microcontrôleur risque d'entrer dans un état de brown-out.

Les données techniques marketing de base des fabricants de microcontrôleurs peuvent également être trompeuses. Ceux à faible puissance de Microchip offrent des « courants de sommeil de 9 nA ». Toutefois, un courant aussi faible peut exiger certains compromis dans la conception. Par exemple, le PIC24FJ256GA412 ne conserve pas le contenu de la SRAM dans son mode de veille profonde de 60 nA. Bien que les données critiques du contexte de l'application puissent être stockées dans deux registres (DSGPR0/1), cela signifie toujours que le réveil nécessitera beaucoup de temps d'exécution, et donc de puissance, pour remettre le microcontrôleur dans un état utilisable. Ainsi, le profil énergétique de l'ensemble de l'application doit être soigneusement examiné pour voir si un tel mode basse consommation est utile.

Enfin, l'EEMBC fournit également une famille de benchmarks Ultra Low Power nommée ULPMark. Là encore, lorsque l'on commence à rechercher des micros, il peut être utile de les examiner pour voir par où commencer (Figure 6). 

Quels périphériques ?

Pour des raisons qui avaient un sens il y a plusieurs années, ou parce que certains protocoles de bus étaient des marques déposées d'autres fournisseurs, les périphériques numériques peuvent être un peu confus. La plupart des microcontrôleurs modernes disposent d'une ou plusieurs interfaces UART, I²C et SPI. Cependant, l'I²C peut être appelée Two Wire Interface (TWI) comme un exemple de déviation potentielle. Et, quelle que soit sa dénomination, il se peut qu'elle ne prenne pas en charge les fréquences d'horloge plus élevées de l'I²C, le mode d'adressage à 10 bits, ou qu'elle ne soit pas adaptée aux applications SMBus ou PMBus. Le même risque de variation de fonctionnalité s'applique aux UART et SPI. Comme précédemment, il est préférable de tester plutôt que de supposer que la fonctionnalité souhaitée est disponible.

Les périphériques peuvent également être très exigeants pour le processeur, surtout si une interruption est générée à la réception de chaque octet. Si de nombreux transferts de données sont prévus, il vaut mieux trouver un microcontrôleur doté d'un contrôleur d'accès direct à la mémoire, ou DMA. Ceux-ci peuvent être liés à l'interruption d'un périphérique pour transférer une quantité fixe de données directement de/vers la SRAM de/vers un périphérique. Ce n'est qu'une fois qu'un bloc important de données a été traité que le processeur est interrompu afin qu'il puisse entreprendre tout traitement nécessaire. Le processeur peut également être placé en mode basse consommation sur certains microcontrôleurs pendant que le DMA transfère les données de manière autonome.

Certains microcontrôleurs possèdent des périphériques de contrôle en temps réel hautement spécialisés. Le TMPM375FSDMG de Toshiba est dédié au contrôle vectoriel des moteurs sans balais. Il est doté d'un moteur vectoriel mathématique, d'un bloc de modulation de largeur d'impulsion (MLI) triphasé et d'un CAN qui fonctionnent de manière quasi autonome. Le processeur ne doit intervenir qu'occasionnellement pour gérer les changements de vitesse ou en cas d'erreur.

Les périphériques analogiques sur puce, tels que les CNA, doivent être réalisées dans la même technologie que le reste de la puce. Ce n'est pas toujours la technologie idéale, ce qui signifie que les CAN, les CNA et les comparateurs peuvent ne pas être aussi bons que les alternatives hors puce. Le nombre de bits disponibles dans les convertisseurs analogiques et numériques, ainsi que le taux d'échantillonnage et de mise à jour, peuvent également être limités. Dans de tels cas, un compromis est nécessaire entre les performances souhaitées et d'autres facteurs, tels que l'espace sur la carte, la complexité de la conception et le coût.

Soutien à la conception de microcontrôleurs

Il s'agit d'un vaste sujet, allant des outils et cartes de développement aux bibliothèques logicielles et à l'assistance de fournisseurs tiers. La plupart des fournisseurs de microcontrôleurs proposent également des environnements de développement et des compilateurs. Si ce n'est pas le cas, ils seront probablement pris en charge par IAR, Segger ou d'autres fournisseurs d'outils. Le fournisseur de microcontrôleurs ou des tiers proposent également des débogueurs matériels. Il est possible d'acquérir une connaissance de base de l'environnement de développement en testant une carte d'évaluation ou de développement, car elles sont souvent équipées d'un débogueur intégré, aux fonctionnalités limitées. Les compilateurs sont généralement disponibles gratuitement, avec des restrictions telles que l'absence d'accès aux optimiseurs ou des limitations de la taille du code. De nombreuses applications liées à la sécurité imposent des exigences élevées en matière de documentation, de sorte que des compilateurs et des outils sous licence complète sont nécessaires à des fins de traçabilité.

Au cours des dernières décennies, les fournisseurs de microcontrôleurs ont compris que les bibliothèques logicielles sont essentielles pour aider les développeurs. Au minimum, certaines doivent être disponibles pour permettre l'initialisation et l'utilisation de la grande majorité des périphériques. Dans de nombreux cas, des piles logicielles complètes, telles que USB et TCP/IP, sont disponibles. Pour les applications plus exigeantes, des systèmes d'exploitation en temps réel comme freeRTOS sont également portés sur les principales architectures de processeurs.

Un autre indicateur précieux des défis potentiels de développement futur consiste à examiner les errata du microcontrôleur choisi. Si la liste est étonnamment longue et que certains problèmes n'ont pas de solution connue, il s'agit probablement d'un composant à éviter. Il est également utile de parcourir les forums pour connaître les expériences d'autres utilisateurs et pour savoir dans quelle mesure le fournisseur est réactif et utile lorsqu'il répond aux questions.

---

Des questions ou des commentaires ?

Vous avez des questions techniques ou des commentaires sur cet article ? Envoyez un courriel à l'auteur à stuart.cording@elektor.com ou à l'équipe d'Elektor à editor@elektor.com.



Traduction : Maxime Valens