URL: https://linuxfr.org/news/ordinateur-a-carte-unique-raspberry-pi-4-et-consort Title: Ordinateur à carte unique : Raspberry Pi 4 et consort Authors: freejeff Ysabeau 🧶, palm123, Nicolas Boulay, Davy Defaud, Benoît Sibaud, Anonyme, Claude SIMON, Arkem, BAud, Pierre Jarillon, Nils Ratusznik, ZeroHeure, j, zurvan, esdeem, alpha_one_x86, Tonton Th et Gawan Date: 2019年06月27日T11:59:39+02:00 License: CC By-SA Tags: raspberry_pi, architecture, embarqué, libreoffice, ubuntu, mpv et libretro Score: 80 À l’occasion de la sortie du Raspberry Pi 4, un ordinateur à carte unique (_Single Board Computer_ — SBC), il nous a semblé important de faire un point sur les cartes Raspberry qui se sont démocratisées à partir de 2010, et qui ont aujourd’hui des capacités suffisantes pour traiter l’ensemble des tâches courantes d’un ordinateur de bureau. ![Raspberry Pi 4](https://upload.wikimedia.org/wikipedia/commons/thumb/f/f1/Raspberry_Pi_4_Model_B_-_Side.jpg/320px-Raspberry_Pi_4_Model_B_-_Side.jpg) Les cartes fonctionnant directement à partir de bibliothèques C/C++ de type [Arduino](https://fr.wikipedia.org/wiki/Arduino), ou celles fonctionnant via un interpréteur dans un langage particulier ([MicroPython](https://fr.wikipedia.org/wiki/MicroPython)), ne seront pas traitées en profondeur dans cette dépêche. ---- [Description des entrées‐sorties du Raspberry Pi](https://www.raspberrypi.org/documentation/usage/gpio/README.md) [Radiateurs‐boîtiers pour Raspberry ](http://www.raspberrypiwiki.com/index.php/Armor_Case) [Les broches du connecteur GPIO](https://fr.pinout.xyz/pinout/wiringpi) ---- Commençons par présenter la petite nouvelle qui s’est longuement faite attendre. Wikipédia définit la Raspberry Pi comme étant un [nano‐ordinateur](https://fr.wikipedia.org/wiki/Nano-ordinateur) à [architecture ARM](https://fr.wikipedia.org/wiki/Architecture_ARM) conçu par des professeurs du département informatique de l’[[université de Cambridge]] dans le cadre de la [fondation Raspberry Pi](http://www.raspberrypi.org/). Elle est de la taille d’une carte de crédit, et est destinée initialement à encourager l’apprentissage de la programmation informatique. Elle permet l’exécution de plusieurs variantes du [système d’exploitation](https://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27exploitation) libre [[GNU]]/[[Linux]], notamment [[Debian]], et des logiciels compatibles. Les améliorations amenées par le nouvel opus de la Raspberry sont nombreuses, elles sont donc synthétisées dans le tableau 1. | Composants | Raspberry Pi 3 B+ | Raspberry Pi 4 | |:---------------------:|:-------------------------------:|:-------------------------------:| | Système monopuce (SoC)| Broadcom BCM2837B0 | Broadcom BCM2711 | | Type de cœurs | Cortex-A53 (ARMv8) 64 bits | Cortex-A72 (ARMv8) 64 bits | | Type de mémoire | DDR2 | DDR4 | | Nombre de cœurs | 4 | 4 | | Processeur graphique | VideoCore IV | VideoCore VI | | Fréquence processeur | 1,4 GHz | 1,5 GHz | | Mémoire vive | 1 Gio | 1 Gio, 2 Gio ou 4 Gio | | Ports USB | 4 ×ばつ USB 2.0 | 2 ×ばつ USB 3.0 + 2 ×ばつ USB 2.0 | | Ethernet | Gigabit sur USB 2.0 | Gigabit sur PCIe | | Port HDMI | 1 ×ばつ HDMI | 2 ×ばつ microHDMI | | Sortie son analogique | jack 3,5 mm | jack 3,5 mm | | GPIO | 26 max | 26 max | | PWM | 4 | 4 ? | | I2C | 1 | 4 | | SPI | 2 | 4 | | UART | 1 | 4 | | LCD Panel | ✓ | ✓ | | Caméra CSI | ✓ | ✓ | | Wi‐Fi | 2,4 GHz et 5 GHz 802.11b/g/n/ac | 2,4 GHz et 5 GHz 802.11b/g/n/ac | | Bluetooth® | 4.2, BLE | 5.0 | | Stockage | microSD | microSD | _**Tableau 1** : comparatif des Raspberry Pi 3 B+ et 4_ Bien que les périphériques de cette carte, présentés sur le **tableau 1**, permettent déjà un nombre d’usages très important, l’intérêt majeur de ce type de cartes par rapport à un PC est l’accès au [[GPIO]]. Cet accès privilégié à des bus tels qu’[I2C](https://fr.wikipedia.org/wiki/I2C), [SPI](https://fr.wikipedia.org/wiki/Serial_Peripheral_Interface) ou [UART](https://fr.wikipedia.org/wiki/UART), permet l’utilisation de tout matériel électronique ; nous avons donc vu fleurir depuis 2014 un nombre important de cartes d’extensions de fonctionnalités dénommées [HAT](https://www.raspberrypi.org/blog/introducing-raspberry-pi-hats/) (_**H**ardware **A**ttached on **T**op_). Nous proposons donc de faire un point sur les différents types d’usages. Pour chaque usage, nous évoquerons des alternatives existantes, avec leurs avantages et leurs limites. # Usage pédagogique # La carte Raspberry Pi se distingue de ses concurrentes, car elle a, dès le début, pris le parti de se positionner comme une carte dédiée à l’éducation de masse à l’informatique, l’électronique et la robotique. Ce positionnement a conduit à mettre en place une [certification](https://www.raspberrypi.org/training/picademy/) afin que des enseignants ou des passionnés puissent avoir une reconnaissance de la fondation sur leur compétence à transmettre le savoir technique autour de ces plates‐formes. Des entreprises telles que [Pi-Top](https://www.pi-top.com/) ont conçu des unités pédagogiques comme un [ordinateur portable permettant l’accès aux GPIO](https://accounts.pi-top.com/products/pi-top/), ou dernièrement une [plate‐forme modulable orientée robotique pour la version 4](https://www.pi-top.com/products/pi-top-4). # Bureautique et Web # Bien que l’on puisse considérer qu’il est possible de faire de la bureautique avec les précédentes générations de la Raspberry Pi, le fait de ne pouvoir utiliser qu’un seul écran était une vraie limitation. De plus, la navigation Internet pouvait assez rapidement s’avérer poussive à cause du manque de mémoire vive. Lancer plusieurs applications en simultané pouvait aussi être compliqué. De manière générale, l’ensemble de ces limitations est levé avec cette nouvelle version. L’ajout de mémoire vive (jusqu’à 4 Gio), ainsi que la possibilité de brancher deux écrans via les deux ports mini‐HDMI, font de cette plate‐forme un outil tout à fait adapté à un usage de bureautique classique, courriel, LibreOffice, navigateur Internet. On peut noter que dans cette gamme de prix, il existe les cartes [ROCK64pro](https://www.pine64.org/rockpro64/) et [Odroid](https://www.hardkernel.com/), qui permettent d’avoir accès à une très large palette de [systèmes d’exploitation](https://wiki.pine64.org/index.php/ROCKPro64_Software_Release#Armbian_Ubuntu_18.04_Bionic_Desktop_.5BmicroSD_.2F_eMMC_Boot.5D_.5B5.90.5D), ce qui en fait un choix très intéressant pour la bureautique. Il est cependant important de noter que la plupart des utilisateurs de bureautique aimeront avoir une solution plus finalisée, avec un boitier. Il existe donc un nombre très important de boîtiers pour les Raspberry Pi [1, 2 et 3](https://thepihut.com/collections/raspberry-pi-cases/Raspberry-Pi-3-Model-B), et on en trouve de plus en plus pour la 4 ([The Pi Hut](https://thepihut.com/collections/raspberry-pi-cases/Raspberry-Pi-4-Model-B)). Il ne fait pas de doute que des initiatives viendront créer de nouveaux boîtiers permettant de tirer pleinement parti des possibilités de cette carte. Le choix du boîtier doit être fait en tenant compte de la dissipation de chaleur qui, sans être globalement importante, est concentrée sur quelques circuits. Le taux de panne des Raspberry fonctionnant dans une ambiance chaude n’est pas négligeable. C’est pour cela que l’on trouve actuellement des solutions allant de petits radiateurs à coller sur les circuits à des boîtiers‐radiateurs en contact avec les circuits intégrés. Certains sont même équipés d’un ou deux ventilateurs. De manière générale, l’ensemble des cartes ARM ayant au moins 2 Gio de mémoire vive et étant compatible avec une distribution GNU/Linux pour ARM permettra de faire de la bureautique de manière satisfaisante. En revanche, il n’existe pas de boîtier pour toutes les cartes. Avant de passer aux autres usages, il est nécessaire d’expliquer les différences matérielles entre ces cartes et les machines PC compatibles. La section suivante présente les spécificités matérielles ainsi que les pièges à éviter pour pouvoir profiter des usages plus complexes que la navigation Web. # Matériel # ## Pilotes ## Les systèmes monopuces (_system on chip_ — SoC) destinés aux téléphones et aux ordinateurs à carte unique disposent généralement d’une unité de traitement graphique (GPU) initialement utilisée dans les jeux vidéo, les applications 3D (CAO, animation), mais aussi utilisée dans la majorité des environnements de bureau modernes pour les effets visuels. Mais il est aussi nécessaire de pouvoir décoder matériellement les flux vidéo via une unité spécialisée (VPU), car les processeurs ne sont souvent pas assez puissants pour le faire. De plus, ces cartes pouvant interagir avec le monde physique, comme présenté dans la section « Électronique, robotique, Internet des objets », il faut aussi être en mesure d’avoir accès aux entrées‐sorties. ### Quelle différence avec un PC ? ### Les périphériques sont connectés au processeur principal via un bus. Certains protocoles de bus supportent l’énumération (aussi appelée découverte), c’est‐à‐dire que le processeur central peut demander « quels dispositifs sont connectés à ce bus » et les dispositifs répondent avec des informations sur leurs type, fabricant, modèle et configuration dans un format standardisé. Avec ces informations, le système d’exploitation peut rapporter la liste des périphériques disponibles et décider quel pilote de périphérique utiliser pour chacun d’entre eux. Certains protocoles de bus ne prennent pas en charge l’énumération, et le processeur principal n’a aucun moyen de savoir quels périphériques sont connectés, à part deviner. Tous les bus PC modernes prennent en charge l’énumération, en particulier PCI (l’original ainsi que ses extensions et successeurs, tels que AGP et PCIe), sur lequel la plupart des périphériques internes sont connectés, USB (toutes versions), sur lequel la plupart des périphériques externes sont connectés, ainsi que [[FireWire]], [[SCSI]], toutes les versions modernes de ATA/SATA, etc. Les connexions de moniteur modernes permettent également de découvrir le moniteur connecté (HDMI, DisplayPort, DVI, VGA avec EDID). Ainsi, sur un PC, le système d’exploitation peut reconnaître les périphériques connectés en énumérant le bus PCI, et en énumérant le bus USB quand il trouve un contrôleur USB sur le bus PCI, etc. Notez que le système d’exploitation doit supposer l’existence du bus PCI et la manière de le sonder ; ceci est standardisé sur l’architecture du PC (« architecture PC » ne signifie pas seulement un processeur x86 : pour être un PC (moderne), un ordinateur doit aussi avoir un bus PCI et doit démarrer d’une certaine manière). De nombreux systèmes embarqués utilisent des bus moins sophistiqués qui ne prennent pas en charge l’énumération. C’était vrai sur PC jusqu’au milieu des années 1990, avant que le PCI ne dépasse l’ISA. La plupart des systèmes ARM, en particulier, ont des bus qui ne gèrent pas l’énumération. C’est également le cas de certains systèmes x86 embarqués qui ne suivent pas l’architecture PC. Sans énumération, le système d’exploitation doit savoir quels périphériques sont présents et comment y accéder. L’arborescence de périphériques (_Device Tree_) est un format standard pour représenter ces informations. La principale raison pour laquelle les bus PC prennent en charge la découverte est qu’ils sont conçus pour permettre une architecture modulaire dans laquelle des périphériques peuvent être ajoutés et supprimés, par exemple en ajoutant une carte d’extension dans un PC ou en connectant un câble sur un port externe. Les systèmes embarqués ont généralement un ensemble fixe de dispositifs et un système d’exploitation préchargé par le fabricant et qui n’est pas remplacé, de sorte qu’il n’est pas nécessaire de procéder à un dénombrement. Si vous souhaitez aller plus loin dans la compréhension de la construction d’un système d’exploitation sur des systèmes monopuces, François Mocq a écrit [un billet](https://www.framboise314.fr/un-point-sur-le-device-tree/) permettant de comprendre comment cela fonctionne. ### Quelles conséquences ? ### La principale conséquence de cette différence entre PC et ordinateur à carte unique est que, si le concepteur d’un appareil décide que son produit n’est destiné qu’à un usage précis et non pas une utilisation plus large, il sera alors très compliqué de faire fonctionner l’ensemble du matériel pour un usage autre que celui prévu initialement. On peut prendre l’exemple des boîtiers Android TV, disponibles à des prix attractifs, ayant des performances équivalentes voire meilleures que le Raspberry Pi 4 telle que le [H96 Max](https://www.dx.com/p/h96-max-rk3399-20ghz-4k-tv-box-android-4gb32gb-wifi-1000m-lan-bluetooth-2619191). Pour être capable de l’utiliser avec une distribution GNU/Linux, il faudra jouer avec des images venant de vendeurs de SBC tels que Orange Pi ou PINE64 et des développements communautaires comme Linux-Sunxi, mais il sera très difficile d’avoir accès à tous les périphériques, car des éléments du _Device Tree_ seront manquants. On voit donc que ce manque d’accès aux sources de ces boîtiers handicape fortement la réutilisation de ce type de matériel. Ce problème touche malheureusement également les ordinateurs à carte unique. Il n’est que très rarement spécifié si le matériel présent est utilisable. La plupart du temps, des images Android et GNU/Linux (Ubuntu pour la plupart) sont fournies, et si l’image Android permet d’exploiter la partie graphique, c’est souvent plus compliqué avec la distribution GNU/Linux (d’autant plus si l’on souhaite la garder à jour). Il n’est, en revanche, quasiment jamais spécifié si les entrées‐sorties sont disponibles et comment elles le sont. Par exemple dans la section « Électronique, robotique, Internet des objets », des bibliothèques sont citées, mais elles ne sont disponibles que pour très peu de cartes. Il faut donc comprendre qu’entre les fonctionnalités matérielles décrites et leur utilisation, il y a un monde. C’est précisément pour ces raisons qu’un débutant devra toujours s’orienter vers une carte ayant une grande communauté, dans le cas contraire, on rentre dans l’embarqué, et cela nécessite des compétences d’ingénieur dédiées à ce domaine, et cela peut être très décourageant pour les hobbyistes souhaitant faire un petit projet. Les activités PC modernes nécessitent donc le bon fonctionnement de deux composants périphériques : - l’unité de traitement graphique (GPU) ; - l’unité de traitement vidéo (VPU). Une autre conséquence est l’impossibilité de créer une image du noyau Linux universelle. Pour cela, celle‐ci devrait reconnaître sur quelle machine elle tourne. Or, sans moyen standard, il y a une forte probabilité de « casser » la puce (par exemple, en jouant sur des registres de commande d’horloge). Il n’existe ainsi aucun noyau Linux ARM qui démarre partout, à l’inverse d’un noyau Linux x86 classique. C’est d’ailleurs incompréhensible qu’ARM ne garantisse même pas un fonctionnement minimal (amorçage + un [[UART]] + une [horloge temps réel](https://fr.wikipedia.org/wiki/Horloge_temps_r%C3%A9el), et sans doute une configuration « correcte » de la mémoire vive) pour tester plus facilement une nouvelle puce, certains fabricants le proposent (par exemple le FEL mode d’Allwinner) mais ce n’est pas universel. #### Processeur graphique #### Bien qu’il soit possible d’utiliser une distribution GNU/Linux en utilisant le processeur pour l’affichage, la prise en charge de Mesa 3D n’est pas disponible pour tous les processeurs graphiques, ce qui oblige à repasser par [[LLVMpipe]], et donc le processeur, pour l’affichage. Lorsque les pilotes Mesa 3D ne sont pas disponibles, les environnements de bureau ne sont pas accélérés par le processeur graphique, il faut donc utiliser des environnements légers. Les processeurs Videocore IV/VI ont des pilotes disponibles directement sur Raspbian, les environnements de bureau traditionnels peuvent donc pleinement utiliser le processeur graphique. Pour les processeurs graphiques utilisant les puces Mali (quasiment tous les autres systèmes monopuces ARM), c’est plus compliqué. Il existe des pilotes libres pour la couche noyau, mais les pilotes pour l’espace utilisateur ne sont pas libres et donc livrés sous forme de binaires. Chaque pilote binaire est conçu pour une combinaison spécifique de système de d’exploitation (GNU/Linux ou Android), de plate‐forme matérielle, de génération de circuit graphique (4x0/T6x0/T7x0) et de technologie graphique (fbdev, X Window, Wayland ou SurfaceFlinger d’Android). Les plates‐formes sont parfois abandonnées, vous devrez donc peut‐être choisir une version plus ancienne pour obtenir un pilote qui fonctionnera sur un matériel plus ancien. Un pilote binaire devrait fonctionner avec un pilote du noyau publié en même temps, et jusqu’à quatre versions antérieures. Le pilote binaire vérifie la version de l’API du pilote du noyau au démarrage. ARM a abandonné le prise en charge de X Window dans ses versions postérieures à X11 version 16 (janvier 2017). C’est pénible, car c’est encore très utilisé. Seuls Wayland, fbdev et SurfaceFlinger sont aujourd’hui pris en charge. Cependant, tout n’est pas si sombre car la version 5.2 du noyau contient maintenant par défaut les pilotes libres compatibles avec ces processeurs. Ces pilotes ont été obtenus par rétro‐ingénierie, ils ne sont pas considérés comme étant stables. Mais ils permettent de faire fonctionner une grande palette de cartes sans avoir à galérer à trouver les bonnes versions du noyau pour le matériel à disposition. [Le billet de blog de Collabora du 5 août](https://www.collabora.com/news-and-blog/blog/2019/08/06/rockpi-panfrost-wayland/), montre d’ailleurs des progrès énormes sur la prise en charge de ces processeurs. Sur le système monopuce RK3399, qui est très populaire aujourd’hui, les environnements graphiques, GNOME Shell et Plasma sont maintenant compatibles par défaut. Il est donc possible de faire fonctionner KDE et GNOME sur ce type de matériel en n’utilisant que des logiciels libres ! Pour les nombreux appareils moins récents ou plus modestes à base des vénérables circuits graphiques Mali4*0 (génération [[Utgard]]), le pilote libre tant attendu nommé Lima est lui aussi en bonne voie. ## Performances thermiques ## Plus les cartes ont des processeurs rapides et puissants, et plus le dégagement thermique est important. Si les précédentes versions de Raspberry Pi permettaient de ne pas trop se soucier de la dissipation pour la plupart des cas d’usage, la dernière version nécessite de travailler ce sujet. C’est d’ailleurs tout aussi vrai pour les cartes ARM puissantes, comme les [[Odroid]] qui nécessitent un dissipateur thermique pour pouvoir fonctionner de manière optimale. Un point intéressant est que, si ces cartes ne sont pas refroidies correctement, il n’y a pas de danger particulier mais en revanche un abaissement automatique de la fréquence des processeurs (_throttling_) est activé. Afin d’obtenir des performances optimales, il convient donc de traiter ce problème. Cela peut se faire directement sur la carte avec un [refroidissement actif de type « ventirad »](https://thepihut.com/collections/raspberry-pi-cases/products/dual-fan-heatsink-case-for-raspberry-pi-4), mais également par une dissipation passive [sur la carte](https://thepihut.com/collections/raspberry-pi-cases/products/aluminium-heatsink-case-for-raspberry-pi-4) ou via un [boîtier en aluminium faisant contact avec le processeur](https://thepihut.com/collections/raspberry-pi-cases/products/flirc-raspberry-pi-4-case). [Phronix](https://www.phoronix.com/scan.php?page=article&item=raspberrypi-4-cooling&num=1) a fait des tests avec ventilateur, « ventirad » et boîtier de dissipation passive, et seules les deux dernières options permettent de ne jamais activer l’abaissement de fréquence. # Vidéo # L’usage multimédia fait partie des usages les plus problématiques de ces cartes. La Raspberry Pi 3B+ n’est clairement pas taillée pour les plus exigeants ou pour l’avenir proche, car elle n’est pas capable de gérer des flux 4K en décodage matériel, ce qui ne permet pas l’utilisation des vidéos 4K. De plus, s’il est possible d’avoir des performances acceptables jusqu’en 1080p pour le codec H.264, cela ne peut se faire qu’au travers du logiciel OMXPlayer. Une version de [VLC](https://www.raspberrypi.org/forums/viewtopic.php?t=227185#p1393388), prenant en compte le décodage matériel du videocore IV, a été publiée en novembre 2018 ; elle semble donner satisfaction à ses utilisateurs. Bien que l’on puisse se dire que cela peut toujours être intéressant, il est possible de trouver des [solutions toutes prêtes pour le multimédia pour moins de 30 €](https://fr.aliexpress.com/item/33014928441.html?spm=a2g0o.productlist.0.0.4a14690ft3mFHK&s=p&algo_pvid=48b7175b-3bea-4cde-b6ca-49e7137de90a&algo_expid=48b7175b-3bea-4cde-b6ca-49e7137de90a-2&btsid=ecd9b6e5-6a11-45b4-a5f0-bcfd77cc3470&ws_ab_test=searchweb0_0%2Csearchweb201602_4%2Csearchweb201603_53) qui se basent sur Android. À l’instar des solutions pour l’Internet des objets, la question du suivi logiciel et, intrinsèquement de la sécurité, va se poser si l’objectif est aussi de relier l’appareil à Internet, ainsi que la question de la protection des données personnelles et du « Bigdata ». Si le but recherché est donc uniquement le multimédia, la question de l’utilisation d’une Raspberry Pi ne se pose pas, celle‐ci n’est pas intéressante. Si l’on souhaite en revanche avoir une solution GNU/Linux non Android, la version 4 avec au moins 2 Gio de mémoire vive est une solution très pertinente. Il faudra néanmoins s’armer de patience, car la prise en compte de l’accélération matérielle par les distributions dédiées nécessite encore de la mise au point. Si l’on compare à la ROCKPro64 précédemment présentée dans la section bureautique, il semble que les versions des logiciels de lecture vidéo tels que mpv ou VLC par défaut, ne sont pas compilées avec l’accélération matérielle, il faut donc le faire [manuellement](https://forum.pine64.org/showthread.php?tid=7112). Ce n’est clairement pas un bon point pour cette carte. Les cartes de chez Odroid sont, elles, livrées avec des lecteurs permettant d’exploiter l’accélération matérielle pour le décodage, mais pas forcément VLC ou mpv. Il est cependant à noter que le travail de PINE64 autour de la création d’un téléphone et d’un ordinateur portable basés sur l’architecture de la ROCKPro64 les a conduits à travailler à mettre en place l’ensemble des briques applicatives libres pour une utilisation optimale. Il est très probable que l’ensemble des développements faits pour le portable et le téléphone mobile conduise à une distribution dédiée qui bénéficiera également à la carte ROCKPro64. Les développements faits par PINE64 mériteraient une dépêche à eux seuls. Il existe une autre entreprise qui semble donner satisfaction à un grand nombre d’utilisateurs : Hardkernel, qui produit les Odroid. Dans les cartes permettant de bonnes performances en multimédia on notera la XU4 et la N2, la N2 étant plus performante. Il est à noter que ces cartes coûtent souvent plus cher que le prix affiché, du fait des frais de douane. Les revendeurs européens sont bien plus chers. La carte N2 est livrée avec une Ubuntu 18.04 ainsi que tous les pilotes graphiques et accélérateurs permettant les jeux 3D et la lecture de vidéos 4K H.265. Si elle avait de réels arguments à sa sortie, sa faible disponibilité en Europe, couplée à une équivalence en termes de VPU, la rend aujourd’hui moins intéressante face à la Raspberry Pi 4. Peut‐être que l’utilisation d’un processeur graphique Mali permettra de faire une différence sur la partie _retrogaming_, pour les jeux 3D, mais on ne peut pas le savoir aujourd’hui, car il n’existe pas de comparatifs exhaustifs. Il existe aussi des alternatives plus chères à base de processeurs X86-64, telles que les cartes [UDOO X66 II](https://www.udoo.org/udoo-x86/) dont le prix de base commence à 174 €. Comme ces cartes utilisent des processeurs d’ordinateurs portables, elles n’autorisent pas l’accès aux GPIO, ainsi elles ajoutent des processeurs d’Arduino pour permettre l’interaction avec le monde extérieur. Cette carte est basée sur un _[[Accelerated processing unit]]_ Intel N3160 (circuit graphique Intel HD 400, dont les performances ne sont pas transcendantes). Elles n’auront cependant aucune difficulté à faire ce que font toutes les cartes ARM en termes de bureautiques multimédia et jeu, mais pour un prix deux à trois fois supérieur. Mais, comme l’ensemble de la chaîne logicielle est libre (circuit graphique Intel, Arduino Leonardo), il est facile de mettre à jour la distribution, ce qui évite à coup sûr l’obsolescence qui peut faire peur sur des cartes ARM. À noter également qu’UDOO vient de basculer chez AMD avec sa plate‐forme embarquée APU Ryzen V1000 qui, avec le processeur graphique Vega, a des performances graphiques bien supérieures à celles que l’on peut trouver sur les processeurs graphiques Intel HD. UDOO a financé ses développements sur une campagne [KickStarter](https://www.kickstarter.com/projects/udoo/udoo-bolt-raising-the-maker-world-to-the-next-leve/updates) et entre en [phase de production](https://www.kickstarter.com/projects/udoo/udoo-bolt-raising-the-maker-world-to-the-next-leve/posts/2570565). Lorsque l’on commence à vouloir faire un serveur multimédia, il est souvent envisagé d’utiliser des distributions dédiées. Il existe plusieurs distributions spécialisées comme [LibreElec](https://libreelec.tv/), [OpenElec](https://openelec.tv/) et [OSMC](https://osmc.tv/). Cette dernière ayant un magasin d’applications, ou _app store_, pour rajouter des greffons (_plug‐ins_). Ces distributions sont basées sur le gestionnaire multimédia [Kodi](https://kodi.tv). Il est possible de l’installer directement depuis Raspbian, mais aussi de l’avoir directement dans [EmulationStation](https://emulationstation.org/) via [RetroPie](https://retropie.org.uk/), [Recalbox](https://www.recalbox.com/fr/) ou [batocera.linux](https://batocera-linux.xorhub.com/). Si l’on ne veut faire que du multimédia, alors ces distributions spécialisées sont à préférer, car elles optimisent au mieux la gestion des ressources. # Audio # La carte Raspberry Pi 4 n’est, en revanche, pas du tout prévue pour l’audio par défaut. Bien qu’il soit possible d’installer des [HAT](https://www.hifiberry.com/shop/boards/hifiberry-dac-adc/) dédiés, la sortie par défaut est un [modulateur de largeur d’impulsions](https://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion) (PWM) filtré qui ne satisfera pas grand monde, et il n’y a pas du tout d’entrée son (contrairement à ce que la concurrence propose, parfois depuis longtemps à la vue des cartes et appareils basés sur un Allwinner A10 ou A20). Après, il semble nécessaire de relativiser. Car que ce soit avec des ordinateurs monocartes ou même avec des cartes‐mères de PC, les gens exigeants quant à la qualité sonore privilégieront des convertisseurs numérique‐analogique (DAC) ou analogique‐numérique (ADC) externes connectés via l’USB ou les différents protocoles de communication accessibles via les GPIO. Il est simplement regrettable de ne pouvoir se reposer sur l’implémentation par défaut que dans de très rares occasions. Avec ses GPIO, ses ports USB et la sortie audio via HDMI, cela reste tout de même un outil facilitant la création de matériel Hi‐Fi connecté. Ainsi, on trouve beaucoup d’exemples de matériel audio à faire soi‐même ([[DIY]]) conçus à partir de Raspberry Pi. J’ai trouvé que [ce projet](https://cloriou.fr/2018/04/04/creer-chaine-hi-fi-diy-raspberry-pi-materiel-utilise/), assez didactique, méritant d’être mentionné. # Rétrogaming # Bien que l’émulation de jeux vidéo soit un sujet [complexe quant à sa légalité](https://www.millenium.org/news/132859.html), il a permis à des jeunes générations de découvrir les jeux de leurs parents (voire de leurs grands‐parents). Présenter ici les techniques d’émulation conduirait à un exposé bien trop long, il est cependant évident qu’émuler une Wii ou une NES ne demandera pas les mêmes performances. Jusqu’ici la Raspberry Pi pouvait émuler l’ensemble des consoles 8 bits, la PlayStation et parfois quelques jeux de consoles plus récentes. Bien que la version 4 soit plus puissante, il n’est pas du tout certain que l’ensemble des jeux des consoles telles que la Nintendo 64 ou la DreamCast (naomi/atomisware) soit émulé de manière fluide, mais il y a déjà eu des tests montrant des résultats intéressants sur ces consoles. Pour accéder à l’émulation avec ce genre de cartes, il est possible d’installer [RetroPie](https://retropie.org.uk/), qui permet d’aller chercher l’ensemble des dépôts de [Libretro](https://www.libretro.com/) et de compiler les logiciels pour les rendre disponibles dans le superviseur [EmulationStation](https://emulationstation.org/). C’est un processus très long, car la compilation des différents émulateurs est gourmande même sur un PC X86-64. Il est également possible d’installer des distributions prévues pour l’émulation telles que [Recalbox](https://www.recalbox.com/fr/), ou [batocera.linux](https://batocera-linux.xorhub.com/). Il est évident que les solutions à base d’APU X86-64 présentées dans la section multimédia, seront plus performantes que les solutions ARM, mais la gamme de prix n’est pas du tout la même. # Électronique, robotique, Internet des objets # C’est, pour moi, le point qui a fait de cette carte un succès, voire une révolution. Nous avions déjà vécu la révolution [Arduino](https://www.arduino.cc/), qui permet, avec un [EDI](https://fr.wikipedia.org/wiki/Environnement_de_d%C3%A9veloppement "environnement de développement intégré") simplifiant l’édition de code source, la compilation et le téléversement vers le microcontrôleur, de mettre à la disposition de personnes non expertes en informatique embarquée, une solution permettant de contrôler des actionneurs et de mesurer à l’aide de capteurs pour ainsi créer un environnement idéal pour le [[DIY]] et l’Internet des objets. Cependant, bien que faire des petits projets soit assez simple, dès que l’on veut faire des projets plus élaborés, cela se complique sérieusement. Ces microcontrôleurs étant monocœurs, il n’est pas forcément possible de simplement définir plusieurs tâches. Il existe des bibliothèques pour simplifier l’utilisation, mais il y a beaucoup de fonctions bloquantes qui rendront les choses complexes. De plus, ces cartes n’ont pas une très grande puissance de calcul et des capacités mémoire restreintes ; on peut donc atteindre leurs limites bien plus rapidement. Elles ont, en revanche, l’avantage d’être totalement préemptives. Si l’on accepte que la criticité des tâches à effectuer n’est pas élevée, alors le fait de perdre le temps réel (l’aspect préemptif) par l’utilisation d’un noyau Linux rend la carte Raspberry Pi excellente pour le prototypage et l’interaction avec le monde réel. Tout d’abord, contrairement à l’écosystème Arduino où la programmation se fait en C++, une très grande partie des ressources pédagogiques autour de la gestion des GPIO avec la Raspberry Pi se fait en Python grâce à la bibliothèque RPi.GPIO. Ainsi, changer périodiquement l’état d’une sortie numérique est aussi simple que : ```python import RPi.GPIO as GPIO # importation du module RPi.GPIO from time import sleep # importation de la fonction sleep GPIO.setmode(GPIO.BCM) # choix BCM or BOARD GPIO.setup(24, GPIO.OUT) # régler GPIO24 comme sortie try: while True: GPIO.output(24, 1) # régler GPIO24 to 1/GPIO.HIGH/True sleep(0.5) # Attendre une demi‐seconde GPIO.output(24, 0) # régler GPIO24 à 0/GPIO.LOW/False sleep(0.5) # Attendre une demi-seconde except KeyboardInterrupt: # Inteception de l’interruption de clavier CTRL+C GPIO.cleanup() ``` L’approche de RPi.GPIO est très proche du matériel, il n’y a quasiment pas d’abstraction, elle est donc extrêmement intéressante d’un point de vue pédagogique, mais nécessite de solides connaissances pour l’utiliser efficacement. En tant que mécanicien, je dois trouver des solutions pour réaliser des tâches de mouvement (mon travail consiste plutôt dans la destruction de la matière par le mouvement), j’étudie donc souvent comment faire pour réussir à trouver des solutions pas chères pour faire ces tâches de mouvement. Aujourd’hui, les actionneurs les moins chers sont les moteurs pas à pas. Leur électronique de commande impose d’envoyer un train de créneaux dont la fréquence définira le nombre de pas par seconde. Des outils dédiés existent, car ils sont aussi utilisés pour la motorisation des imprimantes 3D, mais si l’on veut le faire avec une Raspberry Pi, il y a évidemment une bibliothèque pour cela. La bibliothèque [GPIO Zero](https://gpiozero.readthedocs.io/en/stable/) permet de réaliser une quantité énorme d’opérations sur les GPIO, contrairement à la bibliothèque RPi.GPIO, qui permet d’écrire du code qui traite des broches et de l’état des broches. GPIO Zero fait généralement référence à des périphériques comme des [diodes électroluminescentes](https://fr.wikipedia.org/wiki/Diode_%C3%A9lectroluminescente "diode électroluminescente") (LED) ou des boutons plutôt qu’aux broches d’entrée et de sortie. GPIO Zero fournit des classes qui représentent les périphériques, donc au lieu d’avoir un numéro de broche et de lui dire d’activer la sortie numérique, vous avez une LED et vous lui dites de s’allumer et, au lieu d’avoir un numéro de broche et de demander si elle est allumée ou éteinte, vous avez un bouton et demandez s’il est pressé. Cette bibliothèque permet notamment de piloter directement un moteur depuis la Raspberry Pi : ```python import time import sys from gpiozero import OutputDevice as stepper IN1 = stepper(12) IN2 = stepper(16) IN3 = stepper(20) IN4 = stepper(21) stepPins = [IN1,IN2,IN3,IN4] # Motor GPIO pins

