Plus d'un an après la sortie de la nouvelle version de la célèbre carte, on attendait toujours sa déclinaison pour le monde de l'embarqué. Elle vient d'être annoncée à un tarif de départ de 25 dollars. 32 déclinaisons sont proposées, avec quelques surprises à la clé.
Le Compute Module 4 de la fondation Raspberry Pi est enfin là. Il reprend le gros des caractéristiques de la v4 du Single Board Computer (SBC), dont son (chaud) SoC Broadcom BCM2711. Le CPU se compose ainsi de quatre cœurs ARM Cortex-A72 cadencés à 1,5 GHz, avec une partie graphique VideoCore VI.
Une carte, plein de possibilités
Deux interfaces HDMI (4K60p) sont exploitables, ainsi qu'une ligne PCIe 2.0, deux interfaces DSI (écran) ou CSI-2 (caméra), un port réseau Gigabit (PHY), un USB 2.0 et 28 signaux GPIO. Les caractéristiques sont détaillées sur cette page. Les options sont nombreuses, pas moins de 32 déclinaisons étant proposées à la vente :
La carte peut être livrée avec ou sans gestion du réseau sans fil (Wi-Fi 5 et Bluetooth 5.0), de 1 à 8 Go de mémoire, un lecteur de carte microSD (Lite) ou 8 à 32 Go de stockage eMMC. Le tarif maximal affiché est ainsi de 90 dollars.
Pas de rétrocompatibilité, une nouvelle IO Board
Ses dimensions sont de 55 x 40 mm, son connecteur passe à 2x 100 broches plutôt que d'utiliser l'habituel DDR2 SO-DIMM. La compatibilité avec les anciens modèles et cartes d'accueil n'est plus de mise. Une nouvelle carte mère (IO Board) est donc aussi annoncée à 35 dollars, avec toute la connectique exploitable depuis ce module.
La disponibilité est annoncée comme immédiate. Un kit est aussi mis en vente pour ajouter une antenne aux versions avec réseau sans fil. L'équipe revient dans une vidéo sur ce nouveau projet :
Commentaires (25)
#1
“La compatibilité avec les anciens modèles et cartes d’accueil n’est plus de mise.”
Tout le concept tombe à l’eau….
#2
35$ pour la carte “mère” c’est une bonne nouvelle.
#3
Oui et non, il y arrive forcément un moment où à force d’ajouter des E/S, il faut évoluer. Par contre j’ai une pensée pour ceux qui ont investi dans un Turing Pi en se disant que ce serait rétrocompatible
#4
Je me demande si c’est pas au niveau de la consommation électrique que ça coince ?
Car il pourrait aussi sortir une version sodimm pour la rétrocompatibilité.
Surtout que cette nouvelles version est moins compacte.
#5
Depuis quand Jason Statham travaille chez Raspberry Pi ?
#6
Me demande si on pourra connecter une carte sata sur ce port PCIe. Et j’attends de voir les boîtiers qui pourraient aller avec.
#7
Il existe deja un adaptateur cm4 vers cm3 : https://www.cnx-software.com/2020/10/19/gumstix-introduces-cm4-to-cm3-adapter-carrier-boards-for-raspberry-pi-compute-module-4/amp/
#8
Et, très intéressant également, une “CM4 Development Board” qui utilise fort à propos le PCIe qui devient utilisable sur cette CM4 (contrairement à la PI4 normale, sans virer le contrôleur USB3 et bricoler) afin de proposer un slot M.2 utilisable par exemple pour un stockage (point faible récurrent des PI pour un usage embarqué/24-7).
Reste à Raspberry à offrir le support du démarrage sur un SSD M.2 car je doute que ce soit actuellement possible.
Mais au final, le problème de Raspberry c’est que leur carte devient trop puissante pour bien des usages (avec la chauffe/conso allant avec). Pour ma part, si je devais faire ma domotique orchestrée par un PI3 maintenant, je partirais sur une RockPI E avec un module eMMC: Aucun besoin de GPU (carte “headless”, OS sans support graphique installé), du GB filaire, capacités DDR variées afin de pouvoir monter de gros tmpfs pour la performance/préservation du stockage SSD… Pour du plus frugal, la version S est très bien aussi.
C’est bien de sortir tous les 2⁄3 ans une carte plus puissante au même prix, mais après quelques itérations, problème: On commence à sérieusement sortir du cadre de la carte pour l’enseignement ou les projets perso… et ça ne fait plus le job.
#9
C’est bien bien intéressant.
Ça permettrait d’avoir du SATA / M.2 avec le bus pci ?
#10
Il reste le pi zero ou les anciennes révision des CM.
#11
alors techniquement, maintenant que le boot usb est officiellement supporté, c’est théoriquement assez simple d’utiliser un ssd comme disque système (je dit “théoriquement” car je n’ai pas encore testé)
y’a même un boîtier qui intègre un bridge et un emplacement m.2 pour faire ça (Argon ONE M.2) (mais ça utilise un des usb3)
#12
Et si l’augmentation de la puissance permettait d’avoir plus de réalisations possible? Rien ne t’empêche de brider ton Pi4 CM , alors que c’est compliqué d’accélérer ton Pi3….
Je suis sûr qu’il y a des milliers d’étudiants, scientifiques ou bricoleurs à travers le monde ravis de l’augmentation de puissance, et de la possibilité de faire des clusters à foison pour un budget réduit :)
#13
Oui enfin attention quand même avec la notion de cluster à budget réduit. Parce que plusieurs RPi et ce qu’il faut pour les interconnecter, on arrive vite au budget d’un petit PC que tu peux utiliser comme hyperviseur et qui sera plus performant au bout du compte.
#14
Oui mais ça a deux avantages majeurs:
Quand tu vois que tu peux faire un routeur haute disponibilité pour 200 balles alors qu’un simple routeur en coute 500…. ben voilà quoi.
Alors des stockages S3, des load balancers, etc…. ça peut être trop cool.
#15
Le problème, c’est que ça n’utilise pas du tout la même route qu’un usb-storage (SCSI simplifié dédié à l’USB) et que le code supportant cela est totalement disjoint dans le noyau Linux et les boot loader (qui se basent en général sur une version simplifiée/hors OS du support Linux).
Donc que le boot sur USB (avec un bricolage pour attaquer un SSD M.2 Sata) soit supporté ne présage en rien de celui sur un SSD M.2 (PCIe), même si extérieurement ça se ressemble bin techniquement, justement, pas du tout!
#16
Le PI zéro n’a pas d’Ethernet filaire et on tombe trop juste en mémoire (surtout qu’avec juste la SD, les tmpfs sont la seule solution de la préserver… et font consommer de la RAM)… Et les anciennes révisions de CM arrêtent leur production quand la nouvelle sort et sont rapidement difficiles à trouver.
Mon PI3 qui gère la barque, fait alarme+gestion caméras, serveur DNS filtrant pour les PC des enfants… entre autres… peine déjà à dépasser les 15% de charge en crête, dépassant rarement quelques %!
Au moins il ne chauffe pas trop et, GPU totalement inutilisé, se contente de l’alimentation de l’USB de ma box… profitant au passage de sa batterie tampon 20V… le tout tenant thermiquement dans un meuble faiblement aéré.
Un PI4 serait encore plus bas en charge et obligerait à tout revoir niveau alim/disposition: Inadapté!
#17
je n’ai absolument pas dit le contraire hein, c’est juste que techniquement on peut utiliser un ssd m.2 sata comme disque système au lieu d’une µsd via l’usb
d’un point de vue “branchements” et “code dans le noyau” c’est effectivement probablement différent de passer via du pcie
d’un autre coté, je ne sais pas quels seraient les avantages d’un ssd directement en pcie sur un raspberry en fait (à part économiser un usb3, encore qu’ils semble qu’il n’y en ait pas sur la “carte mère” du cm4)
#18
Il y a des solution, mais le prix final risque de ne pas être intéressant.
Il n’y a pas une histoire de production garanti pendant n années ?
#19
Si vous voulez toutes les versions, regardez chez farnell/element14
exemple, pour la rpi2: https://fr.farnell.com/raspberry-pi/rpi2-modb-v1-2/sbc-raspberry-pi-2-model-b-v1/dp/2612474?st=Raspberry%20Pi%202%20Raspberry%20Pi
#20
Tout simplement passer d’une branche de code pour des périphériques annexes de sauvegarde-dépannage type clef USB à une autre pour les stockages internes. Avec ce que cela signifie de différence de déverminage poussés par la variété des matériels/charges/patch noyaux…
L’usb-storage, on tombait quand même sur pas mal de gags utilisé en stockage de base/racine quand on l’utilisait dans l’embarqué (eUSB) sur des SoC n’ayant pas de SATA…
#21
hum
merci de la réponse, mais je dois avouer ne rien avoir compris en fait :s
#22
Sur de l’usb-storage, à l’utiliser en mode “stockage interne”, on n’est absolument plus dans le cas d’usage type du genre (stockage externe amovible).
=> On tombe sur des bugs inhérents à des branches de code beaucoup moins utilisées donc déverminées, selon ce sur quoi on compile (surtout hors x86 en fait), les patch noyau qu’on ajoute (gare aux patchs Linux temps réel, en particulier, la possibilité de voir une tâche utilisateur préempter le noyau pose pb quand cela tombe mal avec certains contrôleurs de stockage USB). Sans compter que les contrôleurs côté stockage eux mêmes moins fiables (limitations matérielles, bugs firmware).
#23
ah, je crois piger (ou presque)
tu crains que la gestion du stockage usb soit moins fiable (coté OS) et/ou moins prioritaire que la gestion d’un stockage plus “natif” genre sata ou pciexpress en fait
j’ai bien résumé ?
mais l’uasp et ce genre de protocole est pas censé permettre que le disque soit contrôlé “en direct” par l’os sans passer par une “passerelle” ? (genre l’usb n’est plus là que comme “tunnel” de communication alors que sans l’uasp on tombe sur les périphériques “mass storage”, après on a peut-être toujours le souci que le process qui gère l’usb se fasse interrompre par un autre qui aurait une plus haute priorité ? à moins que l’uasp serve justement à augmenter la priorité du process “stockage” même à travers l’usb ?)
concernant les contrôleurs, j’avais utilisé un disque 8To en SMR, et je croyais que les problèmes que j’avais eu venaient de la forte sollicitation du disque sur les quelques jours avant qu’il lâche (qui dépassait les données constructeur), mais il semblerait que depuis qu’il a été changé de boîtier il tourne bien, ce qui va dans ton sens que les bridges usb/sata peuvent avoir des défauts (ou alors je suis tombé sur un exemplaire défaillant)
#24
Quand ton système écrit en USB:
Quand ton système écrit en stockage NVMe:
Moins d’intervenants, un canal de communication quasi direct, moins de bugs possibles, tout simplement ;)
L’USB n’est pas magique, c’est une surcouche. Et qui rajoute des surcouches rajoute des problèmes potentiels (0,1% du temps, mais ça suffit pour mettre le bronx dans un truc qui fonctionne très souvent).
#25
je suppose que ce que tu appelle “contrôleur disque” est le bridge usb<-> m.2 pour le coup
je comprend l’idée, cela dit avec le port pcie est-ce qu’on n’a pas le même nombre d’étapes qu’en usb ? on se retrouve pas avec un bridge “pcie <-> m.2” ? je sais bien qu’il existe des ssd m.2 au choix en pcie ou sata, mais est-ce que les cartes pcie sur lesquelles on peut brancher un ssd m.2 sont totalement passives (dans le sens pas de circuit électronique, il n’y a aucun composant ? que des piste pour un changement de connecteur ?)