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.

3 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.

URL de trackback pour cette page