stepDir = -1 # Set to 1 for clockwise # Set to -1 for anti-clockwise mode = 1 # mode = 1: Low Speed ==> Higher Power # mode = 0: High Speed ==> Lower Power if mode: # Low Speed ==> High Power seq = [[1,0,0,1], # Define step sequence as shown in manufacturers datasheet [1,0,0,0], [1,1,0,0], [0,1,0,0], [0,1,1,0], [0,0,1,0], [0,0,1,1], [0,0,0,1]] else: # High Speed ==> Low Power seq = [[1,0,0,0], # Define step sequence as shown in manufacturers datasheet [0,1,0,0], [0,0,1,0], [0,0,0,1]] stepCount = len(seq) if len(sys.argv)>1: # Read wait time from command line waitTime = int(sys.argv[1])/float(1000) else: waitTime = 0.004 # 2 miliseconds was the maximun speed got on my tests stepCounter = 0 while True: # Start main loop for pin in range(0,4): xPin=stepPins[pin] # Get GPIO if seq[stepCounter][pin]!=0: xPin.on() else: xPin.off() stepCounter += stepDir if (stepCounter>= stepCount): stepCounter = 0 if (stepCounter < 0): stepCounter = stepCount+stepDir time.sleep(waitTime) # Wait before moving on ``` _Trouvé sur [instructables.com](https://www.instructables.com/id/Playing-With-Electronics-Raspberry-GPIO-Zero-Libra/)._ Un point vraiment intéressant pour la nouvelle Raspberry Pi est qu’il y a eu une nette amélioration de la vitesse de commutation des entrées‐sorties. La figure ci‐dessous montre l’évolution de la vitesse de commutation d’une sortie numérique : ![évolution de la vitesse de commutation d’une sortie numérique](https://linuxfr.org/images/historique/images_perdues/ordinateur-a-carte-unique-raspberry-pi-4-et-consort-2019-06-21-15_41_32-Window.png) On constate une augmentation d’un facteur 3, qui est très probablement due à l’utilisation de nouveaux cœurs ARM. Il est clair que lorsque l’on veut faire des projets qui nécessitent plusieurs capteurs, alors avoir une commutation plus rapide est un avantage certain. Bien que la bibliothèque GPIO Zero permette de faire beaucoup, elle ne s’occupe pas de l’I2C et du SPI. Afin de permettre au plus grand nombre de facilement utiliser des capteurs, Adafruit a développé une bibliothèque appelée [Blinka](https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/installing-circuitpython-on-raspberry-pi) qui permet de faire fonctionner l’ensemble des capteurs et actionneurs qu’il a développés pour ses cartes fonctionnant sous [CircuitPython](https://learn.adafruit.com/welcome-to-circuitpython/what-is-circuitpython) (interpréteur Python pour microcontrôleur, simplifiant grandement la programmation). L’ensemble des capteurs et actionneurs disponibles pour sur Adafruit est très important, ce qui peut grandement réduire le coût de développement d’un prototype ! Pour utiliser des convertisseurs analogiques‐numériques, il existe des cartes filles comme [celle de WaveShare](https://www.amazon.fr/Waveshare-Raspberry-AD-Board-High-Precision/dp/B00ZZGDL32/ref=asc_df_B00ZZGDL32/?tag=googshopfr-21&linkCode=df0&hvadid=51048574806&hvpos=1o1&hvnetw=g&hvrand=11630872363865146702&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9055774&hvtargid=pla-274470144622&psc=1) présentée ci‐dessous : ![**Figure carte WaveShare**](https://www.waveshare.com/img/devkit/accBoard/High-Precision-AD-DA-Board/High-Precision-AD-DA-Board-5.jpg) Mais il est possible d’en utiliser de [beaucoup moins chers](https://www.adafruit.com/product/1083), l’avantage de la Raspberry, c’est que l’on a directement accès aux GPIO, et l’avantage de l’Adafruit, c’est qu’il y a un pont avec CircuitPython. # Serveur de stockage et passerelle Internet # Quand elles sont équipées d’une connectique réseau et de stockage suffisant, les cartes ARM peuvent aussi faire des serveurs domestiques intéressants de par leur faible consommation électrique. Une carte à base de système monopuce A20 ([OLinuXino MICRO](https://www.olimex.com/wiki/A20-OLinuXino-MICRO#Linux), [Banana Pi M1](http://www.banana-pi.org/m1.html)) suffit à synchroniser les contacts, les agendas et les fichiers de tablettes et smartphones familiaux avec un ordinateur de sauvegarde en utilisant ownCloud (et certainement Nextcloud — non testé). Pour un vrai _cloud_ familial entre ordinateurs avec le même logiciel, un système monopuce un peu plus puissant, comme le R40 ([Banana Pi M2U](http://www.banana-pi.org/m2u.html)) s’en sort sans latence sensible. Même l’interface Web plutôt lourde pour le A20 passe ici très correctement. Certaines cartes disposant d’Ethernet Gigabit et de plusieurs ports SATA, comme la [Banana Pi R2](http://www.banana-pi.org/r2.html), la Marvell Expressobin ou la [ROCKPro64](https://www.pine64.org/rockpro64/), avec sa carte d’extension SATA, permettent de faire un serveur de stockage en réseau (NAS) avec RAID logiciel. Enfin, des logiciels de supervision comme Munin ou Zabbix (Nagios non testé) sont tout à fait utilisables pour surveiller un petit réseau local, du moment que le nombre de machines n’est pas trop élevé.