[Conseils] Quel microcontrolleur choisir ?

Salut les zeszteux !

Aujourd’hui j’ai une petite question qui me trotte dans la tête : quel microcontrolleur choisir ? J’ai cinq pré-requis pour ce composant :

1. une interface SPI
2. une interface I2C
3. une interface USART
4. une consommation minimale (genre 6 mois à un an de fonctionnement sans changer la batterie)
5. des outils de développement simples et de préférence libres (type GCC-AVR)

Les tâches réalisées par le µC seront basiques : se réveiller une fois toutes les heures, parler avec un composant via la liaison USART pour récupérer des données, et les transmettre à un autre via la liaison SPI ou I2C. Tout ce système doit tenir dans un environnement fermé, avec une batterie intégrée à changer le moins souvent.

Je pensais partir sur le µC ATtiny417, étant donné le nombre très limité de fonctionnalités à implémenter et qu’il corresponde à tous les critères énoncés :

• interfaces USART + SPI + I2C
• tailles et conso minimales (4K de flash est amplement suffisant)
• GCC-AVR + AVRDude

Mon soucis, c’est que je ne connais pas les autres vendeurs de composants, peut-être un zesteu aurait un conseil pour un µC équivalent (j’ai regardé du côté de ST avec les STM8L, mais les outils de dev ont l’air relativement plus compliqués qu’Atmel). Même question, niveau consommation faut-il mieux partir sur un µC 8 bit ou sur un composant type Cortex-M0/M0+ si le développement est plus simple ?

En vous remerciant d’avance

Salut,

Bon, je vois que tu sais déjà ce que tu cherches, je ne vais pas épiloguer.

Je te conseille de jeter un oeil sur la famille PIC de Microchip (qui facilitent le développement, par exemple pour changer l’état d’une sortie, il n’y a pas besoin de jouer avec les registres, il existe directement une fonction "output high(PIN_XX)") (IDE: MPLAB).

Il y a aussi Texas Instruments, avec la famille des MSP430, ils ont plusieurs modes de consommation (certains modes sont vraiment économiques tu peux multiplier par 10 ton autonomie voir plus …), mais cette fois-ci, il n’y a pas de "framework" comme pour les PIC, il faut coder soi-même dans les registres et ce n’est pas forcément évident pour un noninitié … (IDE: Éclipse, mais je crois qu’il est possible d’en utiliser un autre).

Sinon, je te conseille de jeter un oeil directement chez les fournisseurs, comme Farnell, il propose un large choix de composants et en général, la plupart des fabricants ont leurs produits sur cet espace de vente … (PICs et MSPs y sont, je suppose que les STMs et les ATtiny aussi) .

EDIT: Les cortex M-0 s’apparentent plutôt à des micro-processeurs (seuls ce sont des CPUs), s’ils sont intégrés dans un autre matériel, alors celui-ci sera un microcontrôleur. Ex: Le SAM3A d’Atmel est un microcontrôleur (avec toutes les fonctions périphériques, communications, mémoires, contrôle etc.) mais il intégre un Cortex-M3 comme processeur. Je t’invite a regarder la différence entre microcontrôleur et micro-processeur si elle ne t’est pas familière

Il y a aussi Texas Instruments, avec la famille des MSP430, ils ont plusieurs modes de consommation (certains modes sont vraiment économiques tu peux multiplier par 10 ton autonomie voir plus …), mais cette fois-ci, il n’y a pas de "framework" comme pour les PIC, il faut coder soi-même dans les registres et ce n’est pas forcément évident pour un noninitié … (IDE: Éclipse, mais je crois qu’il est possible d’en utiliser un autre).

Ils ont aussi leur OS temps réel homemade TI-RTOS qui peut simplifier le développement (mais il faut réussi à se mettre dedans, ca change de la programmation µc classique)

Exact, j’ai omis ce point pourtant j’ai déjà joué avec le RT des MSP430 …

Merci pour vos réponses !

Les cortex M-0 s’apparentent plutôt à des micro-processeurs

la différence entre microcontrôleur et micro-processeur

Hmm, la différence n’est-elle pas au niveau des capacités du matériel ? Ne serait-ce qu’au niveau des accès mémoire (beaucoup plus rapides dans un microcontrolleur), la notion de temps-réel beaucoup plus présente (via des instructions spécifiques) et la quantité de mémoire disponible ? La non-présence de MMU aide aussi. Effectivement, sur le site d’ARM les Cortex-M0+ disposent d’un processeur, mais dans le système final on se retrouve toujours avec des capacités proches d’un système de contrôle plutôt qu’un système "multimédia".

