À 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.
Les cartes fonctionnant directement à partir de bibliothèques C/C++ de type Arduino, ou celles fonctionnant via un interpréteur dans un langage particulier (MicroPython), ne seront pas traitées en profondeur dans cette dépêche.
Sommaire
- Usage pédagogique
- Bureautique et Web
- Matériel
- Vidéo
- Audio
- Rétrogaming
- Électronique, robotique, Internet des objets
- Serveur de stockage et passerelle Internet
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 à architecture ARM conçu par des professeurs du département informatique de l’université de Cambridge dans le cadre de la fondation Raspberry Pi.
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 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 ? |
| I²C | 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’I²C, SPI ou 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 (Hardware Attached on Top).
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 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 ont conçu des unités pédagogiques comme un ordinateur portable permettant l’accès aux GPIO, ou dernièrement une plate‐forme modulable orientée robotique pour la version 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 et Odroid, qui permettent d’avoir accès à une très large palette de systèmes d’exploitation, 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, et on en trouve de plus en plus pour la 4 (The Pi Hut). 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 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. 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, 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, 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 », mais également par une dissipation passive sur la carte ou via un boîtier en aluminium faisant contact avec le processeur. Phronix 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, 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 € 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. 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 Ⅱ 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 et entre en phase de production.
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, OpenElec et OSMC. 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. Il est possible de l’installer directement depuis Raspbian, mais aussi de l’avoir directement dans EmulationStation via RetroPie, Recalbox ou batocera.linux. 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 dédiés, la sortie par défaut est un modulateur de largeur d’impulsions (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, 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é, 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, qui permet d’aller chercher l’ensemble des dépôts de Libretro et de compiler les logiciels pour les rendre disponibles dans le superviseur EmulationStation. 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, ou batocera.linux. 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, qui permet, avec un EDI 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 :
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 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 (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 :
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</p><p>
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 onTrouvé sur instructables.com.
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 :
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’I²C 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 qui permet de faire fonctionner l’ensemble des capteurs et actionneurs qu’il a développés pour ses cartes fonctionnant sous 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 présentée ci‐dessous :
Mais il est possible d’en utiliser de beaucoup moins chers, 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, Banana Pi M1) 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) 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, la Marvell Expressobin ou la 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é.
Aller plus loin
- Description des entrées‐sorties du Raspberry Pi (136 clics)
- Radiateurs‐boîtiers pour Raspberry (280 clics)
- Les broches du connecteur GPIO (185 clics)
# Dissipation thermique
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
On pense toujours au CPU mais ce n'est pas le seul circuit à considérer. Il y a aussi un circuit plus petit situé près des connecteurs USB et un autre au-dessous de la carte dont la température est élevée. J'ai utilisé des Pi 3 B et B+, pas encore le Pi 4 dont la dissipation thermique est encore plus élevée.
Sans radiateurs additionnels, un Raspberry mis dans un local où la température peut dépasser 40°C tombe en panne à coup sûr. On me l'avait dit et j'ai pu en faire moi aussi l'expérience. J'ai essayé les petits radiateurs à coller sur les chips. Certes, on améliore la surface de refroidissement, c'est beaucoup mieux que rien mais je crains qu'un radiateur ne se décolle avec le temps. De plus, le chip du dessous n'est pas pris en compte. La température donnée par /opt/vc/bin/vcgencmd measure_temp est de 45°C pour le Pi 3 B+ qui est à côté de moi pour une température ambiante de 24°C. Les radiateurs m'ont fait gagner 5°C. C'est bien mais est-ce toujours suffisant ?
La solution du boitier-radiateur me parait de loin préférable. Le lien donné en fin d'article correspond au Pi 3 et donne un lien pour le Pi 4 . Le risque de décollement n'existe plus avec ce boitier et tous les circuits sensibles sont pris en compte. On peut trouver ces boitiers avec ventilateurs ou statiques dans la gamme 9€ à 16€ selon le circuit de vente et que l'on est pressé ou pas de les acquérir.
[^] # Re: Dissipation thermique
Posté par freejeff . Évalué à 5.
Oui, la dissipation thermique n'est jamais à prendre à la légère dans des environnements fermés.
Il est certain que pas mal de puces sur ces cartes chauffent, mais c'est bien souvent le SoC qui va poser des problèmes à l'usage. La températures des autres puces risque par contre de conduire à une panne.
J'ai mis un lien vers un distributeur qui a déjà pas mal de boîtiers pour Rpi4 dans la dépêche (lien appelé thepihut).
[^] # Re: Dissipation thermique
Posté par Anonyme . Évalué à 5.
Tout dépend du datasheet de ces différents circuits. Comme l'a dit Jeff, bien souvent le composant le moins tolérant au niveau thermique c'est le SoC et c'est pas pour rien qu'il possède un mécanisme interne de bridage.
Après, n'importe quelle puce de semi-conducteur qui atteint sa température de jonction maximale a de grandes chances de faillir rapidement.
Compliqué dans ce genre de cas de ne reposer que sur la convection naturelle. Une ventilation active même faible fera souvent un meilleur travail de dissipation. J'ai opté pour récupérer des ventilateurs de PC de 80mm que j'alimente en 5V, ça suffit pour un modem ou un tel ordinateur monocarte sans avoir de nuisances sonores.
Il reste un problème. En utilisant les trous de fixation de la carte avec ces radiateurs-boitiers, il devient difficile de fixer le tout sur un chassis ou dans une armoire informatique.
Pour moi, l'idée d'un grand radiateur est bonne (c'est ce qui est régulièrement utilisé sur les cartes graphiques, dans des systèmes de signalisation ou encore les alimentations télécom) mais le design de ces dissipateurs pourrait être revu.
# double-écran - utilisation à l'extérieur
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 22 août 2019 à 14:22.
L'utilisation en double écran était déja possible (à condition de ne pas dépasser du 1080p). Je l'ai vu sur des thinclients à base de raspberry, le second port hdmi étant fourni par une raspberry pi zero connectée via usb à la raspberry 3.
Moi je suis à la recherche d'info pour l'utilisation de raspberry pi à l'extérieur, à l'ombre mais dans un climat assez chaud (Andalousie). Des pistes ? Existe t-il des boitiers dédiés à une utilisation extérieure avec refroidissement passif correct? Pour l'instant je n'ai trouvé que des nuc-likes industriels fort onéreux.
[^] # Re: double-écran - utilisation à l'extérieur
Posté par freejeff . Évalué à 2.
Pour le double écran, je n'avais jamais entendu parler de faire transiter la vidéo via de l'USB2 pour aller vers l'hdmi d'une autre carte, si tu as des refs, je suis preneur.
En ce qui concerne l'utilisation en extérieur, ce genre de produit ne fait pas l'affaire ?
[^] # Re: double-écran - utilisation à l'extérieur
Posté par damaki . Évalué à 3.
C'est étanche et en plastique, soit exactement pas ce qu'il ou elle veut pour dissiper la chaleur.
[^] # Re: double-écran - utilisation à l'extérieur
Posté par Anonyme . Évalué à 2.
L’étanchéité est tout de même un critère important, même en climat assez sec, car l'humidité et la condensation peuvent vite détruire les circuits. On parle d'une carte qui ne possède pas de vernis de tropicalisation.
Sinon il existe ceci pour la RockPro64.
[^] # Re: double-écran - utilisation à l'extérieur
Posté par Psychofox (Mastodon) . Évalué à 3.
Oui effectivement j'avais vu quelques bricolages à partir de boitier electriques étanches générique mais ça ne tient la route que dans des climats propices ou utilisation très peu cpu intensive. Ce dernier boitier semble mieux correspondre. idéalement il faudrait avoir un contact entre la puce et le boitier pour maximiser la dissipation thermique. Merci pour le lien.
[^] # Re: double-écran - utilisation à l'extérieur
Posté par Anonyme . Évalué à 3.
Vu que la RockPro64 dispose de trous de fixation pour un radiateur, il me semble peu complexe d'usiner un bloc d'alu qui viendrait affleurer l'intérieur du couvercle du boitier. Avec des pads thermiques ça pourrait faire le job.
Sur un Raspberry ça serait plus compliqué à usiner et plus coûteux mais comme dit plus haut ça couvrirait l'ensemble des composants de la face supérieure.
[^] # Re: double-écran - utilisation à l'extérieur
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Une autre solution est mettre un ventilateur pour brasser l'air à l'intérieur du boitier métallique. L'inconvénient est le risque de panne du ventilateur.
[^] # Re: double-écran - utilisation à l'extérieur
Posté par Psychofox (Mastodon) . Évalué à 5.
J'ai juste ouvert par cuirosité le boitier d´un thin clearcube qu'on avait en POC et qui fournissait le double écran :
https://www.clearcube.com/c3xpi/
Mais je n'ai pas été dumper l'OS qui tournait sur les deux cartes ni étudié en détail comment ça se passait. Je sais juste que les deux cartes étaient reliées par les pins d'un port usb. Celui qui a un cache sur le boitier pour éviter qu'on l'utilise en même temps:
Aucune idée si c'est du code proprio ou pas qui faisait le lien, j'ai changé de boite entre temps.
# C sur Raspberry
Posté par harlock974 . Évalué à 10.
Merci Jeff pour ce compte rendu très complet.
Concernant la programmation du Raspberry Pi et de son GPIO, je trouve un peu dommage la prééminence donnée au langage Python, rendant difficile la recherche de documentation sur les librairies C correspondantes. Cela peut se comprendre du point de vue pédagogique, mais si l'on a besoin d'une rapidité accrue, utiliser des programmes C compilés peut être un avantage.
Trois liens intéressants sur la programmation C sur Raspberry :
[^] # Re: C sur Raspberry
Posté par freejeff . Évalué à 6.
Merci du complément !
C'est vrai que j'aurai du faire l'effort de faire le recensement des bibliothèques pour les autres langages dont le C, mais j'évite au maximum le C et préfère le python.
En ce qui concerne la vitesse, je pense que pour la plupart des script pour les I/O cela ne doit pas faire beaucoup de différences. Par exemple, on voit que gpiozero arrive à du 50kHz, je ne suis pas sûr que le même exercice en WiringPi aille plus vite, mais je peux me tromper !
Après pour les choses plus compliquées, beaucoup de bibliothèques python efficaces sont disponibles via pip pour python sur RPi, donc il y a moyen d'avoir des codes bien efficaces, tant qu'il n'y a pas trop de boucles imbriquées ! Et vu qu'en plus aujourd'hui avec les nouvelles versions de pythran on doit pouvoir l'utiliser sur RPi, cela fait pas mal d'atout à ce langage, pour les cibles dans mon genre, qui ne sont pas fan de la verbosité et complexité liés aux développements en C/C++.
[^] # Re: C sur Raspberry
Posté par David Marec . Évalué à 8.
On peut aussi préciser que l'on peut manipuler les «pins» du rpi avec des commandes shell.
En gros:
Pour les curieux, il existe (en C) de nombreuses interfaces dédiées des GPIO.
-
gpio-leds,gpio-keys,pinctrl-[^] # Re: C sur Raspberry
Posté par Claude SIMON (site web personnel) . Évalué à 3. Dernière modification le 23 août 2019 à 08:45.
Il y a aussi l'utilitaire
gpio, installé d'office (il me semble) sur une Raspbian, avec notamment la commandereadall, qui permet d'avoir une vue d'ensemble de la configuration et de l'état de chaque port GPIO. On peut voir cette commande en action sur cette vidéo (c'est du Peertube).Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: C sur Raspberry
Posté par BAud (site web personnel) . Évalué à 8.
ou sinon, simplement taper dans son terminal habituel
gpio -hqui détaille toutes les possibilités. C'est quoi cette mode de faire des vidéos énergivores là où du texte est directement lisible ? ya aussiman gpioqui est plus complet : c'est à ma connaissance installé par défaut sur Raspbian :-)[^] # Re: C sur Raspberry
Posté par Claude SIMON (site web personnel) . Évalué à 3.
Le premier lien est l'équivalent d'un
man gpio, et le second permet de voir à quoi ressemble la sortie de la commandereadall. Ainsi, on peut installer l'utilitaire en connaissance de cause, et non pas juste pour se faire une idée, sans être sûr de vouloir le conserver.Cet utilitaire n'est pas toujours installé d'office, même avec les distributions dédiées. Il n'était pas installé sur mon ODROID, par exemple.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: C sur Raspberry
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Pour moi, c'est l'inverse, pas loin de 30 ans de pratique plus ou moins régulière avec le C et je n'ai pas eu de mal à m'y remettre. Je suis en train de terminer un programme pour remplacer dans un premier temps la liaison téléphonique (RTC) d'un centrale d'alarme par internet et GSM.
J'ai ajouté une fonction nouvelle, la détection de la présence ou de la coupure du 220/240V. Il peut en effet être important de savoir que le frigo et le congélateur ne sont plus alimentés…
Dans un deuxième temps, le Raspberry donnera l'état de chaque capteur et dans un troisième, il remplacera toute la centrale avec une très grande souplesse d'utilisation. L'accès GSM ou web sera sécurisé.
L'architecture du programme a été conçue dès le départ avec ces options. Cela le rend très facile à comprendre et à modifier. La documentation que je tiens à jour en parallèle et même souvent avant de coder, complète les commentaires du code source.
J'ai justement utilisé WiringPi avec le C car cette solution m'a paru la plus simple et après l'avoir mise en œuvre, j'en suis totalement satisfait et WiringPi a totalement répondu à mes souhaits. Il procure une grande simplicité dans la mise en œuvre.
Au final, Raspberry avec Raspbian est une merveille. J'ai juste eu besoin d'installer mailutils mpack et php-fpm en plus des paquets installés par défaut. Je n'ai aucune dépendance autre que raspbian. Pour la pérennité, c'est excellent.
Si tout va bien, dans quelques semaines, je publierai (GPL V3) le code et la documentation. Il y aura peut-être un dessin de circuit imprimé dans le lot pour raccorder les interfaces.
[^] # Re: C sur Raspberry
Posté par barmic 🦦 . Évalué à 2.
C'est très contraignant le C dans ce contexte je trouve. Le fait d'avoir à manier des toolchaines complexe pour pouvoir démarrer ou à devoir faire son build sur la board elle-même ce qui (demande à installer des choses inutiles pour le run et c'est bien plus lent et il faut pousser les sources sur la board…).
Pour moi le bon compromis, c'est le go. La cross compilation est triviale, tu as des bibliothèques qui font le job et la différence de performance avec le C a toujours était négligeable pour mes usages. Cerises sur le gâteau : le langage est sympathique (je trouve) et le build est très rapide.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C sur Raspberry
Posté par BAud (site web personnel) . Évalué à 1.
pareil pour le python dans ton cas :-)
[^] # Re: C sur Raspberry
Posté par barmic 🦦 . Évalué à 1.
Python a une latence au démarrage que je trouve perceptible (j'aime pas attendre !).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C sur Raspberry
Posté par freejeff . Évalué à 2.
C'est vrai que de devoir compiler à chaque changement de programme ce n'est pas perceptible … C'est bien la première fois que j'entends cet argument !
[^] # Re: C sur Raspberry
Posté par barmic 🦦 . Évalué à 2.
La cross compilation go sur ma machine est plus rapide que le lancement du runtime (+JIT) python sur RPi. C'est choquant ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C sur Raspberry
Posté par freejeff . Évalué à 3.
Non, mais en général, ton runtime tu l'as au démarrage de ta session ipython.
Lorsque tu codes, tu peux faire depuis cet éditeur intercatif, des run mon_code, ou faire des copier/coller depuis ton éditeur. Souvent, lorsque l'on parle de la vitesse des langages interprétés pour le prototypage, c'est parce que tu peux tester les choses en copier/coller depuis l'éditeur, ou écrire directement dans l'interpréteur et non modifier ton code, sauvegarder, compiler, executer. Dans ce contexte, le lancement du runtime n'est pas vraiment un problème.
Ta comparaison n'est pas choquante en elle même, mais elle ne correspond pas à un workflow traditionnel sur les langages python/octave/julia/…
[^] # Re: C sur Raspberry
Posté par barmic 🦦 . Évalué à 1.
Je ne code pas sur le Pi. Coder à travers une connexion ssh ou un dossier partagé ne me plaît pas des masses.
Je ne suis pas sûr que coder en local sur le Pi soit si majoritaire (et c'est clairement pas l'usage classique en embarqué).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C sur Raspberry
Posté par freejeff . Évalué à 5.
Le point c'est que justement le pi, ce n'est pas que de l'embarqué. Lorsque tu as 4Go de ram et que tu peux faire tourner libreoffice chrome et autre, on n'est pas vraiment dans des contraintes d'embarqué.
[^] # Re: C sur Raspberry
Posté par barmic 🦦 . Évalué à 3.
Mais c'est pas pour autant forcément ta machine de dev. Et bon 4Gio ça vient de sortir, hein ? Un RPi 3 c'est 1Gio, de quoi affamer Firefox ou Chrome en moins de temps qu'il n'en faut pour le dire. Tout le monde n'y branche pas un écran et un clavier et n'y installent pas leur build tools. D'ailleurs même sur des gros serveurs plus puissant que ma machine de dev, je n'installe pas mes outils de build.
C'est has been comme pratique ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C sur Raspberry
Posté par freejeff . Évalué à 4.
En fait cette news traite en partie de la sortie de la Raspberry Pi 4 qui peut avoir de 1 à 4 Go de RAM. Après, il n'y a pas de problème si tu aimes travailler comme ça !
Visiblement tu aimes bien le go, pas de pb. Je n'ai jamais joué avec, donc je ne suis pas bien placé pour juger.
Perso, je ne suis pas informaticien, j'aime développé sous python, car c'est ce que je trouve le plus simple à utiliser et à faire apprendre à mes étudiants. Pour les microcontrôleurs, il y a même micropython !
On peut donc faire plein de choses avec ce matériel, sans avoir à faire du génie logiciel et mettre en place des chaines de compilations …
Si toi, tu aimes l'ingénierie logicielle et que des langages comme le GO te conviennent, c'est très bien !
Je ne comprends pas vraiment ton propos. Je ne suis pas là pour dire qui est has been ou pas, à vrai dire, cela ne me concerne pas vraiment.
Donc éclates toi bien avec le go et la RPi3 ! Pas de pb.
[^] # Re: C sur Raspberry
Posté par barmic 🦦 . Évalué à 1.
Désolé si notre conversation t'a agacée, j'ai voulu simplement expliqué ma remarque qui t'a fais réagir.
Je ne vois pas ce qu'il y a d'irritant à échanger sur nos pratiques.
Passe un bon week-end !
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C sur Raspberry
Posté par AnthonyRabine (site web personnel) . Évalué à 1.
Non c'est tout à fait moderne ; je suis un véritable développeur embarqué (c'est mon métier) et je fais de la compilation croisée pour un Raspberry PI depuis une machine Ubuntu.
C'est vrai que c'est très compliqué maintenant pour installer une chaîne de compilation croisée… apt install gcc-arm-linux-gnueabi, fouuuuuu !!
Par ailleurs, je crois que je n'ai jamais réussi à faire fonctionner un script Python du premier coup… comme quoi :) (je tremble à chaque fois, y'a un pip truc un setup machin, 36 façons d'installer une lib qui finit invariablement à échouer à la compilation).
[^] # Re: C sur Raspberry
Posté par freejeff . Évalué à 3.
C'est vrai que faire des makefiles lorsque l'on est pas informaticien, que l'on n'a jamais appris ce genre de techno, c'est simple.
Sérieusement, regardez les autres domaines et vous verrez que l'immense majorité est frileuse avec l'informatique. Mon travail consiste à trouver des technos qui permettent au non informaticiens de développer et d'utiliser ce qu'il se fait ailleurs facilement.
Python est idéal pour ça.
Ton avis est un avis d'expert de l'embarqué, désolé, mais tu n'es pas du tout la cible de cette dépêche, je ne suis pas sûr qu'elle t'ait apporté quoi que se soit.
Mais après, si tu aimes bosser comme ça pas de problème, je dis juste que ces méthodes sont trop lourde dans ma galaxie.
[^] # Re: C sur Raspberry
Posté par AnthonyRabine (site web personnel) . Évalué à 2.
Ce n'est pas une histoire d'aimer ou pas, c'est une histoire de "je n'ai pas le choix" ou "le choix du C est le meilleur dans tel cas". Tu confonds le goût avec le choix technique de passer au C pour des raisons tout à fait valables.
Et on peut très bien ajouter des précisions plus techniques à ta dépêche, elle n'est pas à toi, donc merci de ne pas envoyer à la figure le sempiternel "chacun ses goûts".
Discuter, c'est aussi découvrir les galaxies des autres et peut être s'enlever de la têtes des idées préconçues !
(cela n'enlève rien à tes remarques sur Python, je suis globalement d'accord mais je rajoute un bémol : ce n'est pas SI simple).
[^] # Re: C sur Raspberry
Posté par freejeff . Évalué à 7.
Je suis globalement d'accord avec toi.
Un bémol, c'est que tu considères que les gens vont chercher le meilleur langage pour leurs contraintes, dans mon expérience, les non-informaticiens vont chercher à voir jusqu'où ils peuvent aller avec le langage qu'ils connaissent, c'est très différent comme approche.
Être efficace en C et en Python, ne prend pas du tout le même temps, il est clair, que les cas de non-informaticiens qui feront ce choix sont minoritaires.
C'est juste ce point que je voulais exprimer.
[^] # Re: C sur Raspberry
Posté par AnthonyRabine (site web personnel) . Évalué à 5.
Ok, pigé ton point de vue, tu as raison sur les non informaticiens, mais je ne suis pas d'accord avec ta dernière phrase :)
Exemple qui tue : Arduino. C'est du C++, et des gamins de 12 ans s'y mettent sans vraiment comprendre ce qu'il y a derrière.
L'astuce d'Arduino est d'avoir bien packagé le C++ avec un IDE dépouillé et une librairie simplissime.
[^] # Re: C sur Raspberry
Posté par freejeff . Évalué à 2.
Oui, c'est vrai arduino est un bon exemple, et nous l'utilisons souvent en C++.
Je ne connais pas d'autre exemple d'interface de ce type pour le C++.
Tu as donc raison, si on fait une IDE, qui gère les makefiles, la CrossCompilation, l'upload du Code avec création de script init pour l'avoir au démarrage, alors Go ou C++ pourraient être des alternatives très intéressantes pour le raspberry pi. Seulement, cela resterait très difficile d'inclure d'autre lib de C++/Go car il faudrait trouver un mécanisme qui permettrait de faire tout le makefile … en pratique cela se limitera pour les non experts au lib packagées pour cet environnement. C'est pour cela que je pense Python est préféré sur les RPi, car si on arrive à installer un package, après ça sera bon pour tout les programmes que l'on fera. De plus les outils comme pip,conda (gestionnaires de paquets python) marchent pas trop mal dans la plupart des cas, ce qui rend l'installation d'une très grande proportion des lib python facile et donc facile à utiliser.
De plus, lorsque il y a des bouts de programmes trop lents, ce n'est pas si dur de faire un cython de base qui peut aider, et encore mieux si tu rajoutes le typage. Du coup le typage statique arrive lorsque tu en as besoin, pour les performances. Si tu veux moins te faire chier tu peux faire ta fonction lente en numba. Et si c'est ton code numpy qui est trop lent, tu n'as quasiment rien à faire pour utiliser pythran.
Avec ces nouveaux outils d'accélération de code, j'ai bien plus de mal à justifier l'utilisation d'un langage de plus bas niveau.
C'est un peu ça mon point de vue.
De plus dans beaucoup de cas, finalement la vitesse n'est pas prépomdérente, mais une mise en donnée rapide permettant de nombreux aller/retour, elle permet d'optimiser son rendement.
Après, encore une fois, je ne rejette pas C/C++/Fortran/Go/Rust, c'est juste que dans mon activit"é quotidienne, je n'y ai pas encore trouver d’intérêt.
S'il s'avère qu'un jour cela devient indispensable, alors je m'y remettrais dans la douleur.
[^] # Re: C sur Raspberry
Posté par barmic 🦦 . Évalué à 1.
Tu te méprends au sujet de go. C'est un langage haut niveau (probablement tout autant que python) qui ne nécessite pas de makefile. Quant aux dépendances, elles ont était problématiques uniquement au début.
Le langage est plutôt simple et ne doit pas être plus compliqué que du python, je trouve. D'ailleursuune bonne partie de la communauté go vient de python. Le placer dans la même catégorie que C n'a pas vraiment de sens.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C sur Raspberry
Posté par freejeff . Évalué à 2.
Probablement, je ne l'ai jamais essayé. Peut être que faire un journal pour expliquer l'ensemble de la chaîne en partant de l'utilisation des lib à comment faire pour que le compilateur les reconnaisse serait une super idée. !
[^] # Re: C sur Raspberry
Posté par barmic 🦦 . Évalué à 1.
Bof… Il y en a déjà pleins.
Tu as aussi Tour of go très connu.
Moins connu mais en français et très sympa je trouve riptutorial.
Plus spécifiquement pour les dépendances https://zestedesavoir.com/billets/2892/dep-le-gestionnaire-de-paquet-pour-golang/
Bref je vais pas te donner un lien vers lmgtfy, je n'ai pas grand chose à ajouter sur l'énorme quantité d'info qu'on peut déjà trouver en anglais comme en français.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C sur Raspberry
Posté par freejeff . Évalué à 0.
Un peu tout much ta réaction à mon gout.
Je te pensais à un retour d'expérience qui expliquerait ce qu'il fait et pourquoi il trouve ça mieux et en quoi ça l'a aidé à être plus efficace.
Tu ne trouves pas très souvent ces choses là sur le net tu as soit du "ça a changé ma vie" avec des arguments marketing, soit du très technique sans mise en perspective.
Quand au lmgtfy, tu as de la chance que je veuille rester poli, car tu l'as écrit pour m'agacer, ça a marché, tu es content de toi ?
Du coup, je pense que j'y réfléchirais à deux fois avant de te répondre la prochaine fois.
Plutôt que de prendre clairement les gens pour des cons, tu ne pourrais pas essayer par de la dialectique de mieux comprendre ce qu'ils veulent dire ?
[^] # Re: C sur Raspberry
Posté par barmic 🦦 . Évalué à 1.
Tu avais l'air de demander un tuto. J'ai pris le temps d'en chercher, de donner des liens pertinents en anglais et en français puis de dire que je n'avais rien de plus intéressant à donner que ce que le web te donnera. Mon expérience sur le sujet n'a rien de particulièrement intéressante, je n'ai pas énormément pratiqué le go non plus.
Moi je dois deviner que tu me demande mon retour d'expérience (ton commentaire demande à expliquer la toolchain), toi il te suffisait de lire sans t'énerver pour rien (je ne t'ai aucunement insulté, ai dis que je n'avais rien de plus pertinent qu'un moteur de recherche).
D'autant qu'il y a quelque jours un peu plus haut tu semblais exaspéré de me voir dire que j'aime bien utiliser go sur mon RPi…
Je ne souhaitez aucunement t'énerver, mais en principe ça n'arrivera plus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C sur Raspberry
Posté par barmic 🦦 . Évalué à 0.
C'est vrai que je n'ai pas essayé depuis un paquet de temps, mais comme depuis j'ai un peu joué avec go. Il m'a paru bien agréable de me jouer avec ce dernier.
C'est un truc qui ne me fait pas trop peur avec les binaires statiquement linkés de go :p
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# GPIO
Posté par malt . Évalué à 1.
Merci pour l'article,
Je recherche une carte dans le genre mais avec beaucoup beaucoup plus de GPIO, il m'en faudrait idéalement 200, mais si vous avez une idée pour en avoir plus c'est déjà pas mal.
J'ai fait quelques recherches et je suis tombé sur le MCP23017 et ça semble rajouter 16*8 input/output mais ce n'est pas encore suffisant.
Si vous avez des idées :)
[^] # Re: GPIO
Posté par diorcety . Évalué à 2.
13*MCP23S17 branchés sur du SPI avec 4 lignes de sélection (chaque MCP23S17 étant sélectionné avec un 74LS688). Tu pourrais monter à 240 avec 4 lignes, beaucoup plus avec plus de lignes.
[^] # Re: GPIO
Posté par Phenixrb . Évalué à 2.
Bonjour,
Concernant les I/O ,
16x8=128 en SPI MCP23S17 ,
16x8=128 en I2C MCP23O17.
Soit 256 au total.
[^] # Re: GPIO
Posté par freejeff . Évalué à 3.
Il y a accès à 4 bus SPI et 4 bus I2C sur la RPi4, donc tu peux arriver à 1024, non ?
[^] # Re: GPIO
Posté par malt . Évalué à 1. Dernière modification le 23 août 2019 à 11:01.
C'est peut être ça la solution, un RPi4. Parce que j'ai besoin de 2 bus I2C aussi.
[^] # Re: GPIO
Posté par ted (site web personnel) . Évalué à 1.
C'est pour quelle utilisation?
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: GPIO
Posté par malt . Évalué à 1.
Pour un jeu avec un animal domestique, l'idée c'est de brancher sur des GPIO des LED et Récepeuts IR et que dès que la liaison ne se fait plus (quand l'animal passe devant) ça fait quelque chose.
Mais je ne sais pas si c'est faisable avec ça Récepteur IR, OP505A et ça LED infrarouge, Vishay, TSHF5210, 1 LED, Traversant, 890nm, 180mW/sr 50mW
mes connaissances en électronique s’arrêtent là…
Vous en pensez quoi?
[^] # Re: GPIO
Posté par chimrod (site web personnel) . Évalué à 5.
Ça te reviendra moins cher avec un registre à décalage… C'est normalement fait pour multiplier les sorties, mais tu peux aussi l'utiliser pour tester plusieurs entrées (avec un petit temps de latence qui ne devrait pas être perceptible dans ton cas).
Tu as une explication sur la librairie arduino shitf-in, mais une fois que tu as compris le principe, tu peux le faire ton pi également.
[^] # Re: GPIO
Posté par ted (site web personnel) . Évalué à 2.
C'est ce à quoi je pensais, d'où ma question :)
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: GPIO
Posté par malt . Évalué à 1.
Oui c'est pas mal sauf que j'ai l'impression que les boutons sont reliés entre eux donc je ne peut pas programmer chaque boutons individuellement (je me trompe peut être).
Et sinon on peut relier des led IR et des recepteurs ir directement sur les GPIO ou il faut mettre des résistances?
[^] # Re: GPIO
Posté par ted (site web personnel) . Évalué à 2. Dernière modification le 23 août 2019 à 17:12.
Pour les LED, il faut des résistances, à calculer en fonction de l'alimentation, de l'ampérage max qui doit la traverser et de la tension de seuil. N'essaie pas d'alimenter les leds directement sur des GPIO sans savoir ce que tu fais, sinon tu vas les griller (les GPIO…). Si tu n'as pas besoin de les contrôler, mets les directement sur une alim avec des résistances. Sinon, utiliser un transistor pour contrôler les LED.
Pour les capteurs, ce sont des (photo)transistors. Si tu les aliments avec la même tension que ta carte, il n'y a pas besoin de résistance. Sauf peut-être si tu veux régler la sensibilité. Après, ces phototransistors sont des éléments analogiques, ils ne vont pas te sortir un 1 ou un 0, il faut voir comment tu arriveras à t'en sortir pour avoir des résultats répétables.
Tu peux aussi regarder du côté des boitiers TCRT5000
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: GPIO
Posté par inky-full-bash . Évalué à 3.
Étant donné que ce sont des LED IR pour illuminer des capteurs, je pense qu'il n'essaie pas de les contrôler, ou son animal domestique est très spécial !
Et en effet, comme ces capteurs sont analogiques, il faudra des sorties analogiques. Essayer de faire le filtrage à la main risque d'être casse-gueule ; chaque capteur aura son propre seuil en fonction de son environnement (calibration empirique !)
La question du mode de fonctionnement des capteurs se pose quand-même : c'est un capteur de proximité/distance comme TCRT5000 ou un capteur de coupure de ligne qu'il faut utiliser ? (détection proximité à la gamelle ou détection de passage d'une porte ?)
Pour la problématique du nombre de GPIO et des entrées analogiques, ça vaut peut-être le coup de tous les mettre sur un bus I2C. Tout le monde sur quatre fils (mais les capteurs sont plus chers).
[^] # Re: GPIO
Posté par malt . Évalué à 1.
Oui l'idée c'est d'avoir des résultats logiques (0 ou 1).
[^] # Re: GPIO
Posté par inky-full-bash . Évalué à 4. Dernière modification le 24 août 2019 à 14:03.
Ok. Comme je vois plus haut que tu as forcément besoin d'I2C pour autre chose, je pense que tu peux tout mettre dessus, sans forcément passer par des entrées analogiques ou des convertisseurs I2C/SPI vers entrées analogiques.
Tu as par exemple le capteur VCNL4020 (et plein d'autres, suffit de chercher les mots-clé "i2c photo sensor ir") tout intégré. Il a une LED infrarouge, le capteur juste à côté et l'interface I2C. L'idée c'est de tous les mettre en parallèle sur quatre fils (masse, alim, SDA et SCL). Pour faire simple, lorsque ta Raspberry souhaite récupérer la valeur associée à un capteur, il va interroger le bus et fournir une adresse. Chaque capteur a une adresse (qu'il faut programmer en avance de phase via ce même bus une bonne fois pour toute). Et tu obtiens une valeur (pour ce capteur c'est un nombre sur 3 bits). Ensuite tu compares la valeur à un seuil (que tu dois définir en faisant plein de tests), et tu as ton résultat logique.
C'est une façon de faire complètement différente de l'analogique. C'est un peu comme le bus CAN d'une voiture. L'avantage c'est que tout est sur un seul bus, il y a moins d'électronique, et on compense avec du traitement logiciel (demander à l'OS d'accéder au bus I2C, interroger le bus avec des fonctions kernel ou plus haut niveau à la python, etc.). Un peu difficile à comprendre au début, mais dès qu'on l'a pris en main, ça change la vie !
[^] # Re: GPIO
Posté par malt . Évalué à 1.
Belle explication!
Ce qui m'échappe c'est qu'on parle de photosensible mais moi je veux pouvoir faire ça dans le "noir" aussi. Il ne vaut pas mieux que j'utilise des produits tels que ça oui ça associé à un récepteur led infrarouge (si ça existe…).
Mais oui effectivement je suis beaucoup plus calé en prog qu'en électronique.
[^] # Re: GPIO
Posté par inky-full-bash . Évalué à 5.
Ça fonctionnera aussi dans le noir. "Photosensible", c'est un terme générique pour dire que ça réagit à la lumière d'une longueur d'onde donnée. Par exemple, sur ton premier lien, c'est un capteur photosensible aux longueurs d'onde autour de 940nm, qui se comporte comme un transistor en fonction de la "lumière reçue", c'est-à-dire qu'il laisse passer plus ou moins de courant en fonction de lumière infrarouge reçue (émise par la LED IR juste à côté, et réfléchie lorsqu'un objet est proche).
Tu as aussi des capteurs photosensibles qui se comportent comme des résistances (résistance qui varie en fonction de la lumière reçue), ou des diodes (laisse passer le courant uniquement s'il reçoit suffisamment de lumière).
Plus d'infos par là :
https://fr.wikipedia.org/wiki/Photor%C3%A9cepteur_(%C3%A9lectronique)
Mais dans tous les cas, la longueur d'onde est fixée. Tu peux avoir des photorécepteurs sensibles uniquement aux infrarouges, à toute la lumière visible, aux ultra-violets, à une couleur spécifique, etc. Mais dans ton cas, il faut en effet rester sur l'IR. Pas seulement pour que ça fonctionne la nuit, mais surtout pour que le capteur ne soit pas gêné par la lumière du jour.
Donc le composant de base se comporte comme une résistance, une diode ou un transistor. Ensuite tu as des versions plus sophistiquées qui embarquent ce capteur, mais également de quoi communiquer plus facilement. Par exemple pour lui parler directement en I2C, SPI, etc. et encapsuler toute la "complexité" de l'analogique dans une boite noire. En fait c'est comme faire de l'orienté objet ! Attention néanmoins si tu transporte le signal analogique sur un fil du capteur jusqu'à la raspi : le signal risque d'être parasité par l'environnement (je ne sais pas à quel point, ça dépend du fil, de sa longueur, etc.).
Sur ton deuxième lien, tu as en effet seulement une LED IR. Tu peux trouver des capteurs IR stand-alone, mais je te conseille de prendre les versions qui embarquent la LED et le capteur. C'est tout simplement plus pratique, tout est dans un seul composant. Ce qu'on néglige souvent, c'est le packaging … et c'est quand-même plus facile quand tout est dans un composant unique. Surtout si tu comptes en déployer plusieurs. Un cas particulier : si tu souhaites séparer l'émetteur et le capteur (par exemple dans un ascenseur coupe le faisceau entre les portes), mais là faut du matériel spécifique.
[^] # Re: GPIO
Posté par Strash . Évalué à 5.
Pour gérer un grand nombre de LEDs, le mieux est d'utiliser des LEDs adressables du type ws2812b. Avec un seul GPIO tu peux gérer plusieurs centaines de LEDs, avec le choix de l'intensité et de la couleur de chaque LED individuellement.
# Utilisation de bureau
Posté par tao popus . Évalué à 3.
Justement dans les accessoires de la RockPro64, il y a un vrai boîtier de bureau, avec 2 emplacements disques, comme la carte supporte 2 disques SATA sur le bus PCI (et non pas USB comme certaines cartes).
Je ne connais pas de SBC qui n'a pas son boîtier proposé comme accessoire (ça n'interesse pas tout le monde, selon l'usage (empilements pour cluster HAADOP par exemple, mais celui de la RockPro64 est une nouveauté dans le monde des SBC.
https://store.pine64.org/?product=rockpro64-metal-desktopnas-casing
Sinon, des gens de Collabora ont posté des vidéos sur Youtube, de la Rockpi4b (même SoC que la RockPro64) avec le pilote libre Panfrost encore balbutiant. Le pilote libre émule OpenGL 2.1 là où le blob d'ARM ne faisait qu'OpenGL ES !!
Vhercher "panfrost". (à regarder éventuellement avec indivio.us ou le module firefox invidition, je n'aime pas le fait de ne pas pouvoir accélérer et de regarder en 1080p des vidéos qu'on peut regarder parfois en 140p ou 360p)
Il y a "N64 emulation" (il y a 2 jours). Il y a aussi une démo de SuperTuxKart dans un teste plus complet de différentes distro (ambian, ubuntu) sur RK3399 avec PanFrost sur desktop
Visiblement ça utilise la même technique que ça https://github.com/rfht/fnaify pour cette démo de owlboy (utilisant une api Microsoft XNA, porté via mono et nommé FNA ?).
https://www.youtube.com/watch?v=022ROW2MsYQ
Je trouve que Broadcomm fait un peu du caca à vouloir économiser sur des bouts de chandelle, ce qui fait des conflits, les Rockchips (et en fait tous les autres procs ARM) ont des unités plus spécialisées et séparées. Ils se sont améliorés avec le proc du RasbPi4, mais ils ont encore du travail. L'avantage du Rasb reste indéniablement l'énorme base utilisateur.
[^] # Re: Utilisation de bureau
Posté par Anonyme . Évalué à 3.
J'avais aussi tiqué en relecture mais j'ai supposé que vu le contexte bureautique du paragraphe, Jeff voulait parler de toute la variété de design disponibles pour RPi.
Merci pour l'ajout. On a pris soin de présenter les avancées de Panfrost et même de Lima mais difficile d'être à la pointe de l'info quand ça progresse aussi rapidement.
Il ne faut pas non plus oublier les performances du matériel : La RPi4 est l'une des très rares cartes de cette gamme intégrant quatre cœurs Cortex A72 "haute performance", les autres en ont seulement deux ou uniquement des cœurs A53 basse consommation comme la RPi3. Au-dessus il y a le SoC S922X de Amlogic mais pour l'instant uniquement présent dans des boitiers Android >100€. Je trouve que c'est dommage d'avoir sacrifié la conso en idle (j'aurai vu au moins un petit cortex A35 dans le SoC en config big.little) mais ça reste intéressant pour un usage qui demande un peu plus de patate qu'un RK3399.
[^] # Re: Utilisation de bureau
Posté par freejeff . Évalué à 3. Dernière modification le 23 août 2019 à 09:51.
Oui, c'est l'idée. Il y a une telle communauté que ce n'est pas que le fabriquant de la carte qui fait le boîtier, ce qui est rarement le cas pour les autres cartes.
Du coup on voit fleurir plein de solutions, et il y a plus de chances de trouver chaussure à son pied.
je trouve de plus qu'à 57,32 €, elle est moins chère que la plupart des cartes RK3399, pour plus de performances CPU, un VPU équivalent, par contre en terme de GPU, on n'a pas encore beaucoup de retours.
[^] # Re: Utilisation de bureau
Posté par Mathias Bavay (site web personnel) . Évalué à 2.
D'après certains benchmarks que j'ai pu voir, les quatre A72 (à 1.5 GHz) du Pi4 restent un tout petit peu en deçà des 2 A72 (à 2 GHz) + 4 A53 du Rockship RK3399. Après, je ne sais pas si les deux systèmes sont comparables en terme de support de la DDR4 (sur le rk3399, ce n'est pas encore supporté). À noter, l'implémentation de l'usb3 sur le Rpi4 est apparemment la plus propre de son domaine (ie sur SBC Arm).
[^] # Re: Utilisation de bureau
Posté par tao popus . Évalué à 3. Dernière modification le 28 août 2019 à 02:33.
Le RK3399 à maintenant quelques années effectivement (on le trouve dans des produits finis depuis octobre 2016). le A72 aussi d'ailleurs (février 2015). Il y a plusieurs autres Fabless qui font de l'A73, A75 ou A76, avec d'avantages de cœurs (Amlogic, MediaTek, HiSilicon, NXP (16*A72 orienté station de travail) etc…) le problème étant de ressaisir à les convaincre de laisser souder le SoC sur des SBC d'indépendants. Odroid fait des SBC avec des Amlogic comprtant 4*A73(1.8Ghz)+2*A53(1.9Ghz) ODROID-N2.
On trouve une version 4G à 70 ($=€ normalement), donc pour moins de 13€ de plus on a une plus basse conso en creux et beaucoup plus de puissance en pic + collabo avec CoreELEC
https://www.hardkernel.com/shop/odroid-n2-with-4gbyte-ram/
On devrait trouver les nouveaux SoC RK3588 (4*A76 + 4*A55, NPU, vidéo 8K, GPU Mali G52, USB3, SATA) dans des produits finis début 2020, ça ne sera probablement pas le prix d'une RasbPi, mais ça reste abordable avec des SBC <100€ dès la sortie pour chaque gamme et des netbook <300€. La société Rockchip (comme quelques autres dans le domaine ARM) supporte bien eux-même le noyau mainline, ça reste un avantage. Ils ne maîtrisent pas les droits pour les GPU qui sont conçus par ARM par contre. Je n'ai pas trop suivi ce qui en est au niveau des NPU (neural) niveau pilote.
[^] # Re: Utilisation de bureau
Posté par Anonyme . Évalué à 2.
À quel prix. Parce que généralement ce n'est pas encore compétitif avec du x86 et en plus avec que des cœurs haute performance on perd l'avantage basse consommation des SOC ARM (comme sur le RaspberryPi4).
Au passage, durant la rédaction j'ai voulu aussi parler de etnaviv en citant la gamme i.MX de NXP mais force est de constater que toutes les solutions sont au-delà de la centaine de dollars US et font vraiment pâle figure au niveau CPU par rapport à la concurrence.
C'est davantage que le marché des ordinateurs monocartes est majoritairement tributaire de celui des SoC destinés aux boitiers TV/multimédia et que celui-ci est très en retard par rapport à celui des téléphones.
Les gros comme Mediatek ou Qualcomm en ont pas grand chose à faire de ce marché low-cost.
Merci j'avais pas vu que Hardkernel utilisait le Amlogic S922X. Ça devient déjà plus intéressant même si attention : Amlogic a la fâcheuse habitude de ne pas tenir les fréquences annoncées.
Ça malheureusement c'est quand on ne compte pas les frais de livraison, de douane, l'arnaque des "frais de dossier" du transporteur ou la marge de l'importateur (quand on veut obtenir une garantie de deux ans).
Je ne sais pas comment sont les sud-coréens mais importer en Europe depuis l'amérique du nord ça peut vite douiller.
Sans compter qu'il faut y ajouter le coût d'une alim 12V 2A. Et de préférence pas trop dégueu parce que ces ordi monocartes sont souvent faibles au niveau des capacités et filtrage d'entrée.
Tu les tirent d'où tes infos ? Je n'ai rien trouvé de nouveau depuis leur annonce en avril dernier.
Je m'attends uniquement à des boitiers multimédia sous Android entre 100 et 150€. Et il faudra attendre de voir si ce SoC sera bien élu par la firme pour être digne d'un développement Linux mainline. Sans ça, l'intérêt d'un ordinateur monocarte est très limité.
C'est du Bifrost donc si le support Linux mainline est bien présent, il y a toutes les raisons de penser qu'il sera couvert par le pilote Panfrost.
Chez Rockchip les VPU ne sont pas du tout libérés, je n'attendrai pas grand chose non plus du côté NPU.
[^] # Re: Utilisation de bureau
Posté par tao popus . Évalué à 3.
Bah les infos d'avril justement. Les précédentes années, ils ont respectées leurs annonces pour les sorties. La puce sort cet automne et le matos devrait pouvoir sortir début 2020, l'intégration dans le noyau se fait en parallèle.
La firme pousse tout dans le mainline depuis des années et c'est leur principal évolution. Sachant que leur SoC ne sont utilisé quasiment que par du Linux, et leur support mainline Linux est toujours très actif. Je ne vois pas l’intérêt qu'ils auraient à ne pas l'y ajouter.
Si, il y a bien des pilotes FLOSS pour les VPU Rockchip et fait par Rockchip :
https://github.com/rockchip-linux/mpp/tree/release/mpp
Et son intégration dans gstreamer :
https://github.com/rockchip-linux/gstreamer-rockchip
Support dans kodi déjà en 2015
https://www.cnx-software.com/2015/07/16/kodi-14-2-linux-ported-to-rockchip-rk3288-with-vpu-hardware-decoding/
Oui, mais comme je disait, ils ne maîtrisent pas les droit (appartient à ARM) et ne peuvent donc faire un pilote libre d'eux même.
J'ai testé le pilote panfrost sur un RK3288 (Mali-T760), comme l'auteur principale à travaillé tout d'abord sur le RK3399 (Mali-T860), son support est donc plus récent, je ne sais pas encore ce qui en est des GPU Bitfrost et pas la peine de rêver pour Valhall). Ça ne commence à fonctionner pour X11 et Wayland) qu'avec Mesa-19.2.0 (actuellement en RC1). Mais ça marche déjà sacrément bien pour une première mouture. XFCE est encore un peu lent (un peu moins que le blob d'ARM), mais :
* Tous les tests glmark2 fonctionnent, juste un petit détail dans l'ombre portée du logo 3d ideas in motion (glmark2-es2 -b ideas), par contre le test jellyfish (glmark2-es2 -b jellyfish (es2 ou sans)) qui bug sur mon intel (les courbures en splines sont remplacés par des formes angulaires), fonctionne là.
* Il supporte déjà partiellement l'OpenGL full, contrairement au blob ARM qui ne supportait que GL ES et ça, ça débloque plein de choses pour Linux sur le bureau.
score global glmark2:
* Panfrost: 333 sous XFCE, 337 sous OpenBox
* blob ARM: 257 (dans le meilleur cas sous XFCE, pas testé avec OpenBox)
* C'est un peu moins de la moitié du résultat en fps des test et en score global de mon corei7 (Sandybridge 2700K).
Weston 6.x fonctionnait par conter, problème avec la mise à jour en 7.0.0 ce matin, Archlinux.
Niveau jeux :
* Neverball parfait.
* SuperTuxKart est censer marcher mais je ne l'ai pas encore compilé.
* mame fonctionne (dont 3d), un peu lent en général.
* Le RTS Warzone2100 (full GL) fonctionne et est très fluide mais avec plein de glitchs (grosse facettes translucides qui traversent l'écran et rendent certains objets invisibles) qui le rendent quasi-inutilisable. (le blob ne permet de l'utiliser qu'en pure logiciel, et c'est trop lent).
Bref il y a encore du boulot, mais c'est un bon début, déjà prometteur.
[^] # Re: Utilisation de bureau
Posté par tao popus . Évalué à 0.
# moment marrant
Posté par freejeff . Évalué à 7. Dernière modification le 23 août 2019 à 19:52.
23/08/2019 19 h 42
Dépêche notée 42
42 commentaires.
Qui doutera encore de l'universalité de la Raspberry pi
-->[]
[^] # Re: moment marrant
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5.
Faut jouer au loto, c'est un signe.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Quelle UPS pour Rpi4
Posté par Stibb . Évalué à 4.
J'utilise de manière intensive mes Rpi3, et j'en suis arrivé à la conclusion que le WAF n'est atteind que s'il ne peut tomber en panne à cause d'une mauvaise manipulation ni une coupure de courant. Il n'est donc pas envisageable d'avoir un Rpi en utilisation quotidienne (pour ma par, Home Cine, DNS et Domotique) sans une carte UPS par dessus qui éteind proprement le Rpi sans corrompre la carte mémoire. Je ne comprend pas pourquoi il n'existe pas une Rpi avec une mini batterie intégrée qui ne ferait que débrancher proprement la carte SD et éteindre le PC en cas de coupure d'alimentation. Meme si le FS est par la suite sâle et demand un fsck, c'est pas grâve, mais une carte SD morte au niveau électrique ce n'est pas possible. Pas envie de devoir restaurer les sauvegardes le dimanche soir pour que le chauffage se déclenche bien le lendemain matin parce qu'une fausse manip m'a fait débrancher le cordon d'alimentation. La Freebox ne brick pas en cas de coupure intenpestive, le routeur ne brick pas.
Le NAS, d'accord, mais c'est différent. Pour moi le Rpi DOIT être safe.
Donc pour l'instant je suis sur PICO UPS sur Rpi3, je me demande s'il n'y a pas mieux sur Rpi4 ?
[^] # Re: Quelle UPS pour Rpi4
Posté par Psychofox (Mastodon) . Évalué à 1.
Tu dis que tu ne comprends pas que ça n'existe pas et après tu dis que tu utilises pico ups. Il y'a aussi pijuice. Tu fais dans le dédoublement de personnalité ?
[^] # Re: Quelle UPS pour Rpi4
Posté par Kerro . Évalué à 6.
Le Rpi a été conçu pour le côté éducatif, donc les histoires WAF et de coupures électriques sont très accessoires.
Qu'on en fasse un usage détourné, c'est notre problème. Ce n'est pas un problème de conception.
[^] # Re: Quelle UPS pour Rpi4
Posté par Anonyme . Évalué à 2.
Oui comme on l'a écrit dans la dépêche, les RaspberryPi ne sont pas des cartes pour tous les usages. D'autres solutions sont plus spécifiques.
# Extraction du device-tree
Posté par karteum59 . Évalué à 7. Dernière modification le 27 août 2019 à 13:41.
Note qu'il existe des techniques pour extraire le device-tree depuis l'image kernel/firmware fournie par le fabricant !
(par contre, à supposer que ce soit possible, j'aimerais bien trouver un jour un tuto pour extraire le code objet correspondant aux "board-files" et le réinjecter dans un autre kernel, pour ajouter le support de cartes qui utilisent des board-files et non un dtb. Alors oui je sais, c'est du GPL donc on devrait toujours avoir accès au kernel. Mais il existe de nombreuses situations où ce n'est pas possible (code-source non fourni par le fabricant car de nombreux ODMs à Shenzhen ne respectent pas la GPL, code-source publié 5 ans avant sur un forum type XDA mais "perdu"…)).
[^] # Re: Extraction du device-tree
Posté par freejeff . Évalué à 3.
C'est sûr que cela serait vraiment très intéressant !
Si tu y arrives, n'hésites pas à le poster, je pense que cela peut intéresser plein de gens.
# Commentaire supprimé
Posté par smerin . Évalué à -4. Dernière modification le 01 septembre 2019 à 10:07.
Ce commentaire a été supprimé par l’équipe de modération.
# Commentaire supprimé
Posté par lmds . Évalué à -1. Dernière modification le 06 novembre 2019 à 12:47.
Ce commentaire a été supprimé par l’équipe de modération.
# Commentaire supprimé
Posté par martina . Évalué à -1. Dernière modification le 06 novembre 2019 à 12:47.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.