Au cœur de nos appareils numériques, des puces. Mais selon les cas, leur composition diffère. On parle ainsi de processeur, de SoC ou de micro-contrôleur. Des solutions à la composition parfois assez proche en théorie, mais avec de grosses différences dans la pratique.
Nos ordinateurs sont basés sur une multitude de composants aux acronymes dont nous parlons ici au quotidien : CPU, GPU, mémoire, carte mère, chipset, stockage via des HDD/SSD. Mais ils ne représentent qu'une partie du secteur informatique.
Une réalité de plus en plus visible depuis l'apparition des Single Board Computer (SBC) ou micro PC, avec le Raspberry Pi en fer de lance. Comme les smartphones, tablettes et autres systèmes embarqués, ils utilisent des SoC basés sur l'architecture ARM, plutôt que x86 pour les processeurs d'AMD et Intel.
Les bidouilleurs s'intéressent parfois à d'autres cartes exploitant cette fois des micro-contrôleurs, encore plus basiques et économes en énergie, comme le Raspberry Pico et son RP2040 qui viennent d'être annoncés. Mais dans la pratique, qu'est-ce qui différencie réellement ces solutions les unes des autres ?
Des processeurs...
Le micro-processeur est au cœur de nos ordinateurs, présenté en général comme son « cerveau » lorsqu'il s'agit de vulgariser son rôle à un public non technique. Il est en effet central, puisque cette puce est chargée d'exécuter la majorité des calculs, en lien avec la mémoire, le stockage, la carte graphique, etc.
On la désigne souvent par l'acronyme CPU (Central Processing Unit), un peu à tort puisque ce n'est là qu'un de ses rôles. En effet, avec le temps elle a gagné en fonctionnalités et les processeurs modernes intègrent directement certains éléments qui étaient externalisés jusque là : le contrôleur mémoire, la partie graphique ou certaines E/S.
Pour s'en convaincre, il suffit de regarder le diagramme d'un Core de 11e génération d'Intel (Tiger Lake). Comme on peut le voir dans le document ci-dessous, les cœurs de calcul sont désormais une minorité de la puce qui va même jusqu'à intégrer différents accélérateurs pour le traitement d'image, l'IA, etc.
... qui ressemblent de plus en plus à des SoC
On serait alors tenté de les présenter comme des SoC (System-on-chip). Comme leur nom l'indique, ces solutions que l'on trouve essentiellement dans le domaine de l'embarqué ou de la mobilité (smartphones, tablettes) comprennent presque l'entièreté d'un système au sein de leur die.
Mais les processeurs x86 sont encore en général accompagnés d'un chipset où sont déportés une partie des E/S et du réseau, ce qui n'est pas le cas d'un SoC. Il y a néanmoins des exceptions, tant chez Intel que chez AMD. Lakefield intègre par exemple au sein d'une même puce différents cœurs CPU, GPU, la gestion des E/S et même la mémoire dans un packaging de 12 x 12 mm. « L'astuce » trouvée par Intel est de la composer en trois couches.
Avec les premières versions de ses Ryzen, AMD avait fait un choix similaire. On y trouve ainsi des cœurs CPU, le contrôleur mémoire, parfois un GPU mais surtout des contrôleurs S-ATA/USB. Les deux premières générations (Zen(+)) sont autonomes, ne nécessitant pas de chipset. Cela a changé avec Zen 2, les E/S et le contrôleur mémoire ayant été déportés dans un « I/O die », une puce différente placée dans le packaging, gravée en 12/14 nm plutôt qu'en 7 nm.
AMD présente Zen(+) comme un SoC, avec S-ATA et USB intégré. Zen 2 a externalisé ses E/S dans une puce séparée
Les SoC, des processeurs tout-en-un
Processeurs et SoC tendent donc à se rapprocher dans leur composition. Ces derniers gardent néanmoins quelques avantages comme une taille et une consommation très réduite, étant le plus souvent basés sur des architectures ARM. C'est pour ça qu'ils sont utilisés dans de nombreux SBC, comme le Raspberry Pi.
Mais aussi dans les smartphones et autres appareils mobiles. Car ils intègrent parfois un modem 4G/5G. Intel a bien tenté à une époque de faire de même avec ses Atom et le projet SoFia, cela s'est soldé par un échec. Mais qui sait...
Pour référence, voici le diagramme d'un SoC Rockchip RK3399(K) que l'on trouve dans le NAS Helios64 de Kobol :
Et les micro-contrôleurs dans tout ça ?
Viennent ensuite les micro-contrôleurs, nombreux. Outre le RP2040 à base de Cortex M0+ d'ARM, qui vient d'être annoncé par la fondation Raspberry Pi, les plus connus chez les bidouilleurs sont sans doute les ESP32 et ESP8266 d'Espressif Systems du fait de leur faible tarif, de l'écosystème et la communauté qui se sont construits autour. Mais on rencontre aussi souvent des modèles ATMel (notamment sur les cartes Arduino), le ST32 de STMicroelectronics, etc.
Un micro-contrôleur se distingue en général par une intégration plus poussée que les SoC, puisque de la mémoire et du stockage y sont le plus souvent présents. C'est là qu'une autre caractéristique de ces puces entre en jeu : on change d'échelle à de nombreux niveaux. Pour vous donner une idée, un ESP32-SOLO1 intègre un unique cœur Xtensa LX6 (32 bits) cadencé à 160 MHz, intégrant 520 ko de SRAM et 448 ko de ROM. Sa consommation est donnée pour 27 à 34 mA lorsqu'il est actif (Wi-Fi en sommeil) avec une tension de fonctionnement aux alentours de 3,3 V.
La composition d'un ESP32
On est donc loin des SoC consommant quelques watts ou des processeurs à plusieurs dizaines/centaines de watts. Surtout, ces puces sont presque intégralement autonomes. On ne peut y installer un OS classique, mais leur firmware permet d'y charger un programme qu'ils exécuteront en lien avec leurs E/S. Ils intègrent ainsi régulièrement de quoi contrôler des moteurs, capteurs et autres éléments du même genre.
On les programme en C(++), parfois directement en langage assembleur. Pour ceux qui veulent des solutions de plus haut niveau, il existe des solutions telles que MicroPython ou CircuitPython. Cela va parfois plus loin avec des solutions qui visent un usage éducatif comme les BBC micro:bit.
Nous aurons d'ailleurs l'occasion sous peu de revenir sur le fonctionnement de différents micro-contrôleurs, par l'exemple.
Commentaires (36)
#1
La grosse différence entre un microcontrôleur et un Soc pour moi, est l’intégration de la mémoire. Si vous faite une petite carte, un microcontrôleur n’a besoin que d’une horloge et d’une alimentation. Un SoC aura besoin en plus de DRAM et/ou de mémoire Flash.
#2
À effacer
#3
ST32 -> STM32
#4
Les micro-controleurs sont surtout “auto-suffisant”, car ils disposent d’entrées sorties qui leur permettent de nombreuses communications (CAN, USB, Ethernet, I2C, PWM, I/O numériques, Interruptions …). Les SOC peuvent eux aussi s’auto-suffire dans certains cas mais pas toujours, mais surtout, ils sont conçus pour une application bien spécifique, là où les microcontroleurs seront à usages génériques (d’où la richesse de leurs interfaces de communication au regard de leurs performances). C’est vrai que les CPU ressemblent à des SOC, en intégrant GPU, CPU, de la mémoire (mais en faible quantité comparé à la mémoire vive ou morte installée à coté), mais on y trouve moins de blocs fonctionnels que certains SOC.
A noter qu’il existe des SOC relativement basiques, comme les capteurs CMOS des appareils photos : grosso modo, une matrice de pixels, des drivers, et une interface numérique pour capturer l’image.
#5
Microcontrôleur :
Tu peut très rapidement y brancher des capteurs et y faire tourner du code. Le boot est instantané et tu peut l’éteindre à la porc quand tu le veut. Le code est en général assez simplet car pas beaucoup de ram / rom / cpu. En général ça tiens bien sur batterie et il y à des mise en veille prolongée.
Il faut un pc pour le programmer et le prix c’est juste donné !
Soc :
T’a l’os à gérer donc le boot est loin d’être instantané et tu peut pas l’éteindre comme un porc sinon il y à une chance pour que la prochaine fois ça boot pas. Tu peut mettre du code complexe et le monitorer les doigts dans le nez. Par contre bien souvent c’est que sur secteur.
Il ne faut pas de pc pour le programmer et le prix est élevé !
Pour résumer si vous débutez et que vous voulez un peu bidouiller commencez par un micro contrôleur. En quelques minutes il vous sera possible d’avoir des résultats. Et si par malheur vous en cramez un c’est pas grave car ça coute rien.
#6
Certains SOC n’ont pas d’OS, comme les capteurs CCD des caméras ;)
Ce sont eux aussi des SOCs.
#7
Merci pour l’article.
Je voyais bien ce qu’était un CPU ou un SOC mais pas vraiment pour un micro-contrôleur.
#8
Comme dit sur la composition c’est en gros ça même si on se retrouve du coup à considérer Lakefield comme un microcontroleur parce qu’il embarque de la RAM, alors que, bon, c’est pas trop le même délire en vrai 😬
#9
Et la puce M1 est un Soc, qui intègre la RAM et donc entre dans une autre catégorie appelée system-in-a-package
#10
C’est surtout marketing, pas une catégorie à part entière, ça reste un SoC classique. D’autres ont déjà intégré de la mémoire plus ou moins proche du processeur par le passé,
Intel avec de l’eDRAM avant Lakefield par exemple
#11
OK,
Ce que je voulais pointer, c’est que la distinction RAM embarquée ou pas ne fait pas toujours le Soc ou le contrôleur. L’analyse est plus complexe car il y a une autre catégorie, même si elle est perçue comme marketing.
Et l’article explique bien qu’il faut voir d’autres aspects (comme les E/S)…
#12
non pas vraiment en fait, un soc est un terme générique pour dire que l’on a mis ensemble plein de fonctionnalités et/ou périphériques sur une même puce/die, les cpu intel et amd jusqu’à zen+ sont des soc et les microcontrôleurs aussi. Les cpu amd c’est un peu différent depuis les zen2 et 3 car le io die est différent des coeurs zen2-3 sauf sur les version mobile ou le io die est graver avec les coeurs donc les version mobiles 4xxxU ou H sont des soc.
Les microcontrôleurs sont un sous ensemble des soc car on est limité dans ce que l’on peux mettre ou pas ensemble on ne peux pas tout mettre dans un microcontrôleur. Il y a par contre forcement un cpu, des compteurs et de la mémoire dedans même si les vieux microcontrôleurs n’en avait pas
non pas du tout il y a des soc qui se programme sur un pc et des soc qui n’ont pas d’os.
#13
La partie OS est intéressante. Effectivement, pour qu’un MCU démarre, il juste le brancher. Les séquences de boot d’un soc sont celles d’un ordi. Complexes, voire pas simples.
Par contre, le tu peux pas l’éteindre comme un porc … Tu vis à quel siècle?
Pourquoi les mettre dans la catégorie “SOC”? Tu as un exemple? (sans agressivité: par curiosité)
De même, certains CPU ont basculé dans une catégorie “quasi micro contrôleur” comme les dérivés de 8080/Z80. Il faut dire qu’un Z80, collé à une ROM, c’est ultra basique.
#14
L’appellation dépend principalement de ce qu’intègre la puce elle-même. La mémoire en étant exclue ça ne change rien.
La seule chose qui change dans le M1 c’est le bus et le fait qu’elle soit comme soudée. Ça modifie certaines caractéristiques (latence) et l’évolutivité mais pas le type de puce face à laquelle on est.
#15
+1
#16
Tu peut monter à plus ou moins une minute quand tu veut éteindre un PI… Si t’a pas d’interface comme un écran tactile tu devra ajouter un bouton physique qui initialise la séquence d’extinction. Alors qu’un arduino t’a juste à débrancher la prise. Et si tu à un crash sur un SOC rien ne te garantit que tu pourra à nouveau booter.
#17
si je peux me permettre tu mélanges 2 choses soc et environnement autour. Car le fait que tu ne puisses pas débrancher la prise comme ça c’est parce que avec ton soc qui est sur le PI tu utilises une distrib linux qui initialise un cache en écriture, de la mémoire virtuelle etc. C’est comme windows en fait et les soc intel il se peux que tu ne puisses pas rebooter car windows/linux avait des choses importante dans des fichiers temporaires et ça corompt l’os mais le soc lui il s’en contre fou cela ne l’empechera pas de fonctionner normalement et c’est bien pour ça que régulièrement même en arrachant la prise de mon PI ou reboot sauvage de mon windows j’ai aucun problème car j’ai désactiver la mémoire virtuelle, en plus mon PI3B+ il ne met pas 1min à s’arrêter enfin bref. Tout ce que tu décris c’est à cause de la façon dont est configurer ton OS et non à cause du soc.
#18
sympa ces petits articles de vulgarisation :)
vous avez tous les deux raison
il est très compliqué de rajouter et contrôler des systèmes de caches avec un µc, alors qu’un soc va généralement faire tourner un OS qui va très souvent utiliser ce genre de procédés.
un µc ne lit pas beaucoup de chose en mémoire, et en écrit encore moins, donc ce sont des opérations rapides qui, même si on coupe le jus, ont de grande chance se se terminer correctement, et elles vont rarement impacter le démarrage du système contrôlé par le µc
à l’inverse, avec un soc, l’os va constamment lire et écrire des données, dont certaines impactent le démarrage => si on coupe le jus brutalement, la probabilité que des données soit corrompues est largement plus grande qu’avec un µc, et elles peuvent bien bloquer le démarrage du système complet.
cela dit, le soc en lui-même fonctionnera, mais l’os peut se retrouver corrompu facilement
#19
Un capteur optique de réflex, par exemple, c’est un SOC, pareil pour le capteur de ton smartphone : un SOC ne contient pas forcément un processeur. C’est juste un “système” qui a une tache dédiée, le tout sur une seule plaquette de semi-conducteur.
#20
Pour moi, SOC = system on a chip = CPU + RAM + IO.
Aucun rapport entre le fait d’être un ordi, un soc ou un mcu.
#21
C’était le cas avec EXT2 ou en FAT32, pour corrompre un linux moderne ou un Windows en NTFS, il faut vraiment pas avoir de bol. Avec les systèmes de fichier journalisé + les copies de partout de Windows et les outils d’auto-réparation, je n’ai pas planté un système sur arrachage de prise depuis des années.
Les applis par contre sont moins sécurisées.
#22
je suis tout à fait d’accord c’est ce que j’essayais de dire sans rentrer dans le détail donc nous sommes d’accord pour dire que ce n’est pas ce qui va différencier un soc ou un microcontrôleur car les arguments donnés par skankhunt42 dépendent de l’os et de sa version non de la puce utilisée
#23
si ce comprends bien ce que tu dis tu es uniquement d’accord avec moi
de toute façon le fait qu’il y ai os ou pas n’est pas un critère car on peux utiliser un os sur µc. ils ne sont évidement pas de type x86 windows mais ça peux aller jusqu’à un petit linux. ce sont en général des os dis temps réel pour des applications spécifiques. que ce soit µcOS, freeRTOS ou sysbios (os spécifique µc/DSP TI) ce sont des OS pour processeur à jeux d’instruction réduit (RISC)
Le jeu d’instruction permet de différencier les CPU intel/AMD du reste des SOC basé sur un coeur ARM
#24
je suis quand même un peu d’accord avec lui, les soc sont utilisés dans des systèmes plus complexes et plus sensibles aux extinctions brutales (même si l’os arrive a rebooter et à réparer le système, il a eu une étape supplémentaire lors du boot pour cette opération)
une sonde de température ou une mini station météo (genre de truc courant qui utilise un µc ou qu’on peut bricoler avec), ça enregistre rien conditionnant le boot.
je viens de relire ton message initial et surtout “si je peux me permettre tu mélanges 2 choses soc et environnement autour.” donc effectivement je détaillais “l’environnement autour”
#25
Et encore la plupart des uC on une clock interne.
Dès que tu veux faire quelque chose d’un minimum sérieux, tu mets un OS temps réel sur les uC.
Et je peux t’assurer que tu peux faire des choses vraiment hyper complexe sur un micro.
Quand aux SOC, les smartphones ne sont pas sur secteur, et j’aurais bien tendance à dire que dans la majorité des cas on est sur batterie… mais mon domaine de prédilection, c’est plus les uC.
#26
Ca me fait penser aux keyloggers hardwares que Stéphane Marty de la chaine Youtube Deus Ex Silicium avait présenté. L’un d’eux était un minuscule SoC qui, une fois branché, offrait toute la saisie interceptée via une interface web et un réseau Wi-Fi embarqué.
Le tout dans un minuscule truc de la taille d’un ongle de petit doigt.
#27
En fait, la différence entre SoC et microcontroleur (MCU) n’est pas entièrement précise ici.
Pour définir un MCU, il faut en fait se pencher sur son cas d’usage.
Un SoC a une utilisation assez précise : faire tourner un OS avec un système de fichiers pour stocker des librairies et des logiciels
son accès mémoire se fera donc probablement à travers une MMU pour gérer l’adressage virtuel.
Un MCU n’aura pas de MMU. Il pourra faire tourner un OS, mais pas un qui nécessitera de la RAM avec MMU.
Aussi, un SoC aura des IO très “figées”, peu configurable, puisque son utilisation sera assez standard. Alors qu’un MCU aura des IO plus configurables, pour être plus génériques.
#28
Tu veux qu’on parle des stm32h7 cadencés à 550MHz, avec sorties pour écran 720p, ethernet 100M, et décodeur jpeg hardware ?
Eh bin, va pas faire du code sans OS dessus, ça sera du gâchis. Et pourtant ça reste des microcontroleurs.
#29
D’où l’importance de généraliser un peu la conversation…
Le secteur c’est pas mal démocratisé ! A une époque c’était 35 balles la platine officielle arduino avec un seul form factor. Depuis il y à tout un tas d’autre marque et entre temps l’informatique c’est encore miniaturisé et plus puissant.
Du coup tu peut avoir des micro pc avec un os tellement léger et plein d’io qui ressemblera comme deux goutte d’eau à un arduino sauf que tu pourra log des choses et coder en python. De l’autre tu pourra avoir des micro controlleurs qui vont de plus en plus ressembler à des mini pc.
J’ai lu que quelqu’un parlait des système de fichier et de réseaux… Mais sur un arduino il est aussi possible d’avoir des fichier via un lecteur de carte SD et un shield wifi / ethernet.
ps : comprenez bien que votre conversation de pinaille fera juste fuir les non avertis ce qui va produire l’effet inverse de cette news, je pense !
#30
Je suis étonné que personne ne parle de la presence (ou non) d’une MMU (Memory Management Unit), permettant l’usage de mémoire virtuelle. (Mode “protégé” selon Inte)
Sur les uC, il y a éventuellement une MPU (memory protection unit), mais pas de MMU.
Si on regarde le 8086, il n’y avait pas de MMU (présente sur le 80286), mais déjà le concept était présent avec des segments de 64k (processeur 16bits, bus d’adresse de 20bits, étendu à 24 bits sur le 386).
De manière plus contemporaine, si on regarde les cœurs ARM M vs A (ou plus anciens)
Les soc permettent surtout de réduire le nombre de composants (réduction d’un coût, PCB moins complexe, etc), mais c’était déjà le cas lors de l’intégration du coprocesseurs flottant ou … des MMU (composant externe pour les 68k par exemple)
#31
mhh, attention, que ce soit un mcu ou un cpu / soc dédié, couper l’alim sans prévenir peux corrompre des données.
Suffit qu’il y ait une écriture en cours vers la flash / eeprom / sd, etc. Le soft peux y palier par des checksums / redondance et/ou le hard peux prévoir des condensateurs suffisamment larges pour tenir jusqu’a la fin de l’écriture (c’est d’ailleurs ce qui est fait dans les ssd orientés datacenter)
#32
Pour moi la majeure distinction entre CPU / SOC / µC c’est simplement le nombre de composants externes qu’il va falloir autour pour l’exploiter.
Comptez combien de composants il y a sur un carte arduino, un raspberry PI et un PC complet.
Je pense qu’on multiplie d’un facteur 50 à chaque fois
un truc qui tourne avec 5-10 composants passifs autour, c’est un microcontroleur
si il y a 300 composants, c’est un SOC
si il y en a trop pour les compter c’est un CPU !
#33
Pinaise, j’ai confondu ASIC et SOC… je suis fatigué ! Bref, tu as raison.
#34
La MMU ainsi que le chargement dynamique d’exécutables / librairies (de symboles quoi) sont évoqués effectivement dans mon pavé, je ne peux donc que être d’accord avec toi.
#35
Enfin! Merci!
#36
De rien, j’ai été un peu lent… sur ce coup ! J’ai réalisé un peu tardivement que j’étais carrément dans le faux. Merci à toi d’avoir mis le doigt dessus :)