Ma question était surtout au niveau de la consommation, est-il intéressant de perdre un petit peu de durée de vie en passant par un µC plus standard, dont les outils sont plus accessibles (et il y a possibliité de baisser leur fréquence) ?

Concernant le RTOS, je ne pense pas qu’il soit nécessaire, étant donné les tâches extrêmement simples que je vais devoir effectuer.

Si tu veux pas concevoir toi même ton circuit, pourquoi ne pas partir sur une arduino ?

Tu peux bypasser l’IDE, récupérer les différentes bibliothèques (qui ne sont que du C++ classique), compiler avec avr-gcc et flasher avec avr-dude

Si tu veux pas concevoir toi même ton circuit, pourquoi ne pas partir sur une arduino ?

Arduino est vraiment mauvais en terme de consommation d’énergie.

Quelle différence fait tu entres un système de contrôle et un système multimédia ? Je ne suis pas sur de comprendre ou tu veux en venir.

Je ne me suis pas attardé sur les cortex (je n’ai jamais travaillé avec), mais ils sont clairement présentés comme des processeurs. ARM semble avoir tenté de faire un genre de processeur hybride, dixit Wikipédia:

"ARM Cortex-M est une famille de processeurs RISC 32-bits d’architecture ARM servant à la fois de microprocesseur et de microcontrôleur à destination de l’embarqué."

Donc, mea culpa, j’ai été un peu vite en besogne

Néanmoins, pour ce que tu as à faire, je me tournerais vers un microcontrôleur, ça me paraît amplement suffisant

Par rapport a quoi ? Quand tu parles de durée de vie, tu veux parler d’autonomie ?

Pour les microcontrôleurs, en général ils ont plusieurs modes de basse conso, ils coupent l’alimentation de plus ou moins de choses à l’intérieur. C’est à toi de choisir le mode de fonctionnement adapte à ton besoin, si tu as besoin de faire des opérations en sleep par exemple ou s’il s’agit juste de pouvoir l’endormir/le réveiller … Je t’ai mis un exemple pour le MSP430G2553:

Quand tu parles de durée de vie, tu veux parler d’autonomie ?

Oui, vu que l’objet a pour but d’être embarqué avec une batterie.

Pour les microcontrôleurs, en général ils ont plusieurs modes de basse conso

A ce niveau, les datasheet & programming manuals des différents µC détaillent très bien la mise en place de ces modes, je ne me fais donc pas d’inquiétudes de ce côté

Par contre niveau MSP430, je suis étonné des prix, les moins chers sont autour de 2€, là où les ATtiny et autres sont plus vers les 1€ (voire inférieur).

Quand tu parles de durée de vie, tu veux parler d’autonomie ?

Oui, vu que l’objet a pour but d’être embarqué avec une batterie.

Oui mais une durée de vie ne désigne pas la meme chose qu’une durée d’autonomie.

Du coup je n’ai pas compris ta question "est-il intéressant de perdre un petit peu d’autonomie en passant par un µC plus standard ?"

Tu veux dire, est-ce que ca vaut le coup de se lancer dans un composant "Incredible-Ultra-Low-power" ? Plus sérieusement, ca depend de l’autonomie visée, mais c’est comme tout, y a des calculs theoriques qui te permettent de te faire une idée … De ce que j’en sais, pour rester dans l’exemple du MSP430, la différence entre le mode actif (AM) et le mode le plus économique (LPM4 ici) est assez énorme (de 420uA à 0.1uA, soit un rapport 4200, 420uA étant la conso maximale en mode Actif sous 3 volts)

Allez, pour le plaisir, une petite application numérique avec une batterie de 250mAh:

• En mode actif sans interruption, le MSP430 serait alimenté pendant 595 heures (25 jours environ)
• En mode LPM4 sans interruption, le MSP430 serait alimenté pendant 2 500 000 heures (285 ans)
• Si tu passes en mode actif pendant 1 seconde toutes les minutes (le reste du temps en LPM4), le MSP430 serait alimenté pendant 35 000 heures (4 ans)

