Du microcontrôleur au microprocesseur

Publié par cpb
juil 10 2014

J’ai eu le plaisir aujourd’hui de présenter une conférence au séminaire Captronic « Du microcontrôleur au microprocesseur – Quelle architecture pour quel projet ? » à la C.C.I Nord Isère de Villefontaine.

Le contenu de ma présentation est disponible ici. J’avais déjà abordé ce thème en novembre dernier à Lille, mais j’ai pu enrichir la présentation avec divers approfondissements sur Linux embarqué, et quelques démonstrations de fonctionnement.

En outre, nous avons présenté avec mon ami François Beaulier une architecture hybride composée d’un microcontrôleur (STM32) couplé à un system-on-chip (Raspberry Pi), communiquant en utilisant une bibliothèque de notre création nommée LxMCU.

Cette bibliothèque libre, est prévue pour faire communiquer un système Linux (« Lx ») avec un microcontrôleur (« MCU ») en utilisant un lien SPI (ou I²C prochainement) et une GPIO. Elle sera bientôt mise en ligne.

PS: je n’ai malheureusement pas pu trouver le temps de rédiger d’article sur ce blog depuis bien longtemps, j’espère pouvoir y remédier dans les semaines à venir.

5 Réponses

  1. Fabrice dit :

    Bonjour Christophe,

    Superbe idée cette librairie de communication inter-processeurs :-)
    Je suis impatient d’y jeter un coup d’œil, et peut apporter ma petite pierre à l’édifice 😉

    Fabrice

  2. yann dit :

    Cela résume bien, surtout pour la partie Linux, mais je n’ai pas la même vision que vous de ce qu’est un microcontroleur!

    Certes, la complexité croissant, on les appelle de nos jours plutôt des SoC. Plus un terme à la mode qu’autre chose.

    Mais au fond, un microcontroleur, cela a toujours été un microprocesseur (et pas forcément de simples PIC, depuis longtemps: Cf le 68k avec les familles QUICC dès le début des années 90, passées quelques années après au PPC) avec des périphériques (de communication, en particulier) intégrés dans le même boitier.

    Maintenant qu’on y colle les caches de niveau 2 et 3/plateforme, le PCIe, voire des DSP, avec en plus une variété de versions liées à un design plus modulaire populant le Lego de silicium avec plus de prise en compte de l’intersection des demandes/architectures de gros clients… on les nomme SoC.

    Mais conceptuellement c’est la même chose et il y a toujours eu un processeur généraliste en chef d’orchestre. Votre distinction n’a donc pas vraiment lieu d’être.

    Ainsi, un petit firmware n’est pas le mode imposé d’un petit microcontroleur ni n’impose d’être codé en mode « machine à laver » (tout en pooling). Sans en arriver à refaire un OS, il est tout à fait possible de prévoir des traitements par interruption.

    Un autre élément pourrait également à mon sens être évoqué vu que Xenomaï l’est:

    Car c’est en fait un co-noyau pouvant émuler des OS temps réels du marché, tel vxWorks, l’idée étant de prendre la main sur les exceptions avant le noyau Linux qui tourne a côté et lui passer la main quand on a le temps, permettant de profiter de sa gestion du système de fichiers, du réseau… bref, de lui laisser toute l’intendance qui n’est pas le job du temps réel.

    En effet, au dessus du mode superviseur du noyau, tout processeur moderne intégré ou non à un SoC dispose désormais d’un mode hyperviseur: Il est alors tout à fait possible d’avoir un partitionnement hardware (séparant certains coeurs et périphériques) d’un SoC entre un système Linux qui va gérer les ressources dont il a l’usage… et un autre vxWorks/Firmware maison, qui ne va faire que le temps réel. Les 2 mondes communicant généralement à travers un système de messaging prévu dans le silicium ou via des solutions custom (PCIe/SRIO/protocole réseau UDP dédié).

    Xenomaï est une solution qui perds de son utilité (sauf à s’éviter une licence vxWorks) quand on a un mode hyperviseur, même si au niveau architecture purement logicielle les motivations à les utiliser seront souvent les mêmes!

    • cpb dit :

      Merci de ce commentaire.

      Je pense que la différence entre microcontrôleur (µC) et microprocesseur (µP) est de plus en plus floue, mais je retiens en général la présence ou non d’une MMU (assurant donc une isolation mémoire entre processus concurrents et des possibilités de gestion dynamique de la mémoire assez efficaces), les modes de consommation électriques très réduits pour les µC, l’accès à un bus d’adresses/données permettant entre autre d’ajouter de la mémoire, le coût d’un processeur, etc.

      Ce qui m’importe également c’est le modèle de programmation. Plus qu’une frontière matérielle, il y a une distinction assez nette entre les codes prévus pour fonctionner sur le « bare metal » et ceux qui s’exécutent en tant que clients d’un O.S. (Linux ou autres). Et j’ai remarqué à de très nombreuses reprises, en formation ou en prestations de conseil, qu’il y a un effort nécessaire pour le développeur accoutumé à travailler sur des µC lorsqu’il doit intégrer son code dans l’écosystème que représente un O.S. (l’inverse est vrai mais un peu moins marqué).

      La tendance actuelle pousse (à tort ou à raison je ne me prononce pas) à passer de nombreuses applications embarquées jusqu’alors sur des µC simples vers des environnements plus complexes, généralement sous Linux, afin de disposer immédiatement des piles de protocoles, des systèmes de fichiers, de l’accès à des périphériques variés (via l’USB par exemple). Dans ce cadre, j’ai souhaité attirer l’attention avec ces conférences sur le travail non négligeable nécessaire pour changer de modèle de développement, et donner un bref aperçu de ce qui est disponible avec un OS comme Linux.

  3. Scratt2Bron dit :

    Bonjour,
    Je viens de lire votre article très intéressant ; Le titre et les comparaisons me paraissent un peu trompeurs. En effet, en page 9, je ne suis pas complètement d’accord avec les inconvénients que vous listez pour un microcontrôleur. Au contraire, si l’on veut du déterminisme, il faut utiliser un microcontrôleur et particulière avec un ordonnanceur basé sur l’utilisation des interruptions. Contrairement à un OS type Linux, vous pourrez savoir exactement le temps de réponse de votre µC à un stimulus. De même, la gestion d’opérations d’attente et de timers est très simple et précise. Enfin, les microcontrôleurs sont particulièrement appréciés pour leur consommation qui est bien plus faible que les microprocesseurs.
    Je pense qu’on ne peut pas comparer directement un microprocesseur et un microcontrôleur car ils ne visent pas les mêmes applications. Implanter un OS type Linux apporte de grands avantages pour certaines application, mais est strictement inutile et pénalisant pour d’autres notamment le temps réel. L’OS va chercher à masquer le matériel ; cela permet à un non électronicien d’utiliser ce matériel, mais au prix d’un gros gaspillage de ressources.
    Bien sûr, pour des opérations de communication Internet, gestion de périphériques « complexes » liés au multimédia, l’OS devient maintenant indispensable ; mais pour certaines « petites applications à contraintes sévères », rien ne vaut un µC programmé (proprement) en langage C.

    Enfin, je vous félicite pour la pédagogie de votre article. Je ne vais pas manquer de venir consulter régulièrement votre Blog et le faire connaitre.

    Cordialement,

    • cpb dit :

      Bonjour,

      Je suis parfaitement d’accord avec vous sur l’efficacité et l’économie de ressources que représente l’utilisation d’un microcontrôleur pour des applications relativement simples et le déterminisme qu’ils permettent.

      Le sujet de cette page (c’était indiqué oralement pendant la présentation mais ça n’apparaît pas clairement sur le slide seul) est d’indiquer que les méthodes de programmation pour microcontrôleur (en particulier les boucles de scrutation) s’appliquent très mal sur un microprocesseur avec OS.

      Utiliser une boucle active sur un microcontrôleur est parfaitement légitime, il est conçu pour cela.

      Utiliser la même chose sur un microprocesseur avec un OS comme Linux est mauvais : l’ordonnanceur va « punir » la tâche pour son mauvais comportement vis-à-vis des autres tâches, et les temps de réponses seront totalement imprévisibles.

      Le but était de sensibiliser l’auditoire sur le fait que l’on doit programmer différemment lorsqu’on utilise un OS. En particulier, utiliser des appels-système bloquants et des attentes passives avec select() ou epoll_wait() par exemple.

      Merci pour votre intérêt pour cet article.

URL de trackback pour cette page