Si tu cherche un MCU à faible consommation mais sans plus, c’est-à-dire que tu ne cherche pas le mW, soyons clair, la plupart des MCU basiques seront répondre à ton besoin.
En effet tu réduira plus la consommation sur le mode d’utilisation du MCU que par un modèle spécifique :

• Abaissement de la fréquence de fonctionnement au minimum possible pour avoir un soft qui n’y passe pas 2h. Par exemple un ATTiny417 ne consommera que 2.2 mA en 5V à 5MHz contre 6.9mA à 20MHz
• Abaissement de la tension de fonctionnement. Toujours sur l’ATTiny417, 2.2mA @5V / 5MHz mais 1.2mA @ 3V / 5MHz.
• Optimisation de l’algorithme : un réveil toutes les 60 min est nécessaire ? Ou toutes les 70 min c’est possible ? Sur le long terme tu perds en données mais tu gagne en conso.

Enfin il faut penser à tout le système, le MCU c’est bien, mais si derrière c’est pour l’alimenter en 5V avec un 7805 à partir de 12V… Tes alims ne devraient pas être sous 80% de rendement. Idéalement taper dans le 90-95%. Plus tu as de domaines de tension, plus tu aura d’alims et donc de pertes potentiellement, néanmoins pour un MCU, une tension faible (3.3V ou moins) est préférable en terme de consommation mais à voir pour les autres composants en I2C et UART.

De même, les pull-ups doivent être utilisées avec parcimonie et essayer d’utiliser une valeur plus élevée pour réduire le courant.

zeqL tout ca c’est pour des conso "en fonctionnement" (sous-entendu "pas en veille") non ? parce qu’après la veille a son importance aussi (dans mon taf je dois traquer des µA, on gagne des heures/jours par-ci par là sur le long terme avec ça)

Bah t’auras plus de perte avec ton alim ayant un rendement de 40% avec une charge < 1 mA qu’avec un MCU qui consomme 5% de plus en veille qu’un autre.

Si on est vraiment contraint par la consommation, il faut faire l’étude du système entier et pas seulement du MCU.

Quand tu cherche le moindre µA, le courant de fuite d’une diode ou d’un transistor peut aussi jouer…

Ah bah je dis surtout pas le contraire hein (par ici on travaille sans regulo, directement avec la tension batterie justement pour éviter des pertes (et parce que ça ne nous apporte rien tfacon))

Oui, tu fais bien d’en parler, l’auteur du post n’a pas précisé s’il comptait fabriquer sa propre carte ou plutôt utiliser une demoboard (Arduino-like). Je vois mal comment contrôler la consommation d’une demoboard et, a moins que ça soit dans un cadre pro, réaliser une carte c’est quand même autre chose

l’auteur du post n’a pas précisé s’il comptait fabriquer sa propre carte ou plutôt utiliser une demoboard

L’objectif, c’est de faire un système communiquant capable de transmettre des traces GPS à un transmetteur Sigfox, afin de faire du tracking approximatif (de l’ordre de 100 mètres près). Le principe, c’est que toutes les 30 minutes (ou toutes les heures) :

1. le GPS est démarré et donne les infos de positionnement
2. on éteint le GPS (ou on le met en low-power)
3. on démarre le transmetteur Sigfox, auquel on fait envoyer les données
4. on éteint le transmetteur et on met le µC en pause.

Niveau carte, c’est du custom. J’ai les compétences pour programmer et choisir les composants principaux, après le niveau "bas" (type antenne, petits composants type résistance & condensateurs) c’est un peu plus compliqué pour moi. Mais bon ça ne me fait pas peur d’apprendre .

Un tracker GPS, cool en cas de vol

Donc comme l’a dit zeql, il faut orienter tout le design vers l’objectif de consommation minimum, tu as déjà conçu/routé une carte ? As-tu cherché des renseignements sur les règles de routage à suivre et les logiciels existants ?

Et pour l’impression de la carte tu vas passer par un professionnel où tu comptes faire une impression DIY ?

Sinon, est-ce-qu’on a répondu à tes questions sur la consommation ? Il y a encore beaucoup à dire en dehors du MCU sur cet aspect, beau projet en tout cas

Du coup la conso du mcu devient moins critique, quand on voit ce que consomme un GPS

Donc comme l’a dit zeql, il faut orienter tout le design vers l’objectif de consommation minimum

Absolument

EDIT : j’ai prévu de limiter le MCU au minimum de sa fréquence, afin de limiter encore plus la conso.

tu as déjà conçu/routé une carte ?

Je connais les grandes lignes "théoriques" :

• placement des composants (avec tailles réelles à récupérer dans les datasheets/via une bibliothèque pré-existante)
• routage, comment connecter les composants (avec évidemment la limitation du nombre de couches au maximum)
• la séparation des différents "domaines" de la carte (programmation, puissance, contrôle et transmission)

As-tu cherché des renseignements sur les règles de routage à suivre et les logiciels existants ?

• KiCAD (parce que libre) ou Eagle (pas libre, mais si c’est mieux je vois pas de soucis pour l’utiliser)
• niveau règles de routage, je connais pas trop, je suppose qu’il faut placer certaines parties de certaines façons afin d’éviter les ennuis

Et pour l’impression de la carte tu vas passer par un professionnel où tu comptes faire une impression DIY ?

Plutôt un professionnel, je n’ai pas le matériel pour réaliser cette carte manuellement, et les fablab autour de chez moi ont pour réputation leur prix de production relativement élevés.

Sinon, est-ce-qu’on a répondu à tes questions sur la consommation ?

Absolument, je savais déjà à la base que la conso devait être limitée au maximum. Il est malheureusement compliqué de marier low-cost et basse conso, mais heureusement les composants sélectionnés ont des modes "offline" qui permettent de les éteindre complètement.

Du coup la conso du mcu devient moins critique, quand on voit ce que consomme un GPS

Effectivement, mais si je peux gagner un mA quel que part, alors autant le prendre

Un tracker GPS, cool en cas de vol

Pratique quand tu n’as pas de garage et que ta voiture dors dehors en ville. Et si tu arrives à limiter la taille encore plus, tu peux l’intégrer sur un vélo et avoir l’adresse en cas de vol

niveau règles de routage, je connais pas trop, je suppose qu’il faut placer certaines parties de certaines façons afin d’éviter les ennuis

Le routage c’est compliqué, cela ne s’improvise pas. Mais tu parts sur des technos simples donc cela pourrait aller avec un peu d’entrainement / formation.

Typiquement (certaines astuces ne te concernent pas) :

• bien penser à l’intégration mécanique des composants, en évitant de mettre des condensateurs chimiques à proximité de zones chaudes, à répartir les composants qui chauffent sur la carte ;
• penser au volume des connecteurs, j’en connais qui ont déjà fait des connecteurs SATA et USB très proches, ce qui fait qu’une clé USB volumineuse ne peut pas être branchée en même temps que le SATA d’à côté ;
• Éviter les angles droits et les via au maximum. Pour angles, il faut le faire en plusieurs étapes ;
• pour les connexions hautes fréquences (USB, PCIe, etc.), ne pas tirer les fils trop prêt de zones de bruits, penser aussi à faire en sorte que les fils soient de même longueur pour un même bus (normalement les outils peuvent faire ça pour toi) ;
• bien régler l’outil en terme de tailles des pistes, etc. Ton fondeur ne sait pas gérer n’importe quelles configurations et selon la techno employée tu ne pourras pas faire tout de la même façon (une taille de piste trop petite a plus de chance de rater lors de sa réalisation suivant la techno du fondeur, et ne peut pas gérer un courant trop fort) ;
• faire attention aux composants montés en surface et les autres, tu ne pourras pas mettre un composant en surface du côté opposé d’un composé qui traverse tes couches ;
• attention aussi dans ton cas aux antennes, pour que cela fonctionne bien tu as des propriétés à respecter (de dimension, de formes) et bien sûr éviter que les composants alentours ne le gêne ;
• bien vérifier le design physique des composants que tu places, quand tu dois en modéliser un une erreur arrive vite (du genre tu inverses vue haut / bas, ou l’ordre des pistes) ;
• limiter au maximum la longueur des pistes (donc éviter de mettre deux composants avec un grand bus qui dialoguent entre eux à des côtés opposés de la carte).

Bref, c’est un métier plutôt complexe qui nécessite une grande précision sur les détails (les entreprises qui font des cartes ont des gens dédiés à cette tâche et qui prend beaucoup de temps). N’hésite pas à faire relire ton routage par un pro ou dans un fablab avant réalisation.