Planet RaspFR

Bienvenue sur ce planet dédié au Raspberry Pi
mais aussi autres micro-ordinateurs et aux imprimantes 3D de type DIY.

Si vous voulez ajouter votre blog, n'hésitez pas à nous contacter.
Nous vous donnons rendez-vous sur le forum RaspFR

Deuxièmes rencontres Nationales Raspberry Pi de Nevers (28 et 29 avril 2017)

Les Deuxièmes Rencontres Nationales Raspberry Pi auront lieu à Nevers les 28 et 29 avril 2017. Je serai heureux de vous y rencontrer pour discuter de notre framboise 🙂

Programme

Pour préparer votre venue, voici le programme de ces deux journées (cliquez pou agrandir) :

Programme #RNRPI2 Nevers 2017

#RNRPI2 Pour préparer votre venue à Nevers la semaine prochaine voici ci-dessus le programme des Deuxièmes RENCONTRES NATIONALES DU RASPBERRY PI. Je serai heureux de vous y rencontrer et d’échanger à propos de notre framboise et de Framboise314 🙂 Vous y rencontrerez aussi Alan Mc Cullagh, ambassadeur Raspberry Pi France et Sarah Lacaze, auteur du livre « Scratch » paru aux Editions ENI​. Ils animeront également des ateliers et des conférences !! A la semaine prochaine à l’INKUB de Nevers​ avec la  Communauté d’agglomération de Nevers​

Sources

Cet article Deuxièmes rencontres Nationales Raspberry Pi de Nevers (28 et 29 avril 2017) a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Détection de mouvement sur une mangeoire d’oiseau filmée par un Raspberry Pi

2ème article sur ma mangeoire d’oiseau filmée par un Raspberry Pi : je vous parle aujourd’hui de la mise en place logicielle pour être capable de diffuser la vidéo capturée par la caméra du Raspberry Pi sur le réseau local et ajouter de la détection de mouvement pour prendre des photos lorsque cela est nécessaire.

Remémorons nous le projet initial : je veux filmer une mangeoire d’oiseau avec un Raspberry Pi au milieu de mon jardin et prendre des photos lorsque des moineaux, mésanges, colombes… viennent picorer. Je ne souhaite pas non plus avoir un nombre très important d’images, donc la détection de mouvement doit être configurable.

Après quelques recherches et expérimentations, la solution est composée de 2 logiciels :

  • mjpg-streamer : capture le flux vidéo de la webcam et permet via une interface web de consultation soit de prendre une photo instantanée soit de visionner le « live »;
  • motion : lit le flux vidéo diffusé par mjpg-streamer et sauvegarde des photos en fonction des mouvements détectés.

Matériel

La caméra utilisée est un clone du modèle officiel avec en plus un objectif interchangeable de 22 mm compatible CCTV (caméra de surveillance) testée dans ce billet. Elle embarque un capteur de 5 Mega Pixel. Elle peut prendre des photos avec une résolution de 2592×1944 et filmer en 1080p à 30fps.

Webcam du Pi avec un objectif interchangeable de 22 mm

Webcam du Pi avec un objectif interchangeable de 22 mm

La première chose à faire est de vérifier que la caméra fonctionne bien à l’aide de l’outil raspistill :

$ raspistill -o $(date +"%Y-%m-%d_%H%M%S").jpg

A chaque exécution de la commande raspistill, une image sera sauvegardée dans le dossier courant avec un nom de la forme : 2017-03-19_122629.jpg.

Capture de mouvement

mjpg-streamer est le premier maillon de la chaîne : il s’occupe de capturer le flux vidéo pour le rendre accessible sur le réseau local via une interface web.

Il n’existe pas de paquet précompilé à l’heure actuelle, il faut le compiler, voici la procédure :

Installation des dépendances

Il faut installer quelques paquets au préalable :

$ sudo apt-get install libjpeg8-dev imagemagick libv4l-dev git

Récupération des sources et compilation

Plusieurs fork du projet initial mjpg-streamer existent dont un notamment qui inclus un driver pour la caméra de notre framboise préférée que nous allons cloner. Malheureusement, ce projet ne tag pas les sources ni n’effectue de release, donc la récupération des sources peut être périlleuse si elle s’opère en plein cœur d’un refactoring :'(

$ git clone https://github.com/jacksonliam/mjpg-streamer.git
Cloning into 'mjpg-streamer'...
remote: Counting objects: 2579, done.
remote: Total 2579 (delta 0), reused 0 (delta 0), pack-reused 2578
Receiving objects: 100% (2579/2579), 3.41 MiB | 569 KiB/s, done.
Resolving deltas: 100% (1604/1604), done.

pour mémoire, la version que j’utilise est :

$ git rev-parse HEAD
3ed3f4cad86c4ad6e58bdc70a91c3cc3c949276a

Lancement de la compilation des sources :

$ cd mjpg-streamer/mjpg-streamer-experimental
$ make USE_LIBV4L2=true clean all
$ sudo make install

Il est important d’inspecter les logs de la première commande make pour vérifier les plugins  compilés :

-- The following features have been enabled:
* PLUGIN_INPUT_FILE , File input plugin
* PLUGIN_INPUT_HTTP , HTTP input proxy plugin
* PLUGIN_INPUT_RASPICAM , Raspberry Pi input camera plugin
* PLUGIN_INPUT_UVC , Video 4 Linux input plugin
* PLUGIN_OUTPUT_FILE , File output plugin
* PLUGIN_OUTPUT_HTTP , HTTP server output plugin
* PLUGIN_OUTPUT_RTSP , RTSP output plugin
* PLUGIN_OUTPUT_UDP , UDP output stream plugin

Les plugins qui nous intéressent sont PLUGIN_INPUT_RASPICAM et PLUGIN_OUTPUT_HTTP

Lancement

Finalement exécuter la commande suivante :
$ LD_LIBRARY_PATH=/usr/local/lib mjpg_streamer -i "input_raspicam.so -fps 30 -q 75 -x 1920 -y 1080 -ex verylong" -o "output_http.so -p 9000 -w /usr/local/share/mjpg-streamer/www/"
MJPG Streamer Version.: 2.0
[...]
i: fps.............: 30
i: resolution........: 1920 x 1080
i: camera parameters..............:
Sharpness 0, Contrast 0, Brightness 50
Saturation 0, ISO 400, Video Stabilisation No, Exposure compensation 0
Exposure Mode 'verylong', AWB Mode 'auto', Image Effect 'none'
Metering Mode 'average', Colour Effect Enabled No with U = 128, V = 128
Rotation 0, hflip No, vflip No
o: www-folder-path...: /usr/local/share/mjpg-streamer/www/
o: HTTP TCP port.....: 9000
o: username:password.: disabled
o: commands..........: enabled
i: Starting Camera
[...]
DBG(/home/pi/mjpg-streamer/mjpg-streamer-experimental/plugins/input_raspicam/input_raspicam.c, worker_thread(), 880): Starting video output

Les options disponibles sont décrites sur le site web du projet :

  • plugin raspicam : capture effectuée en 1080p à 30 fps
  • plugin http : IHM web lancée sur le port 9000 et servant les fichiers statiques à partir du dossier /usr/local/share/mjpg-streamer/www/

Ouvrir un navigateur et le faire pointer sur l’ip du Raspberry Pi, port 9000, l’IHM ressemble à cela :

IHM de mjpg-streamer

IHM de mjpg-streamer

Le menu de gauche offre différentes vues :

  • static : photo unique de la caméra, il faut rafraichir la page pour en avoir une nouvelle;
  • stream : flux vidéo live de la caméra. mplayer, vlc savent lire la vidéo à l’url indiquée;
  • java : lance une applet java pour lire la vidéo dans le navigateur;
  • javascript : affiche une vidéo à l’aide d’un script javascript. La perception utilisateur est une vidéo mais n’est en réalité que la succession de photos prises et affichées très rapidement

Détection de mouvement

Motion est un programme qui surveille le signal vidéo d’une ou plusieurs caméras en détectant si une part significative de l’image a changé. Il sauvegarde les images dans un dossier prédéfini en fonction des événements détectés sur la caméra.

Installation

le paquet Debian armf est disponible dans les dépôts officiels :

$ sudo apt-get install motion

Configuration

La configuration par défaut nécessite un peu de paramétrage, notamment l’url du flux vidéo exposé par mjpg-streamer.

netcam_url http://localhost:9000/?action=stream

Les photos sont sauvegardées sur un partage NFS monté sur /mnt/media/webcam, il faut indiquer à motion où écrire :

target_dir /mnt/media/webcam/

Il est possible de spécifier un format de nom de fichier pour les photos prises lors de la détection d’un mouvement :

jpeg_filename %m-%d/%Y%m%d-%H.%M.%S

Les fichiers produits seront stockés dans un dossier <MOIS>-<JOUR> et le nom du fichier sera de la forme <ANNEE><MOIS><JOUR>-<HEURE>.<MINUTES>.<SECONDES>. Avec cette configuration, un dossier par jour sera créé contenant les photos de la journée. Cela va nous être vite utile car il y a entre 50 et 300 photos chaque jour. Motion créé tout seul le dossier spécifié dans le nom de fichier.

J’en profite pour mettre les logs dans le dossier racine :

logfile /mnt/media/webcam/log/motion-pi.log

La taille de l’image reçue est spécifiée :

width 1920
height 1080

La configuration ci dessous est empirique. Je l’ai mise au point en fonction des réactions de la webcam par rapport au soleil, aux mouvements des oiseaux et des ombres projetées etc…
L’idée est de ne pas produire 30 images par secondes à chaque mouvement sur la mangeoire, mais plutôt prendre une photo de temps en temps. La documentation est très détaillée et vaut le détour.

J’ai diminué le nombre d’image par seconde analysé (option framerate), augmenté le seuil de détection de mouvement (threshold, threshold_tune), augmenté le nombre d’images devant avoir du mouvement (minimum_motion_frames), affiné le vieillissement des pixels pour que motion ne détecte pas le mouvement des arbres ou l’ombre (despeckle)…

framerate 2
threshold 3500
threshold_tune on
despeckle EedDl
minimum_motion_frames 5
smart_mask_speed 1

Lancement de la détection de mouvement

Exécuter la commande pour démarrer motion :

$ sudo service motion start

Yapluka attendre que les oiseaux passent pour que les photos se déclenchent ! 😎

Conclusion

J’espère que ces 2 articles vous ont donné l’envie de faire une projet similaire, n’hésitez pas à faire part de vos projets en commentaires ci dessous !

La mise en place de la détection de mouvement est plutôt ludique mais nécessite du temps afin d’affiner la configuration pour ne pas être noyé par le nombre de photos prises.

Une évolution intéressante de la solution serait d’ajouter un mécanisme me notifiant lorsqu’il n’y a plus de graines dans le réservoir à partir des images prises par la caméra.

Cet article Détection de mouvement sur une mangeoire d’oiseau filmée par un Raspberry Pi a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Xenomai sur Raspberry Pi 3 : bon espoir mais bilan mitigé

Depuis plusieurs mois, on m’interroge régulièrement sur le support de Xenomai sur Raspberry Pi 3 tant durant mes sessions de formations sur Xenomai que dans des messages par mail. J’avais l’habitude de répondre que Xenomai ne fonctionnait pas encore sur ce modèle de Raspberry Pi.

Une remarque récente de Syrine dans les commentaires de l’article “Xenomai 3 sur Raspberry Pi 2” a attiré mon attention sur un site japonais qui utilise les mêmes commandes que celles présentées dans cet article et fait fonctionner l’ensemble sur un Raspberry Pi 3. J’ai voulu tenter également cette installation. Le résultat est un peu mitigé : Xenomai fonctionne parfaitement avec une bonne stabilité, sauf en ce qui concerne la gestion des interruptions des GPIO qui n’est pas supportée encore. Si vous êtes néanmoins tentés par l’expérience, voici comment procéder simplement.

Compilation et installation

Dans le cadre d’une mise en œuvre professionnelle pour un client je travaillerais en cross-compilation sur une machine de développement de type PC pour produire l’image qui serait installée ensuite sur la cible. Pour ce petit article, j’ai préféré simplifier la mise en œuvre et réaliser une compilation native directement sur le Raspberry Pi 3. Le temps de construction est plus long, mais il reste très raisonnable (2h tout compris pour cette expérience).

Tout d’abord, installons une image de la distribution Raspbian toute neuve. N’utilisez pas la distribution Noob, l’organisation des partitions est différente.

[~]$ sudo dd if=2017-02-16-raspbian-jessie-lite.img of=/dev/sdc bs=4M

Nous démarrons à présent le Raspberry pi 3 sur cette nouvelle distribution. Elle va rebooter automatiquement pour agrandir la partition et occuper tout la carte SD. Connectons-nous

raspberrypi login: pi
Password: raspberry

Il nous faudra quelques outils supplémentaires à ajouter à la distribution d’origine :

pi@raspberrypi:~$ sudo apt install -y git ncurses-dev bc autoconf libtool

Téléchargeons les sources de Xenomai. Je prends la dernière version disponible à ce jour :

pi@raspberrypi:~$ wget http://xenomai.org/downloads/xenomai/stable/xenomai-3.0.3.tar.bz2
pi@raspberrypi:~$ tar xjf xenomai-3.0.3.tar.bz2
pi@raspberrypi:~$ ls xenomai-3.0.3/kernel/cobalt/arch/arm/patches/
ipipe-core-3.10.32-arm-13.patch  ipipe-core-3.18.20-arm-9.patch  README
ipipe-core-3.14.44-arm-16.patch  ipipe-core-4.1.18-arm-4.patch

Le patch ipipe le plus récent proposé par Xenomai s’applique sur un noyau Linux 4.1. Nous avons de la chance, il existe une branche 4.1 pour le kernel spécifiquement modifié pour Raspberry Pi. Téléchargeons cette branche. L’option --depth 1 raccourcit le temps de téléchargement (2 à 3 minutes) en limitant l’historique au seul dernier commit :

pi@raspberrypi:~$ git clone https://github.com/raspberrypi/linux.git -b rpi-4.1.y --depth 1
pi@raspberrypi:~$ head -4 linux/Makefile
VERSION = 4
PATCHLEVEL = 1
SUBLEVEL = 21
EXTRAVERSION =
pi@raspberrypi:~$

Le noyau est un 4.1.21. Il n’y a pas beaucoup de différences avec le 4.1.18, Xenomai fonctionnera. Néanmoins une option de configuration a été modifiée, et pour que le patch ipipe puisse s’applique nous devons le modifier. Pour cela, j’ai préparé un petit patch (un patch de patch, cela explique qu’il contienne un signe '+' décalé) que nous téléchargeons :

pi@raspberrypi:~$ wget https://www.blaess.fr/christophe/files/article-2017-03-20/001-adapt-4.1.18-patch-to-rpi-4.1.21-kernel.patch

Appliquons ce mini-patch à Xenomai.

pi@raspberrypi:~$ ls
001-adapt-4.1.18-patch-to-rpi-4.1.21-kernel.patch  linux  xenomai-3.0.3  xenomai-3.0.3.tar.bz2
pi@raspberrypi:~$ cd xenomai-3.0.3/
pi@raspberrypi:~/xenomai-3.0.3$ patch -p1 < ../001*
patching file kernel/cobalt/arch/arm/patches/ipipe-core-4.1.18-arm-8.patch
pi@raspberrypi:~/xenomai-3.0.3$

Nous pouvons maintenant appliquer le patch ipipe modifié au noyau Linux que nous avons téléchargé :

pi@raspberrypi:~/xenomai-3.0.3$ ./scripts/prepare-kernel.sh --arch=arm --linux=../linux --ipipe=kernel/cobalt/arch/arm/patches/ipipe-core-4.1.18-arm-8.patch

Il y a quelques messages indiquant un décalage entre le noyau standard et le noyau pour Raspberry Pi (offset xx lines) mais la commande patch arrive à résoudre ces problèmes (Hunk #x succeeded).

Un second patch va être nécessaire. Comme je l’indiquais dans cet article, il s’agit d’une gestion des timers spécifique au Raspberry Pi.

pi@raspberrypi:~/xenomai-3.0.3$ cd ..
pi@raspberrypi:~$ wget https://www.blaess.fr/christophe/files/article-2017-03-20/002-xenomai-3-on-bcm-2709.patch
pi@raspberrypi:~$ cd linux
pi@raspberrypi:~/linux$ patch -p1 < ../002*

Nous allons compiler ce noyau. Pour cela, j’ai préparé un fichier de configuration qui regroupe les options nécessaires. Il s’agit d’une configuration un peu allégée pour réduire le temps de compilation ; s’il vous manque des fonctionnalités, n’hésitez pas à l’éditer (avec make menuconfig) et la modifier :

pi@raspberrypi:~/linux$ wget https://www.blaess.fr/christophe/files/article-2017-03-20/linux.config
pi@raspberrypi:~/linux$ mv linux.config .config

Pour la compilation proprement dite, le Raspberry Pi 3 va être très sollicité, d’autant que nous occupons ses quatre cœurs au maximum (option -j 4 pour quatre jobs en parallèle).
Vu la chaleur qu’il dégage, je vous conseille de le placer de façon à ce que le processeur soit bien ventilé (pas de boîtier fermé). L’idéal consiste à placer sur le processeur un petit radiateur de dissipation comme celui-ci.

 

Pour un Raspberry Pi 3 dans un boîtier fermé sans dissipateur, j’aurais tendance à supprimer l’option -j 4 de la ligne suivante, afin de soulager la charge du processeur, au prix d’un temps de compilation  plus long.

pi@raspberrypi:~/linux$ time make -j 4
[...]
  IHEX2FW firmware/keyspan_pda/keyspan_pda.fw
  IHEX2FW firmware/keyspan_pda/xircom_pgs.fw

real    103m36.178s
user    277m51.420s
sys     13m39.250s
pi@raspberrypi:~/linux$ 
pi@raspberrypi:~/linux$

Comme vous le voyez, il faut environ 1h30 de compilation sur un Raspberry Pi 3 pour obtenir notre noyau. Ne soyez pas surpris de voir passer pendant la compilation des warnings indiquant du code douteux. Ils se produisent tous dans des modules spécifiques au Raspberry Pi ; c’est leur niveau inégal de qualité qui a empêché leur intégration dans le noyau Linux standard.

Nous allons installer ce nouveau kernel à côté de celui de la distribution Raspbian afin de pouvoir revenir en arrière en cas de problème :

pi@raspberrypi:~/ipipe$ sudo cp arch/arm/boot/zImage /boot/kernel-xenomai.img
pi@raspberrypi:~/ipipe$ sudo make modules_install
pi@raspberrypi:~/ipipe$ sudo make dtbs_install
pi@raspberrypi:~/ipipe$ ls /boot/dtbs/4.1.21-xenomai+/
bcm2709-rpi-2-b.dtb  bcm2710-rpi-3-b.dtb  overlays

Le nouveau noyau, ses modules et son device tree étant installés, nous devons modifier le fichier de configuration du bootloader pour lui indiquer quel kernel charger :

pi@raspberrypi:~/ipipe$ sudo nano /boot/config.txt

Ajoutez les deux lignes suivantes à la fin du fichier :

kernel=kernel-xenomai.img
device_tree=dtbs/4.1.21-xenomai+/bcm2710-rpi-3-b.dtb

Testons notre noyau incluant ipipe :

pi@raspberrypi:~/ipipe$ sudo reboot

Si le système ne redémarre pas, montez la carte SD sur un PC, mettez en commentaire les deux lignes ci-dessus (en les précédant d’un '#') pour redémarrer sur la distribution Raspbian initiale. Vérifiez bien l’emplacement du noyau, du device tree, et le contenu du fichier config.txt.

Le Raspberry Pi 3 ayant bien redémarré sur le noyau patché avec ipipe, nous pouvons vérifier sa présence ainsi

raspberrypi login: pi
Password: raspberry
[...]
pi@raspberrypi:~$ uname -a
Linux raspberrypi 4.1.21-xenomai+ #1 SMP PREEMPT Sat Mar 18 10:12:21 UTC 2017 armv7l GNU/Linux
pi@raspberrypi:~$ cat /proc/ipipe/version
8
pi@raspberrypi:~$ cat /proc/xenomai/version
3.0.3
pi@raspberrypi:~$

Le travail n’est pas terminé pour autant, nous devons compiler les bibliothèques et les outils de tests de Xenomai.

pi@raspberrypi:~$ cd xenomai-3.0.3/
pi@raspberrypi:~/xenomai-3.0.3$ ./scripts/bootstrap

Cette étape reste silencieuse durant quelques minutes. Laissez le script travailler, il n’est pas bloqué.

pi@raspberrypi:~/xenomai-3.0.3$ ./configure --enable-smp
pi@raspberrypi:~/xenomai-3.0.3$ make
pi@raspberrypi:~/xenomai-3.0.3$ sudo make install

Deux heures après le début de notre expérience, Xenomai est prêt à être utilisé. Le test le plus simple – et l’un des plus représentatifs – consiste à mesure les fluctuations d’un timer. Pour cela un outil est directement fourni. Je le lance en lui demandant de s’exécuter pendant 60 secondes :

pi@raspberrypi:~/xenomai-3.0.3$ sudo /usr/xenomai/bin/latency -T 60
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|     -3.594|     -2.786|      1.822|       0|     0|     -3.594|      1.822
RTD|     -3.647|     -2.923|      0.051|       0|     0|     -3.647|      1.822
RTD|     -3.595|     -2.920|      1.613|       0|     0|     -3.647|      1.822
RTD|     -3.648|     -2.946|     -0.106|       0|     0|     -3.648|      1.822
[...]
RTD|     -3.616|     -2.936|     -0.230|       0|     0|     -5.017|      1.863
RTD|     -3.616|     -2.871|      1.488|       0|     0|     -5.017|      1.863
RTD|     -3.669|     -2.848|      0.186|       0|     0|     -5.017|      1.863
---|-----------|-----------|-----------|--------|------|-------------------------
RTS|     -5.017|     -2.893|      1.863|       0|     0|    00:01:00/00:01:00
pi@raspberrypi:~/xenomai-3.0.3$

Ces premiers résultats sont intéressants, ce sont les deux dernières colonnes qui sont les plus significatives.

La dernière colonne indique la pire latence mesurée, c’est à dire le pire retard de déclenchement d’un timer périodique. La valeur de 1,863 microsecondes est excellente, mais le système est au repos et ce n’est pas représentatif.
L’avant-dernière valeur montre la meilleure latence observée. Elle est négative (-5,017 microsecondes), ce qui indique que le timer s’est déclenché plus tôt que prévu. En effet, Xenomai anticipe les retards inhérents au matériel en déclenchant les timers un peu en avance. Ceci est intéressant pour avoir une bonne précision, mais nécessite une calibration. Nous pouvons consulter l’avance par défaut :

pi@raspberrypi:~/xenomai-3.0.3$ cat /proc/xenomai/latency 
10052

La valeur est de 10052 nanosecondes soit 10,052 microsecondes. Tous les timers sont donc anticipés de 10 microsecondes environ. Ceci peut être intéressant en production, mais dans un cadre expérimental, ce sont les vraies valeurs de latences qui m’intéressent. Je désactive donc cette avance :

pi@raspberrypi:~/xenomai-3.0.3$ sudo -i
root@raspberrypi:~# echo 0 > /proc/xenomai/latency 
root@raspberrypi:~# cat /proc/xenomai/latency 
0
root@raspberrypi:~# exit

Je relance la mesure pendant une minute pour vérifier :

[...]
RTD|      6.385|      7.073|      9.979|       0|     0|      5.405|     35.980
RTD|      6.437|      7.077|     10.499|       0|     0|      5.405|     35.980
RTD|      6.436|      7.074|      9.561|       0|     0|      5.405|     35.980
RTD|      6.384|      7.083|      9.874|       0|     0|      5.405|     35.980
---|-----------|-----------|-----------|--------|------|-------------------------
RTS|      5.405|      7.142|     35.980|       0|     0|    00:01:00/00:01:00

Presque 36 microsecondes de latence, voilà qui est plus réaliste (et très bien, notons-le).

Je vais lancer une nouvelle mesure pendant une heure en conservant un histogramme des latences observées :

pi@raspberrypi:~$ sudo /usr/xenomai/bin/latency  -T 3600 -g histo-01.plot
[...]
RTD|      6.492|      7.145|      9.825|       0|     0|      4.229|     36.862
RTD|      6.439|      7.146|      9.877|       0|     0|      4.229|     36.862
RTD|      6.491|      7.166|      9.877|       0|     0|      4.229|     36.862
HSH|--param|--samples-|--average--|---stddev--
HSS|    min|      3600|      5.972|      0.205
HSS|    avg|   3600017|      6.586|      0.870
HSS|    max|      3600|      9.651|      1.783
---|-----------|-----------|-----------|--------|------|-------------------------
RTS|      4.229|      7.199|     36.862|       0|     0|    01:00:00/01:00:00
pi@raspberrypi:~/xenomai-3.0.3$

L’histogramme peut être dessiné par Gnuplot. En abscisse la latence observée en microsecondes et en ordonnée le nombre d’occurrences de chaque classe. Le résultat est le suivant :

Xenomai latency - Low system load

Il est intéressant de voir que très peu d’occurrences se produisent au-delà de 10 microsecondes. Pour avoir un aperçu plus précis sur ce qui se passe au-delà de 13 microsecondes, il est préférable de faire une représentation logarithmique en ordonnée qui va dilater et rendre plus visibles les faibles occurrences :

Xenomai latency - Low system load

La mesure a été faite alors que le système était au repos, ce qui ne reflète pas un comportement en production. Je relance la mesure en ajoutant une très forte charge du système avec le script dohell fourni avec Xenomai :

pi@raspberrypi:~$ sudo /usr/xenomai/bin/dohell 3600 & sudo /usr/xenomai/bin/latency  -T 3600 -g histo-02.plot
RTD|      7.690|     14.418|     49.044|       0|     0|      5.644|     62.846
RTD|      7.637|     14.028|     37.637|       0|     0|      5.644|     62.846
RTD|      7.585|     14.297|     44.356|       0|     0|      5.644|     62.846
RTD|      8.261|     14.237|     33.939|       0|     0|      5.644|     62.846
HSH|--param|--samples-|--average--|---stddev--
HSS|    min|      3600|      7.507|      0.799
HSS|    avg|   3600006|     14.871|      5.938
HSS|    max|      3600|     41.476|      4.462
---|-----------|-----------|-----------|--------|------|-------------------------
RTS|      5.644|     15.366|     62.846|       0|     0|    01:00:00/01:00:00

En outre, des rafales de ping en mode flood provenaient régulièrement d’un PC, produisant de nombreuses interruptions réseau.

Xenomai latency - High system load

Nous voyons donc qu’il y a une latence intrinsèque de l’ordre de 4.2 microsecondes au repos, et qu’en fonction de la charge du système elle peut aller jusqu’à une soixantaine de microsecondes. Ces résultats sont tout à fait cohérents avec ceux que l’on peut obtenir avec Xenomai sur d’autres cartes à processeur ARM et correspondent bien à ce que l’on attend d’un système d’exploitation complet comme Linux sous des contraintes temps réel fortes.

J’ai également fait l’essai d’ajouter sur la ligne de commande du kernel les options dwc_otg.fiq_enable=0 et dwc_otg.fiq_fsm_enable=0 afin d’éviter l’utilisation des Fast Interrupt Request qui perturbent le déterminisme du traitement des autres interruptions par Xenomai. Cela n’a pas changé les performances observées.

Conclusion

Xenomai 3.0.3 s’installe bien sur un Raspberry Pi 3. La gestion des timers est précise et présente peu de latences, même sous une forte charge système et interruptive.

Toutefois, il y a un point très décevant : je ne suis pas arrivé à gérer (avec l’API RTDM) les handlers d’interruptions des GPIO. Je suppose que le patch ipipe n’a pas encore été ajusté pour le Raspberry Pi 3. Il va nous falloir patienter encore un peu, je continuerai à utiliser des Raspberry Pi 2 pour les exemples de mes formations sur le temps réel.

Système audiophile Allo pour Raspberry Pi et Sparky

Les cartes comme le Raspberry Pi peuvent servir de base à des solutions audio. Cependant la conception de leur horloge pose quelques problèmes. Audiophonics m’a proposé de tester un « bundle » (kit audiophile) ALLO qui permet de supprimer les défauts et d’obtenir une réelle qualité audiophile.

ALLO Sparky-Kali-Piano et Volt pour un système audiophile

======== Article sponsorisé ========

J’ai reçu gracieusement un kit pour les tests directement de Bangalore  en Inde. Cet article fait donc  partie des articles sponsorisés. Le matériel est totalement compatible avec le Raspberry Pi. Le kit que j’ai reçu comportait une carte Sparky, c’est donc celle que j’ai utilisée pour ces tests.

Déballage du kit

Une fois la feuille de plastique enlevée, on trouve une boîte en carton. des plaques de mousse protègent le contenu. Ici j’ai enlevé les plaques supérieures. On voit mieux le contenu de la boîte 😉 : à gauche les 4 boîtes des cartes, à droite la boîte de l’alimentation, le multiplicateur de capacité et les câbles.

L’ensemble du matériel sorti du carton comporte également une série d’entretoises et de vis pour le montage mécanique.

La carte Allo Sparky sortie de sa boîte. Enveloppée dans un sachet à bulles rose. J’ai eu un recul au vu de ce sachet. Pas que je n’aime pas le rose, mais pour moi, ce genre de sachet protège contre la triboélectricité, pas contre les décharges d’électricité statique. J’ai fait remonter l’information et ALLO confirme que ces sachets protègent la carte contre les décharges d’électricité statique. Tout va bien 🙂

On trouve également dans la boîte (enveloppées dans un plastique à bulles) les plaques transparentes destinées à recevoir l’ensemble des cartes. La plaque la plus grande est le socle, la plus petite ornée d’un logo Sparky sert de couvercle.

Les différentes cartes

Sparky

La carte Sparky SBC (Single Board Computer) est compatible avec le Raspberry Pi. Elle est équipée d’un processeur ARM A9 Quadruple cœur fonctionnant à 1.1 GHz et d’une RAM DDR3 1 Go. Elle possède un port Ethernet 10/100 Mbits/s, un port HDMI 1080p à 60 fps), deux ports USB 2.0 ainsi qu’un port USB 3.0 OTG. A gauche du port USB 3.0 (en bleu ci-dessus) on trouve un capteur infrarouge grâce auquel on pourra utiliser une télécommande pour piloter cette carte.

Accessibles également : un port LCD et un port Caméra. L’alimentation de la carte se fait par la classique prise micro USB. A noter : la carte est équipée d’origine d’un radiateur digne de ce nom qui devrait limiter la montée en température du CPU. Les 40 ports GPIO sont compatibles avec ceux du Raspberry Pi.

Le « disque dur » est comme sur notre framboise, une carte micro SD. Je regrette juste la faible longueur du connecteur qui me semble moins protéger la carte et la rendre plus sensible à la casse en cas de pression sur son extrémité (le bras de levier est plus grand que sur le Raspberry Pi). Cette carte fonctionne sous Linux et sous Android.

Kali

Kali est une déesse du panthéon hindou. C’est la déesse de la préservation, de la transformation et de la destruction. Elle représente le pouvoir destructeur du temps.
Ici la carte Kali a un rôle de préservation des performances, et de lutte contre les effets du temps. Je m’explique :

« Chaque ordinateur SBC, Raspberry Pi, Sparky ou autre, a un cristal qu’il utilise pour envoyer des signaux numériques à vos DAC », a déclaré Allo. « La précision de ce cristal est très importante pour la façon dont le DAC va transformer le signal numérique en sons analogiques ».

La gigue

Le Raspberry Pi 3, par exemple, comporte une horloge à 19,2 MHz dérivée de son processeur BCM2835. Elle ne peut cadencer correctement un signal 16 bits – 44.1kHZ qui n’est pas un multiple exact de 19,2 MHz. En raison de cette impossibilité de synchronisation liée à la fréquence, la stabilité de la plupart des SBC repose sur un oscillateur bon marché (pour limiter les coûts) avec beaucoup de gigue (jitter).

Cette désynchronisation et cette gigue font que les données sont fournies au DAC à des instants variables par rapport à ce qui avait été enregistré. Du coup, le son qui est généré par les DAC comporte des « erreurs » qui viennent compromettre la qualité de l’écoute.

Du FPGA

La carte Kali est basée sur un circuit logique programmable (FPGA) et une mémoire FIFO de 4 Mo. Cela lui permet de stocker 700ms d’audio. Ce « tampon » permet à la sortie de « reclocker » les échantillons à la sortie et de les faire parvenir à la carte DAC Piano sans aucune gigue. On ne trouve cette fonction de « reclockage » que sur les équipements audiophiles haut de gamme.

L’horloge de sortie de Kali est basée sur un oscillateur à faible gigue de Nihon Dempa Kogyo (NDK), alimenté par un régulateur LDO à faible bruit.

La carte a en fait deux horloges (sur la droite de la photo ci-dessus), une pour l’échantillonnage à 44,1 kHz (fichiers wav) et une autre pour le 48 kHz (flux musical). Les entrées I2S  16, 24 et 32 ​​bits avec des fréquences d’échantillonnage 44,1, 48, 88,2, 96, 176,4 et 192 kHz peuvent être re-synchronisées sur une sortie I2S.

La sélection de la longueur du mot et de la fréquence d’échantillonnage est faite automatiquement par la carte. Des LED vous informent en permanence de l’état de la carte et des fréquences utilisées. Un « Recloker » comme la carte Allo Kali utilise un coefficient multiplicateur d’upsampling (sur-échantillonnage) de 8 fois (352.8kHZ pour les fréquences de 44.1kHZ et de 384kHZ pour les fréquences mlutliples de 48kHZ) pour garantir une réelle précision.

Piano 2.1

La carte PIANO 2.1 HIFI DAC de ALLO est un convertisseur utilisant deux DAC PCM5142 avec DSP intégré et traitant les signaux jusqu’à 32Bit/384kHz. Le circuit est conçu en mode 2.1, avec possibilité d’y relier un caisson de basses (Subwoofer).

La partie numérique a été proprement séparée de la partie analogique. Côté analogique on trouve un LDO LT3042 avec un bruit ultra faible et un excellent PSRR (Power Supply Ripple Rejection = Réjection de l’ondulation de l’alimentation). Pour être précis, chaque carte Piano utilise 4 LDO ! (2 par DAC).

Les sorties D/G sont équipées de prises RCA dorées pour assurer un contact de qualité.

Grâce aux connecteurs J19 et J20, la carte est directement compatible avec l’amplificateur ALLO VOLT. L’ensemble de ces deux cartes étant utilisables avec le ALLO Sparky comme avec le Raspberry Pi 2 et le Pi 3. Dans le cas où vous voulez utiliser Piano 2.1 sur un Raspberry Pi, pensez bien à positionner sur « ON » le switch SW1 (RPI COMPATABILITY). La sortie Subwoofer est réglable de 60 à 200Hz, uniquement sur Max 2 Play.

Multiplicateur de capacité

Le multiplicateur de capacité à transistor multiplie la valeur du condensateur par une quantité égale au gain en courant du transistor. Il simule la présence d’un condensateur de très forte valeur sur l’alimentation.

Ce circuit est habituellement utilisé dans les alimentations à courant continu lorsque la tension d’ondulation résiduelle en charge est d’une importance primordiale, comme dans des amplificateurs de qualité audiophile.

Cette carte n’est en aucun cas un régulateur de tension. La tension de sortie suit la tension d’entrée avec un décalage de 0,65v environ. Son principal intérêt est d’abaisser le bruit résiduel de l’alimentation (le ripple) à des niveaux compatibles avec la qualité HiFi.

Cette conception particulière réduit le bruit issu d’un bloc d’alimentation à découpage (utilisé pour alimenter l’ampli classe D) à des niveaux négligeables (moins de 5mV jusqu’à 1MHz).

L’ensemble des dispositifs mis en œuvre permet d’obtenir un rapport signal/bruit de 112dB et un THD+N de 93dB.

Volt

La carte Volt est le dernier étage du kit (y compris au sens physique 🙂 ). Elle vient se connecter directement sur la carte Piano.

La carte Volt récupère l’audio analogique à la sortie de la carte Piano et l’envoie au circuit intégré Texas Instruments TPA3118D2, un amplificateur classe D délivrant 2 x 25w lorsqu’il est alimenté en 19v. La tension d’alimentation doit être appliquée à la prise Jack de 3 mm.

Attention, cet amplificateur est au format HAT mais n’est pas compatible avec le Raspberry Pi . Il est conçu pour se connecter à la carte Piano ! La sorties vers les haut parleurs se fait sur des borniers à vis, gage de bon contact et de solidité. Le rapport signal bruit (SNR) de l’ampli est de 102 dB. Il peut attaquer des enceintes dont l’impédance va de 4 à 8 Ω et la classe D permet d’obtenir un ampli de puissance élevée, sans radiateur, puisque son rendement est proche de 90%. Il est possible de modifier la fréquence de commutation avec 3 dip-switches pour réduire de possibles interférences dans la bande radio AM.

Le synoptique

Le montage en image

La première étape : Sparky SBC et Kali la recloqueuse 🙂 montée sur le GPIO.

Mise en place de la carte DAC Piano.

La doc recommande de mettre la carte micro SD avant le montage sur les plaques transparentes. Vous voyez ici le débord de la micro SD. Je pense qu’il faudra insérer la carte au dernier moment… Trop de risques de casse.

Le kit est complètement assemblé. L’ampli Volt est venu se poser au dessus de la carte Piano.

N’oublions pas que les cartes ont la taille d’une carte bancaire (pour les plus grandes ! ). On obtient donc un ensemble compact, de taille réduite mais de qualité élevée.

Sur cette vue de côté, la prise d’alimentation (jack 2,5mm) de la carte Kali (la deuxième en partant du bas) recevra l’alimentation 5v provenant de l’alimentation 5v/3A. C’est elle qui sera chargée d’alimenter la carte inférieure (Raspberry Pi ou Sparky) et la carte supérieure (Piano 2.1).

Au dernier étage la carte Volt, ampli classe D, reçoit une alimentation 19 volts lisse, après son passage par le multiplicateur de capacité (prise Jack 3mm).

Vous devriez avoir devant vous un ensemble qui ressemble à ceci (© Audiophonics) :Ici c’est un Raspberry Pi 3 qui est utilisé pour la réalisation de l’ampli audiophile.

Cliquez pour agrandir

Ici l’ensemble obtenu après montage des plaques transparentes avec une carte Piano. J’ai par la suite rajouté des pieds autocollants pour éviter que les têtes de vis ne rayent le meuble sur lequel l’ampli est posé.

Connexion des câbles

La documentation donne l’ordre de branchement des câbles sur le kit ALLO :

  1. Assurez-vous que la carte SD est correctement insérée.
  2. Connectez le câble HDMI et les clavier/souris USB.
  3. Connectez le câble LAN Ethernet.
  4. Branchez les câbles de haut-parleur dans les borniers à vis de sortie. Assurez-vous que le câble du haut-parleur gauche est bien connecté sur la sortie gauche et que le câble du haut-parleur droit est bien connecté sur la sortie droite.
  5. Branchez l’adaptateur + 5V CC sur la carte KALI.
  6. Connectez l’adaptateur secteur  + 19 V continu sur la carte Multiplicateur de Capacité (CM). Connectez la Sortie du CM à l’amplificateur VOLT (voir ci-dessous).

Cette procédure semble compliquée et aurait mérité d’être retravaillée. Le maintien d’un prix bas justifie sans doute l’absence d’une alimentation unique ou d’un système automatisant l’extinction. Ceci impose à l’utilisateur une gymnastique pas forcément simple.

La documentation Vana-Tech-Manual donne l’ordre de branchement (ci-dessus) mais on n’y trouve pas d’indication sur l’opération inverse. Comment procéder à l’extinction de l’ensemble ? Mon avis serait de procéder de façon inverse : débrancher d’abord la prise 19 volts de l’ampli Volt. Attendre un moment (un bon moment) que les tensions disparaissent des condensateurs. Enfin déconnecter la prise Jack 5 volts de la carte Piano.

Les essais

Ubuntu

Le kit est livré avec une carte SD toute prête qui embarque Ubuntu et une série de logiciels pour l’utilisation du kit.

Vous en saurez plus en lisant le manuel VanaPlayer.

En plus de Max2play Kodi est supporté et des applis pour smartphone permettent de piloter l’ensemble depuis votre téléphone. Une distribution Android est également disponible pour Sparky.

Volumio

Comme je suis contrariant et que je préfère utiliser Volumio, je me suis rendu sur la page de téléchargement de Volumio et… Bingo ! il y a une version (récente : 7 mars 2017) de Volumio pour Sparky que je m’empresse de mettre sur une carte SD pour les essais.

Pour les premiers tests j’utilise la carte Piano 2.1 que je relie à des enceintes amplifiées.

Après le démarrage de la distribution ouverture d’une page web sur un PC ou un smartphone (images ci-dessus) il faut indiquer à Volumio quelle carte DAC est utilisée.

On peut ensuite indiquer où le logiciel doit aller chercher la musique (ici MyBookWorld de WD)

Démarrage d’une piste audio et… c’est parti, les LED bleues indiquent comment la carte reclocker Kali traite le signal et la musique est là ! J’ai écouté de la musique qualité CD et des webradios, Volumio tourne depuis plus d’une semaine sur la carte Sparky… Même avec des enceintes de qualité moyenne, la musique semble plus percutante et nette.

Amplificateur Volt

Dernière étape, l’amplificateur Volt. Il nécessite une alimentation 19 volts. Un modèle prévu pour la charge d’un portable fera l’affaire, si vous en avez un en stock.

Voilà celle que j’ai utilisée, capable de fournir plus de 80 watts. Aucun souci en utilisation normale.

N’étant pas audiophile dans l’âme (mais j’ai un mot d’excuse), j’ai fait l’essai sur deux enceintes détournées d’une mini chaîne HiFi. Qualité impeccable, pas de souffle, percussions franches, basses profondes…

Vidéo

Gardez à l’esprit que le son de cette vidéo a été enregistré avec les micros intégrés de la caméra… pas vraiment top comme système 😉

Combien ça coûte ?

Prix relevés sur le site Audiophonics en mars 2017 :

  • Le Multiplicateur de capacité : 17.90€
  • Les plaques transparentes : 12.90€
  • L’adaptateur secteur 5v / 3A : 16.90€
  • L’ampli VOLT classe D 2x25w : 31.90€
  • Le DAC PIANO 2.1 : 51.90€
  • Le reclocker KALI : 84.90€
  • La carte mère Sparky : 42.90€ (peut être remplacée par un Raspberry Pi)

Sans la carte Sparky on est à 216€, à comparer avec les prix des matériels audiophiles 🙂

Conclusion

Cet ensemble, qu’il soit bâti sur la carte Sparky ou sur le Raspberry Pi, a toutes les qualités pour séduire ceux qui sont attentifs à la qualité de leur installation audio.

Le recloking, les DAC séparés pour les deux parties de la bande audio, et un amplificateur en classe D de qualité forment un ensemble cohérent, au design moderne.

J’ai signalé les points négatifs que j’ai trouvés tout au long de l’article (sachet antistatique, taille du connecteur micro SD, alimentations multiples, absence d’interrupteur, complexité de la mise sous tension).

Dans les points positifs je noterai la disponibilité de plusieurs distributions pour cet ensemble. Une abondante documentation est disponible en téléchargement, aussi bien depuis le site Audiophonics que sur le site Allo. Un regret quand même, ces notices sont pour le moment exclusivement en anglais. Normalement en France le matériel est censé être fourni avec un mode d’emploi en français (Art. 2)… Cette lacune sera bientôt comblée puisqu’une notice en français est en préparation.

Si vous avez mis en œuvre cette chaîne audiophile (ou simplement un sous ensemble), n’hésitez pas à utiliser les commentaires sous cet article pour laisser vos impressions.

Sources

Hi-Fi audio stack for Raspberry Pi includes jitter re-timing

Allo RasPi clone hi-fi sounds great

Cet article Système audiophile Allo pour Raspberry Pi et Sparky a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Conférence Raspberry Pi à la Librairie Eyrolles – 15 mars 2017

A l’invitation de la Librairie Eyrolles et avec la participation des Editions ENI, j’ai animé une conférence sur le Raspberry Pi, samedi 11 mars après midi. Quelques images souvenir…

Conférence Raspberry Pi à la Librairie Eyrolles – Paris

Direction Paris

Le voyage commence le matin… Depuis la Bourgogne, Paris c’est 1h30 de TGV. Pas le bout du monde, mais quelques centaines de kilomètres à parcourir quand même.

Une occasion de jeter un coup d’œil sur le WiFi dont la ligne est fraîchement équipée. Après avoir ouvert un navigateur, on me demande de m’identifier avec mon numéro de dossier… Mmmouais… Bon, je range mon téléphone, l’expérience n’aura pas duré bien longtemps.

Une fois descendu du TGV, faire la queue pour acheter des tickets de métro et c’est parti.

Direction Saint-Michel où le métro arrive pratiquement au pied de la Fontaine Saint-Michel. Cette fontaine symbolise la lutte du bien et du mal…

Prémonition ? Et si on disait… je sais pas, moi ? Euhh que Linux ce serait le bien … Ce serait qui le dragon ? Hein?

Comme il fait beau et que j’ai un peu de temps avant le début de la conférence, je fais une petit détour (tout petit) en longeant la seine avant de rejoindre le boulevard Saint-Michel.

Un peu de tourisme

Cliquer pour agrandir.

Après le tourisme 😉 direction le boulevard Saint-Germain.

La Librairie Eyrolles

Cliquez pour agrandir.

Toujours impressionnante l’arrivée à la Librairie Eyrolles qui occupe la totalité du rez de chaussée de ce bâtiment ainsi que le sous-sol ! L’informatique c’est à l’extrémité, dans le fond de l’image.

Se voir en photo dans une vitrine ça fait bizarre…

Avec mon bouquin en déco 🙂

Cliquer pour agrandir.

Il y a aussi des Raspberry Pi et un kit de démarrage avec boîtier, alim…

Cliquer pour agrandir.

Dans la librairie on trouve regroupés sur un présentoir les différents livres associés au Raspberry Pi (Pi3 ou Pi Zero, Python pour le Pi et Scratch).

Pour les lecteurs Parisiens du blog, il faut savoir que la Librairie Eyrolles vend également du matériel. Vous y trouverez des Raspberry Pi (les Pi Zero étaient attendus) et accessoires mais aussi de l’Arduino…

La conférence en images

Les premiers participants sont déjà là… Les premières questions aussi 😉 Ensuite je commence la conférence.

La salle était remplie. L’âge des participants reflétait bien celui des utilisateurs du Raspberry Pi, du plus jeune au plus âgé, tous passionnés. Certaines personnes ne voyaient pas l’écran du fait de la configuration de la salle. Désolé pour cela.

Les personnes présentes ont participé à l’animation de la conférence en rapportant des expériences (positives ou négatives) toujours enrichissantes, ou en posant des questions pour approfondir un sujet (ou quand je n’étais pas très clair 🙂 ).

Discussion avec les participants à la conférence

Après la conférence on peut échanger. Ce moment de discussion est très intéressant et très riche. C’est l’occasion de répondre aux questions (quand je peux 😀 ) mais aussi d’avoir des retours en direct sur le blog, les livres, la conférence…

Les dédicaces

Là … quand on écrit des bouquins c’est un moment privilégié. On personnalise le livre pour celui qui l’a acheté, va le lire, ou a déjà commencé à le lire 🙂

Sarah auteur du livre Scratch paru aux Éditions ENI a également été sollicitée pour dédicacer son livre 🙂

Les auteurs

Le passage chez Eyrolles m’a aussi permis d’échanger avec Sarah Lacaze, qui a écrit le livre Scratch et est venue assister à la conférence.

Présents également Christophe Blaess (à gauche, auteur de plusieurs livres parus chez Eyrolles sur le développement Linux, le shell ou le temps réel appliqué au Raspberry Pi) et Pierre Ficheux (à droite, auteur d’articles, de plusieurs livres sur Linux embarqué et temps réel).

Je remercie ces trois confrères de s’être déplacés pour suivre ma conférence 🙂

Conclusion

Une belle journée de rencontres et de discussions, organisée par la librairie Informatique d’Eyrolles (merci à Kunthéa et à son équipe) et les Editions ENI avec la présence de Stéphane.

Cet article Conférence Raspberry Pi à la Librairie Eyrolles – 15 mars 2017 a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Un noyau 4.10 sur un Raspberry Pi 3 64 bits

Vanilla kernel 4.10 on 64 bits Raspberry Pi 3

Lorsque nous recompilons un noyau Linux pour le Raspberry Pi, nous avons généralement l’habitude d’utiliser un kernel spécifique, disponible sur https://github.com/raspberrypi/linux contenant des drivers absents du noyau standard. Il est néanmoins possible de faire fonctionner sur la plupart des modèles de Raspberry Pi un noyau Linux parfaitement standard (aussi dit Vanilla Kernel). Ceci au prix de quelques efforts de configuration que nous allons voir.

À titre d’exemple, nous allons installer un noyau Linux 4.10.1 (diffusé depuis deux semaines) sur un Raspberry Pi 3.

En outre, nous allons faire fonctionner le Raspberry Pi 3 en mode 64 bits et utiliser le bootloader industriel U-boot !

Un avertissement pour commencer. Les étapes que nous allons suivre sont très simples, un peu longues mais très simples. Le résultat néanmoins ne sera pas spectaculaire, loin s’en faut.

Je n’ai pour l’instant pas réussi à faire fonctionner le support pour la console (ni HDMI, ni LVDS), aussi est-on limité à une connexion par le port série. L’intérêt est donc purement technique de voir son Raspberry Pi 3 fonctionner en mode 64 bits avec un kernel standard. Dans quelques temps peut-être, l’ensemble du système pourra s’exécuter de la sorte.

Intérêt de cette expérimentation

32 bits vs 64 bits ?

Le system-on-chip autour duquel est construit le Raspberry Pi 3 est un Broadcom BCM2837 comportant un processeur quad-cœurs Cortex A53. Ce dernier peut fonctionner en utilisant un jeu d’instructions ARMv8 64 bits. Néanmoins les distributions actuelles pour Raspberry Pi, afin d’assurer la compatibilité avec le Raspberry Pi 2, continuent de le faire fonctionner avec le jeu d’instructions ARMv7 32 bits (pour les Raspberry Pi 2 et 3, le bootloader charge le noyau kernel7.img alors qu’il charge le noyau kernel.img au format ARMv6 pour les modèles 1 et 0).

Que signifie qu’un processeur fonctionne en 32 ou 64 bits ? Il s’agit de la taille des registres du CPU, c’est-à-dire la taille maximale des données qu’il peut manipuler en une seule opération. L’effet le plus immédiatement visible du passage de 32 en 64 bits, est la taille de l’espace d’adressage qui passe de 232 octets (4 Gio) à 264 octets. Ceci ne présente pas particulièrement d’intérêt pour le Raspberry Pi 3 dont la quantité de RAM reste fixée à 1 Gio non extensible.

En ce qui concerne le passage en 64 bits, aucun intérêt réel donc hormis le challenge technique.

Vanilla kernel ?

Le fait d’utiliser un noyau standard en revanche est beaucoup plus intéressant pour tous les intégrateurs qui sont amenés à appliquer des patches provenant de diverses sources (par exemple PREEMPT_RT) ou à incorporer des drivers spécifiques développés indépendamment du Raspberry Pi.

Ces patches, ces drivers sont quasiment toujours fournis en référence au noyau Linux standard et leur intégration dans un noyau spécifiquement modifié peut être complexe.

Même si mes résultats avec le Raspberry Pi 3 et le noyau standard sont encore limités (pas de console), le principe décrit ici est valable pour les autres modèles qui fonctionnent beaucoup mieux. Pour cet aspect, l’intérêt est plus évident.

Bootloader U-boot

Le fait d’employer un bootloader libre de qualité industrielle comme U-Boot est très intéressant pour pouvoir “scripter” des procédures spécifiques de démarrage.

On pourra l’employer, en modifiant le script de démarrage, par exemple pour  :

  • démarrer sur une carte micro-SD minimale puis aller chercher le noyau et le système de fichiers dans un répertoire sur le réseau,
  • démarrer un noyau spécifique sélectionné en pressant un bouton relié aux bornes GPIO,
  • construire un système de mise à jour solide avec retour en arrière en cas d’erreur,
  • etc.

L’intérêt de l’expérimentation ci-dessous est donc nettement plus important en ce qui concerne cet aspect, pour disposer d’une base d’essai des scripts pour U-boot.

Environnement de construction

Après des essais assez longs de diverses méthodes (Crosstool-NG, compilations manuelles du kernel et de Busybox, etc.), j’ai décidé de m’appuyer sur l’outil Buildroot pour nous fournir un environnement de construction du système assez complet.

J’ai regroupé toute la configuration spécifique dans une recette defconfig pour Buildroot, qu’il nous suffit d’intégrer dans le projet standard. Il faudra également réaliser quelques opérations pour l’installation après la compilation.

La première étape consiste à télécharger la dernière version de Buildroot sur un PC de travail sous Linux (on peut réaliser cette opération sur un Raspberry Pi 3, mais elle durera plus longtemps) :

[~]$ mkdir Vanilla-Pi-3
[~]$ cd Vanilla-Pi-3/
[Vanilla-Pi-3]$ wget https://buildroot.org/downloads/buildroot-2017.02.tar.bz2
[Vanilla-Pi-3]$ tar xjf buildroot-2017.02.tar.bz2

Nous allons ajouter un fichier de recette dans le répertoire config/ de Buildroot. Lorsque j’aurai trouvé le temps de l’affiner et de la compléter, je la ferai parvenir aux développeurs de ce projet.

[Vanilla-Pi-3]$ cd buildroot-2017.02/configs/
[configs]$ wget http://www.blaess.fr/christophe/files/article-2017-03-13/raspberrypi3_64_defconfig 
[configs]$ cd ..

Nous demandons à Buildroot d’utiliser cette configuration :

[buildroot-2017.02]$ make raspberrypi3_64_defconfig

Si vous le souhaitez, vous pouvez explorer la configuration avec :

[buildroot-2017.02]$ make menuconfig

On y voit que j’ai choisi :

  • une toolchain de compilation pour Arm 64 bits, je me suis inspiré de la configuration Raspberry Pi 64 bits de Crosstool-NG.
  • un noyau standard 4.10.1 avec la configuration par défaut pour l’architecture Arm64.
  • un bootloader U-boot avec une configuration Raspberry Pi 3 (par défaut : 64 bits).
  • Busybox et les scripts de démarrage pour un système minimal

Nous pouvons ensuite lancer la compilation avec

[buildroot-2017.02]$ make

Cette étape a une durée variable suivant la puissance de votre processeur et votre lien Internet. Elle s’exécute en général pendant quelques dizaines de minutes.

Si un message d’erreur indique l’impossibilité de produire la cible bcm2837-rpi-3-b.dtb, c’est qu’il vous manque le Device Tree Compiler dtc et que vous devez l’ajouter sur votre machine. Par exemple sur un PC Ubuntu, il s’installe ainsi : sudo apt install device-tree-compiler.

Installation

Une fois le système compilé, nous allons l’installer sur une carte micro-SD. J’insère cette carte dans un adaptateur USB que je branche sur mon PC. Elle est alors automatiquement montée et le gestionnaire de fichiers m’affiche son contenu. Je commence par démonter manuellement la carte (ne pas le faire en cliquant sur l’icône d’éjection du gestionnaire de fichiers, sinon elle sera inaccessible).

[buildroot-2017.02]$ umount /media/$USER/*

Il va falloir partitionner (par exemple avec gparted ou fdisk) cette carte en deux partitions : la première d’une centaine de mégaoctets environ, la seconde couvrant le reste de la carte SD. Voici le résultat attendu :

[buildroot-2017.02]$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
[...]
sdc      8:32   1  1,9G  0 disk 
├─sdc1   8:33   1  128M  0 part 
└─sdc2   8:34   1  1,8G  0 part 
[...]

Nous formatons ces deux partitions, et en profitons pour les nommer boot et root par convention. Attention, les noms sdc1 et sdc2 sont spécifiques à ce que je vois sur ma machine, issus de la commande lsblk ci-dessus. Adaptez les bien à votre situation.

[buildroot-2017.02]$ sudo mkfs.vfat -n boot /dev/sdc1
[buildroot-2017.02]$ sudo mkfs.ext4 -L root /dev/sdc2

Extrayez la carte micro-SD et réinserez-la pour qu’elle soit automatiquement montée sur votre système, et vérifiez ainsi :

[buildroot-2017.02]$ ls /media/$USER/
boot  root

Il ne nous reste plus qu’à y copier les fichiers produits par Buildroot :

  • Image est le noyau Linux au format de l’architecture Arm64 (celui qu’on a l’habitude de voir sous le nom zImage ou vmlinuz sur d’autres architectures).
  • u-boot.bin est le bootloader U-Boot : il s’agit d’un outil très puissant permettant de charger et démarrer le noyau Linux en étant très largement configurable par des scripts. Nous en écrirons un petit exemple ultérieurement.
  • bcm2837-rpi-3-b.dtb est le blob binaire représentant la plate-forme matérielle Raspberry Pi 3 sous forme d’un Device Tree. Le noyau Image est générique pour toute plateforme Arm64 et c’est ce fichier qui lui indique sur quel système il s’exécute.
  • rootfs.tar est une archive tar contenant toute l’arborescence du système de fichiers (les répertoires /bin/, /dev/, /etc/, /usr/…).
[buildroot-2017.02]$ cp output/images/Image /media/$USER/boot/
[buildroot-2017.02]$ cp output/images/u-boot.bin  /media/$USER/boot/
[buildroot-2017.02]$ cp output/images/bcm2837-rpi-3-b.dtb /media/$USER/boot/
[buildroot-2017.02]$ sudo tar xf output/images/rootfs.tar -C /media/$USER/root
[buildroot-2017.02]$ cd ..

Nous avons installé un bootloader générique U-boot (que l’on retrouve sur la plupart des systèmes embarqués industriels). Néanmoins cela n’est pas suffisant, car au démarrage le Raspberry Pi est conçu pour charger un premier bootloader spécifique (et propriétaire). Nous devons l’y installer également et c’est lui qui viendra exécuter u-boot.bin.

[Vanilla-Pi-3]$ git clone https://github.com/raspberrypi/firmware

Le téléchargement est un peu long, car il y a eu de nombreuses versions successives, et comme elles sont fournies sous formes binaires, le stockage n’est pas limité aux différences entre versions. L’installation est très simple :

[Vanilla-Pi-3]$ cp -R firmware/boot/* /media/$USER/boot

Il nous reste trois petits fichiers à créer manuellement (attention aux fautes de frappe, cette étape est très sensible).

  • config.txt est lu par le bootloader primaire du Raspberry Pi (le fichier bootcode.bin). Nous allons lui indiquer de charger le Device Tree produit par Buildroot et de démarrer le second bootloader U-boot.
  • cmdline.txt est également lu par bootcode.bin. Il contient une seule ligne de texte, c’est la ligne de paramètres qui sera passée au noyau Linux (insérée dans le Device Tree).
  • boot.scr est un petit script pour U-boot lui indiquant de démarrer le noyau Image. Ce script est lui-même obtenu par compilation d’un petit fichier source.

Voici les contenus des deux premiers fichiers qui doivent être copiés dans /media/$USER/boot :

config.txt:
 kernel=u-boot.bin
 arm_control=0x200
 enable_uart=1
 device_tree_address=0x100
 device_tree=bcm2837-rpi-3-b.dtb

 

cmdline.txt:
 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait

Attention, le contenu de ce deuxième fichier doit tenir sur une seule ligne.

Le contenu du fichier source à compiler pour U-boot est le suivant :

boot.source:
 fatload mmc 0:1 ${kernel_addr_r} Image
 booti ${kernel_addr_r} - ${fdt_addr_r}

Son rôle est de charger le noyau Image en mémoire depuis la première partition de la carte micro-SD, puis de le démarrer en lui passant l’adresse du Device Tree. Pour le compiler on exécute :

[Vanilla-Pi-3]$ mkimage -A arm -O linux -T script -C none -n boot.scr -d boot.source  boot.scr

Si un message d’erreur vous indique l’absence de l’outil mkimage, installez-le sur votre système, par exemple sur Ubuntu on fera sudo apt install u-boot-tools.

Finalement, nous pouvons terminer en copiant ce fichier et en démontant la carte micro-SD.

[Vanilla-Pi-3]$ cp boot.scr /media/$USER/boot/
[Vanilla-Pi-3]$ umount /media/$USER/*

Test du noyau Vanilla 4.10.1 en mode 64 bits

Comme je l’indiquais au début de cet article, je n’ai pas réussi à faire fonctionne la sortie HDMI ni LVDS de Linux avec cette configuration. Il faut donc utiliser une connexion sur le port série du Raspberry Pi 3. Voici les lignes que je vois apparaître dans la console série de mon PC lors du boot. Cela commence par des messages provenant de U-boot :

U-Boot 2017.01 (Mar 10 2017 - 20:13:02 +0100)

DRAM:  944 MiB
RPI 3 Model B (0xa02082)
MMC:   bcm2835_sdhci: 0
reading uboot.env

** Unable to read "uboot.env" from mmc0:1 **
Using default environment

Cet avertissement est normal, nous n’avons pas fourni de fichier contenant des variables d’environnement personnalisées pour U-boot.

In:    serial
Out:   lcd
Err:   lcd
Net:   Net Initialization Skipped
No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 3 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
       scanning usb for ethernet devices... 1 Ethernet Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
reading /boot.scr
151 bytes read in 24 ms (5.9 KiB/s)
## Executing script at 02000000

U-boot a trouvé notre script et l’a chargé. Il l’exécute.

reading Image
14862848 bytes read in 956 ms (14.8 MiB/s)
## Flattened Device Tree blob at 00000100
   Booting using the fdt blob at 0x000100
   Loading Device Tree to 000000003ab28000, end 000000003ab2dcaf ... OK

Starting kernel ...

Après lecture du fichier Image et détection de la présence d’un Device Tree chargé en mémoire par le bootloader primaire du Raspberry Pi, U-boot démarre le noyau. Sur une console texte (HDMI, LVDS, A/V) c’est là que les messages s’arrêtent…

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.10.1 (logilin@TR-B-02) (gcc version 5.4.0 (Buildroot 2017.02) ) #1 SMP PREEMPT Fri Mar 10 20:28:37 CET 2017
[    0.000000] Boot CPU: AArch64 Processor [410fd034]

Nous pouvons d’ores et déjà observer l’architecture Arm 64 bits (AArch64) et le numéro du dernier noyau vanilla (4.10.1).

[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 16 MiB at 0x0000000039800000
[    0.000000] WARNING: x1-x3 nonzero in violation of boot protocol:
[    0.000000]  x1: 0000000000000000
[    0.000000]  x2: 0000000000000000
[    0.000000]  x3: 0000000000080000
[    0.000000] This indicates a broken bootloader or old kernel
[    0.000000] percpu: Embedded 21 pages/cpu @ffff80003af8c000 s48024 r8192 d29800 u86016
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: enabling workaround for ARM erratum 845719
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 237888
[    0.000000] Kernel command line: earlyprintk console=ttyAMA0 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 dma.dmachans=0x7f35 bcm2709.boardrev=0xa02082 bcm2709.serial=0xf7bb84e8 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait

Le bootloader primaire du Raspberry Pi enrichit la ligne de paramètres du noyau de manière substantielle comme nous pouvons l’observer ici (par rapport à notre fichier cmdline.txt).

[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.000000] Memory: 916920K/966656K available (8636K kernel code, 946K rwdata, 3848K rodata, 1024K init, 392K bss, 33352K reserved, 16384K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     modules : 0xffff000000000000 - 0xffff000008000000   (   128 MB)
[    0.000000]     vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000   (129022 GB)
[    0.000000]       .text : 0xffff000008080000 - 0xffff0000088f0000   (  8640 KB)
[    0.000000]     .rodata : 0xffff0000088f0000 - 0xffff000008cc0000   (  3904 KB)
[    0.000000]       .init : 0xffff000008cc0000 - 0xffff000008dc0000   (  1024 KB)
[    0.000000]       .data : 0xffff000008dc0000 - 0xffff000008eaca00   (   947 KB)
[    0.000000]        .bss : 0xffff000008eaca00 - 0xffff000008f0ea4c   (   393 KB)
[    0.000000]     fixed   : 0xffff7dfffe7fd000 - 0xffff7dfffec00000   (  4108 KB)
[    0.000000]     PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000   (    16 MB)
[    0.000000]     vmemmap : 0xffff7e0000000000 - 0xffff800000000000   (  2048 GB maximum)
[    0.000000]               0xffff7e0000000000 - 0xffff7e0000ec0000   (    14 MB actual)
[    0.000000]     memory  : 0xffff800000000000 - 0xffff80003b000000   (   944 MB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000]  Build-time adjustment of leaf fanout to 64.
[    0.000000]  RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=4
[    0.000000] NR_IRQS:64 nr_irqs:64 0
[    0.000000] arm_arch_timer: WARNING: Invalid trigger for IRQ1, assuming level low
[    0.000000] arm_arch_timer: WARNING: Please fix your firmware
[    0.000000] arm_arch_timer: WARNING: Invalid trigger for IRQ2, assuming level low
[    0.000000] arm_arch_timer: WARNING: Please fix your firmware

Tiens ? Apparemment il y a une petite incompatibilité de gestion des timers. Ce message va se répèter à quelques reprises.

[    0.000000] arm_arch_timer: Architected cp15 timer(s) running at 19.20MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[    0.000006] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[    0.000175] Console: colour dummy device 80x25
[    0.001340] console [tty1] enabled
[    0.001385] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800)
[    0.001437] pid_max: default: 32768 minimum: 301
[    0.001551] Security Framework initialized
[    0.001623] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
[    0.001656] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
[    0.011920] ASID allocator initialised with 65536 entries
[    0.032584] EFI services will not be available.
[    0.048013] smp: Bringing up secondary CPUs ...
[    0.080151] Detected VIPT I-cache on CPU1
[    0.080198] arm_arch_timer: WARNING: Invalid trigger for IRQ1, assuming level low
[    0.080200] arm_arch_timer: WARNING: Please fix your firmware
[    0.080206] arm_arch_timer: WARNING: Invalid trigger for IRQ2, assuming level low
[    0.080208] arm_arch_timer: WARNING: Please fix your firmware
[    0.080218] CPU1: Booted secondary processor [410fd034]
[    0.112234] Detected VIPT I-cache on CPU2
[    0.112261] arm_arch_timer: WARNING: Invalid trigger for IRQ1, assuming level low
[    0.112263] arm_arch_timer: WARNING: Please fix your firmware
[    0.112268] arm_arch_timer: WARNING: Invalid trigger for IRQ2, assuming level low
[    0.112270] arm_arch_timer: WARNING: Please fix your firmware
[    0.112279] CPU2: Booted secondary processor [410fd034]
[    0.144325] Detected VIPT I-cache on CPU3
[    0.144352] arm_arch_timer: WARNING: Invalid trigger for IRQ1, assuming level low
[    0.144354] arm_arch_timer: WARNING: Please fix your firmware
[    0.144358] arm_arch_timer: WARNING: Invalid trigger for IRQ2, assuming level low
[    0.144360] arm_arch_timer: WARNING: Please fix your firmware
[    0.144369] CPU3: Booted secondary processor [410fd034]
[    0.144437] smp: Brought up 1 node, 4 CPUs
[    0.144935] SMP: Total of 4 processors activated.
[    0.144965] CPU features: detected feature: 32-bit EL0 Support
[    0.145041] CPU: All CPU(s) started at EL2
[    0.145084] alternatives: patching kernel code
[    0.146078] devtmpfs: initialized
[    0.152034] DMI not present or invalid.
[    0.152357] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.152417] futex hash table entries: 1024 (order: 5, 131072 bytes)
[    0.153256] pinctrl core: initialized pinctrl subsystem
[    0.155078] NET: Registered protocol family 16
[    0.180398] cpuidle: using governor menu
[    0.181271] vdso: 2 pages (1 code @ ffff0000088f7000, 1 data @ ffff000008dc5000)
[    0.181328] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.182539] DMA: preallocated 256 KiB pool for atomic allocations
[    0.183046] Serial: AMBA PL011 UART driver
[    0.217241] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    0.218481] ACPI: Interpreter disabled.
[    0.219567] vgaarb: loaded
[    0.219937] SCSI subsystem initialized
[    0.220594] usbcore: registered new interface driver usbfs
[    0.220695] usbcore: registered new interface driver hub
[    0.220823] usbcore: registered new device driver usb
[    0.221437] pps_core: LinuxPPS API ver. 1 registered
[    0.221467] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.221535] PTP clock support registered
[    0.221764] dmi: Firmware registration failed.
[    0.222009] Advanced Linux Sound Architecture Driver Initialized.
[    0.223377] clocksource: Switched to clocksource arch_sys_counter
[    0.223575] VFS: Disk quotas dquot_6.6.0
[    0.223659] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.223977] pnp: PnP ACPI: disabled
[    0.233713] NET: Registered protocol family 2
[    0.234435] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[    0.234601] TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
[    0.234867] TCP: Hash tables configured (established 8192 bind 8192)
[    0.235052] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.235118] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.235337] NET: Registered protocol family 1
[    0.236017] RPC: Registered named UNIX socket transport module.
[    0.236047] RPC: Registered udp transport module.
[    0.236072] RPC: Registered tcp transport module.
[    0.236097] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.237356] kvm [1]: 8-bit VMID
[    0.237383] kvm [1]: IDMAP page: 8d8000
[    0.237408] kvm [1]: HYP VA range: 800000000000:ffffffffffff
[    0.238363] kvm [1]: Hyp mode initialized successfully
[    0.238413] kvm [1]: Invalid trigger for IRQ4, assuming level low
[    0.238455] kvm [1]: virtual timer IRQ4
[    0.240265] audit: initializing netlink subsys (disabled)
[    0.240419] audit: type=2000 audit(0.235:1): initialized
[    0.240884] workingset: timestamp_bits=46 max_order=18 bucket_order=0
[    0.254104] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.255158] NFS: Registering the id_resolver key type
[    0.255224] Key type id_resolver registered
[    0.255250] Key type id_legacy registered
[    0.255284] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.255570] 9p: Installing v9fs 9p2000 file system support
[    0.258907] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247)
[    0.258957] io scheduler noop registered
[    0.259300] io scheduler cfq registered (default)
[    0.274984] xenfs: not registering filesystem on non-xen platform
[    0.282150] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.284613] console [ttyS0] disabled
[    0.284769] 3f215040.serial: ttyS0 at MMIO 0x0 (irq = 61, base_baud = 31224999) is a 16550
[    1.133165] console [ttyS0] enabled
[    1.138195] SuperH (H)SCI(F) driver initialized
[    1.143417] msm_serial: driver initialized
[    1.148357] cacheinfo: Unable to detect cache hierarchy for CPU 0
[    1.162381] loop: module loaded
[    1.166975] hisi_sas: driver version v1.6
[    1.175268] libphy: Fixed MDIO Bus: probed
[    1.180610] tun: Universal TUN/TAP device driver, 1.6
[    1.185774] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    1.193842] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[    1.199809] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    1.205966] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
[    1.213070] igb: Copyright (c) 2007-2014 Intel Corporation.
[    1.218865] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.4.0-k
[    1.226860] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    1.233001] sky2: driver version 1.30
[    1.237646] VFIO - User Level meta-driver version: 0.3
[    1.245111] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.251778] ehci-pci: EHCI PCI platform driver
[    1.256424] ehci-platform: EHCI generic platform driver
[    1.261939] ehci-exynos: EHCI EXYNOS driver
[    1.266372] ehci-msm: Qualcomm On-Chip EHCI Host Controller
[    1.272209] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.278539] ohci-pci: OHCI PCI platform driver
[    1.283179] ohci-platform: OHCI generic platform driver
[    1.288671] ohci-exynos: OHCI EXYNOS driver
[    1.293724] usbcore: registered new interface driver usb-storage
[    1.301603] mousedev: PS/2 mouse device common for all mice
[    1.309231] i2c /dev entries driver
[    1.316613] bcm2835-wdt 3f100000.watchdog: Broadcom BCM2835 watchdog timer
[    1.324703] sdhci: Secure Digital Host Controller Interface driver
[    1.331017] sdhci: Copyright(c) Pierre Ossman
[    1.335983] Synopsys Designware Multimedia Card Interface Driver
[    1.343142] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.395407] mmc0: SDHCI controller on 3f300000.sdhci [3f300000.sdhci] using PIO
[    1.407332] ledtrig-cpu: registered to indicate activity on CPUs
[    1.415117] usbcore: registered new interface driver usbhid
[    1.421991] usbhid: USB HID core driver
[    1.428538] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
[    1.436268] NET: Registered protocol family 17
[    1.440935] 9pnet: Installing 9P2000 support
[    1.445379] Key type dns_resolver registered
[    1.450920] registered taskstats version 1
[    1.458971] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 72, base_baud = 0) is a PL011 rev2
[    4.700990] console [ttyAMA0] enabled
[    4.718338] raspberrypi-firmware soc:firmware: Attached to firmware from 2017-03-02 15:32
[    4.752120] 3f980000.usb supply vusb_d not found, using dummy regulator
[    4.778759] 3f980000.usb supply vusb_a not found, using dummy regulator
[    4.855887] dwc2 3f980000.usb: DWC OTG Controller
[    4.874781] dwc2 3f980000.usb: new USB bus registered, assigned bus number 1
[    4.903082] dwc2 3f980000.usb: irq 41, io mem 0x00000000
[    4.925228] hub 1-0:1.0: USB hub found
[    4.940287] hub 1-0:1.0: 1 port detected
[    4.956698] hctosys: unable to open rtc device (rtc0)
[    4.977145] ALSA device list:
[    4.989034]   No soundcards found.
[    5.023382] random: fast init done
[    5.043524] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    5.076028] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    5.107081] devtmpfs: mounted
[    5.120098] Freeing unused kernel memory: 1024K
[    5.351442] usb 1-1: new high-speed USB device number 2 using dwc2
[    5.408029] EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered
[    5.588311] hub 1-1:1.0: USB hub found
[    5.603442] hub 1-1:1.0: 5 ports detected
Welcome to Buildroot
buildroot login: [    5.907403] usb 1-1.1: new high-speed USB device number 3 using dwc2
[    6.917298] random: crng init done

Le boot est à présent terminé et login a affiché son prompt de connexion. Néanmoins le contrôleur USB s’initialise plus lentement et un message vient “recouvrir” le prompt. J’appuie alors sur la touche Entrée.

Welcome to Buildroot
buildroot login: root
Password: root

Le mot de passe de root (root) est codé en dur dans la configuration de Buildroot. Vous pouvez le modifier lors de l’étape make menuconfig dans le menu System configuration.

# uname -a
Linux buildroot 4.10.1 #1 SMP PREEMPT Fri Mar 10 20:28:37 CET 2017 aarch64 GNU/Linux

Nous avons donc bien confirmation de la réussite de notre installation d’un noyau standard 4.10.1. Comment vérifier que notre système fonctionne bien en mode 64 bits ? Simplement en regardant la taille d’un pointeur. Pour cela je prends le petit programme C suivant :

sizeof.c:
#include <stdio.h>

int main(void)
{
        fprintf(stdout, "sizeof(int) = %lu\n", sizeof(int));
        fprintf(stdout, "sizeof(long) = %lu\n", sizeof(long));
        fprintf(stdout, "sizeof(void*) = %lu\n", sizeof(void *));
        return 0;
}

Je l’ai écrit sur mon PC, dans le répertoire Vanilla-Pi-3 et je le compile en utilisant la toolchain Arm64 que Buildroot a produit au début de sa compilation :

[Vanilla-Pi-3]$ ./buildroot-2017.02/output/host/usr/bin/aarch64-linux-gcc sizeof.c -o sizeof

Je copie le fichier sizeof sur la carte micro-SD du Raspberry Pi préalablement arrêté :

[Vanilla-Pi-3]$ sudo cp sizeof /media/$USER/root/root/
[Vanilla-Pi-3]$ umount /media/$USER/*

Après reboot du Raspberry Pi 3, exécutons le script :

Welcome to Buildroot
buildroot login: root
Password: root
# ls
sizeof
# ./sizeof 
sizeof(int) = 4
sizeof(long) = 8
sizeof(void*) = 8
# 

La taille d’un pointeur est bien de 8 octets, 64 bits. Ceci permet en théorie d’adresser 264 octets, soient 16 Eio de mémoire. En pratique les processeurs 64 bits actuels ne dépassent pas 48 bits d’adresse utilisables, soient 256 Tio (ce qui est déjà gigantesque). Du moins pour l’architecture x86, je ne sais pas ce qu’il en est pour le system-on-chip du Raspberry Pi 3. Quoiqu’il en soit, ce dernier ne possède que 1 Gio de RAM non extensible ce qui limite l’intérêt de ce type d’adressage…

L’exécution du programme ci-dessus donne exactement le même résultat que sur un PC x86 64 bits. En revanche sur un Raspberry Pi 3 avec une distribution Raspbian standard (donc 32 bits), on obtient :

pi@raspberrypi:~$ ./sizeof
sizeof(int) = 4
sizeof(long) = 4
sizeof(void*) = 4

Conclusion

Nous l’avons déjà dit, l’intérêt de cette opération est assez limité en ce qui concerne le passage au mode 64 bits. Le fait de pouvoir démarrer sur un noyau standard est plus intéressant. Enfin la mise en place de U-boot nous ouvre des possibilités en ce qui concerne les tout premiers scripts de démarrage, je reviendrai sur ce sujet ultérieurement.

Pour accélérer la compilation de Buildroot, je n’ai incorporé aucun packages supplémentaire par rapport au Busybox minimal ; naturellement vous pouvez ajouter toutes les applications qui vous semblent bonnes en éditant le contenu du menu Target Packages lors du make menuconfig.

Si vous trouvez ce qui cloche dans ma configuration et qui empêche d’utiliser la console graphique du Raspberry Pi 3, j’en serai ravi. Il faut savoir que sur les autres modèles 1 ou 2, on peut démarrer un système complet (y compris l’environnement graphique Pixel) sur un noyau Linux standard.

Système multiroom avec Volumio.

Cet article est un tutoriel qui montre comment installer et configurer une installation multiroom audio à base de Raspberry Pi couplé avec des cartes Hifiberry et du logiciel Volumio. L’ensemble est pilotable depuis tout navigateur installé sur n’importe quel matériel.

Une présentation de Volumio.

Volumio est un système (pas seulement une application) qui permet de jouer de la musique un peu partout avec une bonne qualité sonore.

Quelques fonctionnalités du logiciel :

  • il est libre et open-source,
  • Il tourne sur des petits systèmes tels que : Raspberry PI, UDOO, Cubox-i, Odroid mais aussi sur PC.
  • Il sait lire les formats suivants : FLAC, Alac, Aac, Vorbis, Mp3, DSD,
  • Il sait lire sur les serveurs DLNA, les partages Samba (windows), il est compatible Airplay (Apple),
  • Il sait écouter les webradios (radios diffusées sur internet),
  • Il assure les fonctionnalités dites de multiroom. On va pouvoir par exemple écouter une musique différente dans différentes pièces ou la même musique en synchronisé dans plusieurs pièces,
  • Il ne nécessite pas de tirer des câbles audio. Le réseau filaire ethernet ou wifi suffisent,
  • il se pilote avec un navigateur depuis tout types d’ordinateurs (PC sous linux ou windows, Mac, Androïd, IOS, etc.),
  • il peut créer son propre réseau wifi (hotspot),
  • il propose un plugin Spotify,
  • il peut devenir un réveil avec ses fonctions d’alarme,
  • des applications Android et IOS sont disponibles pour le piloter,
  • il gère en interne ses mises à jour
  • etc.
Architecture

Petit schéma pour comprendre l’architecture. Les systèmes volumio sont représentés à mi-hauteur, à gauche la version ampli, à droite la version DAC. Source : volumio.org

Deux versions de montages seront présentées ici :

  • la version amp+ qui avec un amplificateur peut se brancher sur des enceintes.
  • la version DAC qui se branchera sur une entrée de type RCA (sur une chaîne hifi par exemple)

Le Raspberry pi

Le Raspberry Pi est un formidable ordinateur, apparu en 2012. Il est souple, ouvert, petit et surtout peu coûteux (40€). Des tonnes de cartes additionnelles compatibles et des milliers de projets destinés à cette plateforme ont vu le jour.

Raspberry Pi 3. Source kubii.fr

Quelques défauts :

  • Il souffre d’une sortie audio médiocre.
  • Il n’a pas de bouton marche-arrêt.
  • Il n’a pas d’horloge intégrée.

Pour notre multiroom nous allons doter notre Raspberry Pi d’une sortie audio de bonne qualité.

Plusieurs choix sont possibles :

  • Une carte avec une sortie RCA qui pourra se raccorder à une chaîne hifi par exemple.
    Hifiberry DAC+ 30 €

    DAC+

    Source Hifiberry

  • Une carte avec sortie numérique S/PDIF (non testée)
  • Une carte contient un amplificateur sur laquelle on pourra raccorder deux enceintes hifi.

    AMP+

    Source : Hifiberry

  • Une variante avec amplificateur à tubes (non testée et très chère).
    Ampli à tube

    Source Hifiberry

    Ces cartes se posent par dessus le raspberry pi, ce sont les broches du GPIO qui connectent la carte avec l’ordinateur.

    Les matériels nécessaires

    Version DAC

    Pour la version DAC qui se branche sur une chaîne hifi :

    • 1 Raspberry Pi 2 ou Pi 3
    • une carte Hifiberry Dac +
    • une alimentation pour le Raspberry Pi
    • une SD Card 8 Go ou plus
    • un boîtier pouvant accueillir le Raspberry Pi et la carte DAC.
    • un cordon RCA

      RCA

      Connectique RCA. Source commentcamarche.com

    • une chaîne hifi ou un appareil disposant d’une entrée RCA

Version Amplificateur

  • 1 Raspberry Pi 2 ou Pi 3
  • une carte Hifiberry AMP+ avec une alimentation qui alimentera le Raspberry Pi et l’amplificateur.

    Alimentation

    Alimentation. Source Hifiberry

  • une SD Card 8 Go ou plus avec un adaptateur
  • un boîtier pouvant accueillir le Raspberry Pi et la carte Amp+
  • Deux enceintes
  • du câble pour haut-parleur

Commentaires sur les matériels

Il faudra pour la configuration d’un PC de préférence sous Linux. Ce PC doit être équipé d’un lecteur de carte SD. Si ce n’est pas le cas vous pouvez acheter ceci pour ~6€ :

Lecteur carte sd

Lecteur carte sd. Source : kubii.fr

Avec ce lecteur qui se branche sur un port USB on pourra lire et écrire les cartes SD.

Il est inutile de prendre une carte pré-gravée avec une distribution car nous devrons la re-graver.

Il faudra aussi disposer d’un câble Ethernet même si vous souhaitez utiliser que le wifi au final, le câble Ethernet sera nécessaire pour la configuration initiale.

On note aussi qu’aucun clavier, ni souris, ni écran ne sont requis pour le Raspberry Pi.

Bon on y va ?

Installation et configuration.

Assemblage du matériel.

Assez enfantin, on fixe la carte additionnelle sur le Raspberry Pi. On pose les entretoises (éléments dans les coins des cartes qui les relient entre-elles)

Entretoises

Entretoises pour fixer les cartes entre elles.

Les entretoises sont livrées avec les cartes.

On pose le tout dans le boîtier.

Préparation de la carte SD

Récupération de l’image Volumio

On récupère une image Volumio ici : https://volumio.org/get-started/

L’image obtenue est compressée donc on la décompresse avec le programme de gestion des archives. Quand on « double-clique » sur l’archive zip çà lance le gestionnaire d’archives. Dans ce programme on demande d’extraire le fichier contenu. C’est un fichier dont l’extension est img.

L’image du genre : volumio-2.030-2016-11-20-x86.img sera gravée sur la carte SD.

Gravure de la carte sd.

On place la carte SD dans son lecteur et le lecteur sur le port USB du PC. Dès l’insertion on doit voir le montage de la carte se faire et cela se voit dans le gestionnaire de fichier.

Il faut à ce stade identifier le lecteur vu du système.

Pour cela le logiciel « disques » sous Mint va nous aider.

Application Disques

Disques sous Linux Mint

Dans l’exemple ci-dessus on voit le lecteur monté en sdd.

On ouvre un terminal. On se place dans le répertoire qui contient l’image Volumio.

sudo dd bs=4M if=mon image volumio.img of=/dev/sdx

Cette commande va copier notre image sur la carte.

On remplace « mon image volumio.img » par le nom de l’image qu’on a téléchargé puis extrait.

On remplace sdx par le disque de montage de la carte. Dans mon exemple ce la donnera :

sudo dd bs=4M if=volumio-2.030-2016-11-20-x86.img of=/dev/sdd

Attention une erreur de destination du genre : j’écris sda au lieu de sdd écrasera tout le disque sda !!! A vous d’éviter de vous tirer une balle dans le pied.

Quand on est bien sur, on inspire un grand coup, on lance et on laisse l’exécution se faire. (tsin tsin tsin – musique hitchcokienne)

Quand c’est fait on démonte proprement le lecteur dans le gestionnaire de fichier.

On installe la carte SD dans le Raspberry Pi éteint au préalable !

On effectue les branchements hifi  : RCA ou haut-parleurs.

On branche le connecteur Ethernet (même si la cible finale de fonctionnement sera le wifi).

Le câble Ethernet va relier le Raspberry Pi avec votre réseau. Vous pouvez vous brancher sur une prise disponible de votre box.

Nota important pour l’alimentation de l’ampli AMP+. Je recommande de brancher le câble secteur (entre l’alimentation et la prise secteur) en dernier car sinon la connexion côté amplificateur provoque des étincelles  certes très jolies mais susceptibles de faire des dégâts sur les cartes. C’est vous qui voyez…

Enfin au dernier branchement de l’alimentation le Raspberry Pi démarre dans une ambiance tendue mais pleine d’espoirs musicaux. (tada!)

Et pendant ce temps Volumio démarre…

Le premier démarrage de Volumio est long, voire très long. Plusieurs minutes. Ça tombe bien pendant ce temps nous avons des choses à faire sur le PC.

Préparation depuis une station linux

Sur la station Linux (pas le Raspberry Pi) on installe le logiciel nmap qui permet entre autres de scanner son réseau local.

Sur les distributions de la famille Ubuntu le logiciel se trouve dans la logithèque.

Logithèque Mint

La logithèque sous Linux-Mint.

Ce logiciel s’utilise dans un terminal. Nous l’utiliserons pour découvrir l’adresse IP de notre Raspberry Pi.

Nota : Pour les malins qui pensent plus rapide de se connecter directement sur le Raspberry Pi et modifier les fichiers de configuration réseau : laissez-tomber ! Cela ne fonctionne pas ! Je le sais car j’ai perdu plusieurs soirées avec ça !

Dans quel réseau suis-je ?

Dans un terminal on va déterminer dans un premier temps la plage d’adresse de notre réseau local avec la commande ifconfig

thierry@ioannina-mint ~ $ ifconfig
enp4s0    Link encap:Ethernet  HWaddr f4:6d:04:4f:07:67  
          inet adr:192.168.0.9  Bcast:192.168.0.255  Masque:255.255.255.0
          adr inet6: fe80::c87b:9b52:57f8:88f0/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:1273021 erreurs:0 :0 overruns:0 frame:0
          TX packets:534723 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          Octets reçus:1630221999 (1.6 GB) Octets transmis:62082400 (62.0 MB)

Les informations qui nous intéressent sont : inet adr:192.168.0.9 et Masque:255.255.255.0

La première donne l’adresse IP de mon poste et la seconde comment les adresses peuvent varier dans le réseau local.

255.255.255.0 dit que seul le dernier bloc d’adresse peut changer.

192.168.0.9 dit que mon adresse commence par 192.168.0

Donc mon réseau local va de l’adresse 192.168.0.0 à 192.168.0.255 et comme les adressses .0 et .255 sont réservées mon réseau local va effectivement de 192.168.0.1 à 192.168.0.254.

Vous serez très probablement dans le même cas ou éventuellement des adresses en 192.168.1.x

Ou est mon Volumio  ?

Nous allons déterminer l’adresse IP de notre raspberry et pour cela nous allons faire de la haute voltige dans notre terminal.

Prêts les aviateurs ?

On passe la commande qui suit en remplaçant le x par ce que vous avez trouvé à l’étape précédente :

sudo nmap -sP -PT -PI -T 3 192.168.x.*

donc pour moi c’est :

sudo nmap -sP -PT -PI -T 3 192.168.0.*

Dans la réponse obtenue vous aurez les machines et appareils connectés au réseau local.

Chaque bloc correspond à une machine (un interface réseau pour être précis).

Nmap scan report for 192.168.0.240
Host is up (0.00032s latency).
MAC Address: B8:27:EB:4C:D9:D8 (Raspberry Pi Foundation)
Nmap scan report for 192.168.0.241
Host is up (0.047s latency).
MAC Address: B8:27:EB:A5:97:F9 (Raspberry Pi Foundation)

Dans l’extrait ci-dessus on voit deux Raspberry Pi, un en 192.168.0.240 et l’autre en 192.168.0.241

Notez l’adresse de votre Raspberry Pi.

Ouvrez votre navigateur favori (Firefox) dans la zone d’adresse du site inscrivez l’adresse trouvée.

Si tout s’est bien passé vous devriez avoir une page ressemblant à ceci :

Page d'accueil Volumio

Page d’accueil Volumio

Là vous pouvez être très satisfait de vous. Il ne reste plus que la configuration de Volumio à faire !

Normalement il devrait être tard dans la nuit quand vous serez arrivé là. Je préconise donc d’aller dormir en attendant la publication du second épisode où l’on ouïra la musique jaillir de nos petits mais efficaces engins.

Configuration de Volumio

Description de la page d’accueil de Volumio

Page d'accueil Volumio

Page d’accueil Volumio

De haut en bas et de gauche à droite nous avons :

  1. Le lien qui pointe vers l page d’accueil (Volumio)
  2. Les boutons de pilotage audio (morceau précédent, lecture/pause, morceau suivant)
  3. Le bouton pour aller vers les différents réglages (la route dentée)
  4. Le module de suivi du morceau en cours (ici on a écouté 2:30 sur les 4:19 totaux)
  5. Le module de présentation du morceau : titre de l’album, titre du morceau, artiste, pochette de l’album.
  6. Module de contrôle du volume
  7. La zone d’affichage des Volumio présents sur le réseau (ici c’est deux)
  8. Le lien « Parcourir » qui permet de naviguer dans l’ensemble de la musique disponible
  9. Le lien « Jouer » c’est pour jouer (étonnant non ?)
  10. Le lien « Queue » qui permet de gérer la file en cours des morceaux.

Les paramètres vite !

Ok ok on y va.

Menu de paramétrage

Menu de paramétrage

Menu apparence

Pour commencer on va faire parler français notre système.

Page Apparence

Page Apparence

Je vous laisse choisir la langue et le thème graphique qui vont iront bien…

Menu Système

Ensuite nous allons dans « Système »

Page Système

Page Système

Ici nous allons donner un nom à notre système. Chaque système Volumio doit avoir son nom qui sera unique sur le réseau.

Nota : je recommande l’option : « Son de Démarrage » qui donne un son au démarrage du système c’est assez pratique pour savoir si le son fonctionne et que le Raspberry Pi démarre.

Ensuite on clique sur « Vérifier les mises à jour ». Si nécessaire on installe la mise à jour.

Pour la prise en compte de ces premières opérations nous allons re-démarrer le système.

Ecran de sortie

Should i stay or should i go ?

Je vous laisse deviner sur quel bouton on clique.

Nota : les redémarrages sont toujours longs, soyez patients avant de passer vos nerfs sur ce qui vous tombe sous la main.

Les réglages audio, menu lecture.

Pour la version AMP+ c’est assez simple. Voici mes réglages

Options de lecture

Options de lecture

Pour la version DAC+ c’est plus fourni :

Options de lecture pour DAC

Options de lecture pour DAC

Options de lecture DAC suite

Options de lecture DAC suite

Nota : après toute modification n’oubliez pas le bouton « Sauver » associé au groupe de paramètres.

Les réglages du réseau

Vous êtes toujours là ? Maintenant on arrive dans une partie plus délicate : les paramètres réseau.

Réglages réseau

Réglages réseau

En premier lieu choisissez le mode de connexion que vous voulez : câblé (filaire) ou wifi.

Si vous voulez utiliser le mode câblé : il faudra désactiver le wifi et renseigner la partie « réseau câblé ».

Réseau partie sans fil

Réseau partie sans fil

Vous positionnez « Réseau Sans Fil (Wifi) sur OFF. Vous effacez les saisies dans les 3 champs qui suivent et vous cliquez sur « Sauver »

Pour rappel : dès qu’on modifie cette partie après sauvegarde vous pouvez perdre la visibilité sur votre Volumio. En effet si vous connecté sur l’adresse 192.168.0.10 et vous demandez qu’il passe en 192.168.0.20 il faut dans votre navigateur passer sur la nouvelle adresse. Enfin chaque modification nécessite un redémarrage. Il faudra être patient.

Les débutants en réseau choisiront l’Allocation dynamique (DHCP). Les autres feront comme bon leur semblera.

En allocation dynamique. Vous sélectionnez IP automatique sur ON. C’est le mode le plus facile.

Pour simplifier vos changements d’adresses vous pouvez accéder à Volumio avec son nom (le nom qu’on a renseigné sur la page système) au lieu de son adresse IP.

exemple : http://volumio1.local

Facile non ? Je laisse les barbus faire mieux et plus compliqué.

Les réglages des partages

Le Raspberry Pi est un ordinateur formidable mais il ne dispose pas de beaucoup de place de stockage.

Pour ceux qui veulent faire simple il faudra déposer sa musique dans une clé USB et brancher cette dernière sur le Raspberry Pi.

Pour ceux qui disposent d’un serveur Samba, Volumio sait y accéder.

Pour cela on va dans le menu « Ma Musique« .

Page "Ma Musique"

Page « Ma Musique »

On peut ajouter un disque en cliquant sur « Ajouter un nouveau disque »

Ajout de disques réseau

Ajout de disques réseau

Les disques qu’on peut ajouter sont des partages Samba (CIFS) ou NFS, Volumio les cherche sur votre réseau.

Ensuite on sauve tout çà.

Au passage on peut noter que la sécurité n’est pas le point fort de Volumio car quiconque accède à Volumio pourra voir le compte et son mot de passe !

On demandera ensuite à Volumio de faire un « scan ».

Cette opération est longue particulièrement si vous avez beaucoup de musique, soyez patient et vos morceaux finiront par apparaître.

Nota : quand vous avez fini la configuration, n’importe quel outil disposant d’un navigateur pourra piloter vos appareils Volumio : un pc, une tablette, un smartphone.

Longues heures de bonnes écoutes à vous !

Petit bilan de notre système multiroom.

En résumé les points forts et points faibles de Volumio.

Avantages

  • Mise en œuvre économique
  • Souplesse de fonctionnement car il est multi-plateforme,
  • Bonne ergonomie du logiciel, des pages avec l’essentiel,
  • Esthétique agréable et claire,
  • Francisation complète,
  • Bonne qualité sonore.

Inconvénients

  • La sécurité est quasi absente,
  • Le plus grave pour moi : avec plusieurs appareils le système ne sait pas synchroniser différents systèmes sur la même musique.

Liens utiles

Hifiberry : https://www.hifiberry.com

Volumio : https://volumio.org

Kubii : https://www.kubii.fr

Un excellent tutoriel sur le même sujet avec un autre logiciel : http://www.maison-et-domotique.com/56929-realisation-de-multiroom-audio-a-base-de-raspberry-pi-hifiberry/

Cet article Système multiroom avec Volumio. a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

PiCano un boîtier VESA pour votre Raspberry Pi

J’avais déjà eu l’occasion de vous présenter PiCano, un boîtier VESA pour le Raspberry Pi. Très résistant, il permet de monter votre Raspberry Pi à l’arrière d’un moniteur/TV en utilisant les trous de montage standardisés présents à l’arrière. Steve a souhaité apporter un « petit » changement dans la conception… Pas si simple, en fait !

PiCano un boîtier VESA pour le Raspberry Pi

Un boîtier à la norme VESA

Et si la fixation VESA est déjà utilisée ? Pas de souci. Dans ce cas le boîtier PiCano viendra simplement s’intercaler entre le support VESA et l’écran.

La construction métallique et la quincaillerie livrée permettent une fixation solide même dans cette configuration.

Sur l’image de gauche, vous voyez un écran iiyama. Entre la plaque de fixation sur le pied et l’écran, le PiCano a été intercalé. Ceci ne remet pas en cause la solidité du montage.

Un petit changement dans la conception

Pour info, l’original de cet article, les images et les graphiques ont été préparés sur un Raspberry Pi par le créateur de PiCano : Steve Royd Marker – Tous droits réservés
Je lui laisse la parole pour la suite de cette page.

PiCano est un boîtier VESA pour le Raspberry Pi. Il est en vente depuis un certain temps maintenant. Et comme pour tous les produits mis sur le marché, un des paris c’est de savoir combien de temps les ventes dureront. Par conséquent, vous commencez aussi simplement que possible et lorsque vous voyez les ventes se développer, vous améliorez les méthodes de production, d’emballage, et vous essayez également de réduire les stocks.

Le diable se cache dans les détails

Développer un nouveau produit est quelque chose de très amusant. Fignoler les derniers détails du projet, demande souvent beaucoup plus d’efforts. C’est toujours à la fin, que les problèmes les plus difficiles restent. Une fois que le produit est en production, un amusement différents apparaît : Améliorer les méthodes de production (l’efficacité). Il peut s’agir de la de la production, de la façon dont vous emballez le produit ou même d’une refonte du produit lui-même afin de contourner certains problèmes de production rencontrés… Ou, dans le cas présent, des méthodes de production qui prennent trop de temps .

Dans cet article, je vais vous présenter l’un des problèmes présent sur PiCano à l’origine. Il concerne le perçage des trous dans la tôle d’aluminium pour les vis M3 à tête fraisée. Le perçage et le fraisage sont un problème depuis le début. C’est un processus lent et difficile.
Pourquoi ?

Trop de temps passé

Il y a plusieurs raisons pour lesquelles le fraisage a dû être modifié. L’une d’elles est le temps important passé à fraiser les trous dans la plaque d’aluminium, pour loger la tête de la vis. La tête de la vis ne doit pas dépasser au-dessus de la tôle d’aluminium. Cela pourrait endommager l’arrière du moniteur lorsque PiCano est utilisé comme «support VESA» (entre le moniteur et un support mural, par exemple). Les trous des vis doivent donc être fraisés. On pourrait penser que cela demande simplement l’utilisation d’une perceuse, suivie du fraisage de chaque trou à une profondeur prédéfinie…
Mais ce n’est pas si simple…

Pour commencer, l’aluminium anodisé semble toujours être de qualité douce. Ce type d’aluminium a tendance à coller aux bords de coupe du foret à fraiser (ci-dessous).

Par conséquent, je devais arrêter le foret au moins tous les 3 trous et enlever les copeaux d’aluminium, qui encombrent le foret. Celui-ci ayant 3 tranchants, j’ai donc besoin de le faire trois fois tous les trois trous. Pour empêcher l’aluminium de coller trop fort sur le foret j’utilise une huile légère. Mais cela signifie que je dois nettoyer après. Oui … le processus de fabrication commence à sembler plus long, n’est-ce pas?

La déformation de la plaque

L’aspect suivant à considérer est la flexion de l’aluminium autour du trou, due à la pression du foret à fraiser. Lorsque le foret commence à coincer, il faut appliquer plus de force vers le bas pour continuer à couper, ce qui entraîne une déformation vers le bas autour du trou

Pour compenser cela, j’ai un deuxième foret à fraiser monté sur le tour, à côté de ma perceuse à colonne. Je peux donc fraiser l’arrière du trou pour enlever la matière déformée par le fraisage. En même temps, je dois être très prudent, parce que quand je fraise sur la perceuse à colonne, je peux définir une profondeur maximale. Mais quand je retire la matière déformée sur le tour, je peux dépasser la profondeur parce que je ne peux pas mettre de butée. Par conséquent je peux agrandir le trou et la vis passera à travers. Cela veut dire qu’il faut jeter une pièce par ailleurs parfaitement correcte. (Ce qui donne généralement lieu à l’émission d’une quantité considérable de jurons… Vous voyez ce que je veux dire…?)

Le dernier plaisir, c’est de retirer l’huile avec un chiffon. Le tissu accroche aux bords rugueux du trou, laissant des peluches que je dois enlever manuellement en les récupérant avec mes ongles. C’est un bon test pour ma patience. (…?) Le temps c’est de l’argent, et tous ces détails stupides prennent une énorme quantité de temps pour faire un simple trou avec une bosse dessous. Une chose que le client final ne s’attend normalement pas à trouver, et qu’il n’appréciera pas particulièrement.

La vis à tête fraisée

Ensuite, il y a le problème que la vis à tête fraisée M3, a une tête conique d’au moins 2mm de hauteur. Mais la tôle d’aluminium fait seulement 1mm d’épaisseur, donc ça dépasse 🙁

Pour résoudre ce problème, on peut utiliser une rondelle pour vis M4 de 0,85 mm d’épaisseur. De cette façon, la rondelle remplit l’espace et la vis peut serrer la tôle d’aluminium entre sa tête, la rondelle et l’entretoise de carte. Ça résout également un autre problème. Les entretoises qui supportent la carte Raspberry Pi font 8mm de haut et devraient mesurer 9 ou 9,5mm.Bien sûr on peut trouver des entretoises de 9 mm de haut, mais elles ont tendance à être très coûteuses car c’est une taille non standard. Donc ajouter la rondelle M4 résout ce problème particulier aussi.

Dans le dernier modèle de boîtier PiCano (pour Raspberry Pi B+, 2 et 3) il y a 12 de ces assemblages :  4 dans la plaque supérieure et 8 dans la plaque inférieure. Le Raspberry Pi a 4 trous de fixation et il ne peut plus être fixé sur la plaque en acrylique d’où ces 4 trous supplémentaires.

Cela signifie donc d’avoir au total 12 fois la «joie» de fraiser les trous et 12 rondelles M4 supplémentaires pour résoudre les deux problèmes. (Déborder des trous de fixation du Raspberry Pi sur le dessus de la carte empêche dans certains cas d’utiliser un connecteur de câble en nappe sur le GPIO).

Gérer le stock

Pour obtenir un prix intéressant sur les rondelles M4, je dois en commander une quantité énorme. Si la disposition des trous de fixation du Raspberry Pi change encore, je pourrais me retrouver avec une petite montagne de rondelles en stock. Donc, moins j’ai d’articles en stock, moins j’ai de risque.

Pour compéter le tableau, il y a aussi le fait de devoir compter les petites pièces. J’ai trouvé qu’il n’y a qu’une seule bonne façon de faire, qui donne une certitude sur les chiffres. Il s’agit de les mettre sur une « table de comptage » … pièce par pièce. Toute cette installation et le comptage prennent du temps, donc moins j’ai de pièces et moins je perds de temps. Peser le sac de pièces comme vérification finale n’est pas une option acceptable. J’ai constaté très vite que la tolérance de poids sur les pièces les plus grandes dépasse parfois la masse totale d’une des pièces les plus petites. Donc, le poids total ne donne aucune garantie que le sac est rempli correctement.

Comment faire ?

Pour résoudre tout ce qui précède, j’ai imaginé de construire un outil de découpe-poinçonnage de plaque, pour pousser vers le bas de la zone autour des trous de vis.

De cette manière, le trou devient suffisamment conique pour recevoir la tête de la vis à tête fraisée M3 et la déformation du matériau est suffisamment profonde pour que la hauteur de la rondelle M4 soit complètement compensée par la déformation sous la tôle d’aluminium.

Cela résout également le problème de la hauteur insuffisante des entretoises support de la carte Raspberry Pi puisque la hauteur totale est bien de 9mm.

Voici le résultat obtenu :

A gauche le trou est obtenu par fraisage, à droite par frappe et contre-poinçonnage.

Le premier test.

Pour avoir une idée de la pression nécessaire pour créer un trou dans la plaque d’aluminium, j’ai mis en place un test simple. Dans les mors du tour, j’ai placé un morceau de laiton dans lequel j’avais foré un trou de la taille voulue, et j’ai remplacé le porte foret, par une pointe.

Avec cette configuration je pouvais essayer de pousser un cône dans la plaque d’aluminium et « avoir une idée » de la pression nécessaire. Il était clair que la force manuelle n’était pas suffisante, et j’ai dû utiliser la broche de contre-pointe pour avoir assez de force.

Il me semblait évident que la broche fournirait une force suffisante en raison de l’effet de levier sur la poignée de commande. C’était exactement ce que j’espérais … YESSSSS!

Fabrication de l’outil de poinçonnage

La réalisation de l’outil n’était pas trop difficile. Après avoir fait les premiers tests, je savais ce que je voulais, et j’ai dessiné le projet à la main. Les trois pièces principales sont en laiton. Le laiton est facile à couper et ne s’oxyde pas. J’ai également eu une bonne expérience du fait qu’il ne laisse pas de marques sur l’aluminium anodisé comme le ferait l’acier. Le ressort en spirale était l’un de ceux que j’avais mis de côté pour de telles occasions, et je l’ai sélectionné au cours des tests. Le deuxième ressort n’est rien d’autre qu’un morceau de fil d’acier inoxydable, nécessaire pour faire remonter la bague coulissante de l’outil (qui reçoit l’aluminium poussé vers le bas), entre les actions de poinçonnage.

Un peu plié

Bien sûr, la réalisation du dessin n’a pas pris longtemps. Mais pour tester et construire l’outil, il a fallu presque une journée, sans compter quelques tests faits en amont. Même quand j’étais encore en train de réfléchir à la façon de faire l’outil, je savais que la feuille d’aluminium allait se tordre vers le haut et aurait besoin d’être maintenue par «quelque chose».

Le test fait sur mon tour a confirmé mes soupçons et même quand j’ai totalement empêché la tôle d’aluminium de se tordre vers le haut, les tensions internes déformaient encore la plaque, quand elle était libérée de l’outil.

J’ai constaté qu’elle se pliait vers le haut, avec un angle d’environ 5 degrés. J’ai donc décidé de réaliser l’anneau de serrage et l’enclume avec une pente de 5 degrés vers le bas, en espérant que pourrait résoudre le problème (en le contrant).

Dans l’image ci-dessus, vous voyez l’outil de perforation que j’ai utilisé pour faire la première série de tests. A la suite de ces essais j’étais certain que ça répondait au besoin, mais qu’il fallait encore l’améliorer. Pour commencer la planche de bois qui maintient l’enclume en place, a été une facilité pour tester rapidement le fonctionnement de l’outil. Elle doit être remplacé par un petit morceau d’acier. Celui-ci sera fixé à la table en utilisant des écrous encastrés, de sorte que l’enclume ne fasse plus qu’un avec la perceuse. Cela rendra l’outil plus précis, et nécessitera moins d’attention de la part de l’opérateur pour obtenir une empreinte parfaite.

Les pièces de l’outil


De haut en bas :

  1. Contre-poinçon.
  2. Ressort hélicoïdal de serrage et ressort de retenue mince.
  3. Bague de serrage
  4. Enclume et axe central.

A) En haut, c’est la pièce active, qui crée la déformation. Elle est montée dans un mandrin de perceuse normal, et son diamètre est de 13mm. À mi-chemin il a un rebord pour l’empêcher de glisser dans le mandrin et fournir un support pour le ressort spirale. Elle se termine par un cône de 90 degrés, avec un trou central pour recevoir la broche.

B) Le ressort en spirale ferme a été choisi selon un critère qui était sa force de rappel. Le ressort de retenue (le fil mince) n’est qu’un moyen de garder l’outil assemblé … (un élastique aurait aussi bien fait l’affaire).

C) Ensuite, il y a la « bague de serrage » qui glisse sur le poinçon, est poussée vers le bas par le ressort en spirale et retenue par le ressort fin.

D) L’enclume et la broche centrale ont été séparées. Cela permet d’échanger la broche centrale pour utiliser un diamètre plus grand ou plus petit, parce que parfois la découpe laser est plus large car évaporant plus de matière. Le trou est alors un peu plus grand. Vous verrez également que l’enclume a été «chanfreinée».

Ceci a été ajouté pour pouvoir poinçonner à proximité d’un autre trou fraisé.

Réalisation de l’opération de poinçonnage

La première étape pour le poinçonnage consiste à placer la plaque d’aluminium au dessus de l’enclume sur la broche centrale.

L’axe central garantit que le trou dans la tôle d’aluminium se trouve au centre du poinçon. Lorsque la colonne avec la partie supérieure de l’outil de poinçonnage est déplacée vers le bas, la tôle d’aluminium est serrée entre la bague de serrage (par le ressort hélicoïdal) et l’enclume.

Au fur et à mesure que la colonne est déplacée vers le bas, le ressort en spirale est comprimé et soumet la tôle d’aluminium à une force considérable. Parce que l’enclume et l’anneau de serrage ont tous deux une pente descendante de 5 degrés, la tôle d’aluminium se plie également vers le bas autour du trou. A ce moment, le poinçon « la pièce de travail » (la partie supérieure de l’outil de poinçonnage), repousse le cône dans la plaque d’aluminium.

Lorsqu’on remonte la perceuse, la tôle d’aluminium se courbe vers le haut en restant presque plate …

mais avec un cône fraisé autour du trou.

Tout ceci prend environ trois secondes, alors que la méthode utilisant un foret à fraiser peut parfois prendre jusqu’à 30 secondes.

Le retour sur investissement.

Pour être honnête, je n’ai pas fait de calculs pour voir combien PiCano devait être vendu, pour récupérer l’investissement en temps et en matériaux. Dès le début, je savais que le fraisage par déformation de la tôle d’aluminium serait beaucoup plus rapide que le fraisage par perçage. Maintenant je peux dire avec certitude qu’il ne faudra pas vendre plus de 100 boîtiers pour compenser l’investissement.

La grande question était, combien de boîtiers PiCano seront-ils vendus ? Parce qu’à l’époque, où j’ai vraiment commencé à planifier la fabrication de l’outil, les ventes se sont simplement arrêtées, suscitant des doutes… L’initiative allait-elle disparaître, ou durer assez longtemps … Peut-être allais-je passer beaucoup de temps, créer un outil et ne jamais récupérer l’investissement. J’ai décidé de continuer j’ai écrit cet article parallèlement, ce qui, espérons-le… va relancer les ventes faisant de l’outil de fraisage également un « outil marketing ».

Voilà, c’est tout

J’ai souhaité présenter un cas évident d’amélioration de l’efficacité par de petits changements de conception. Dans ma carrière, j’ai rencontré des projets plus difficiles pour lesquels les calculs de Timing et de retour sur investissement devaient être faits très précisément, afin de pouvoir prouver, à l’avance, que l’investissement en étude et en coût pouvait être rentabilisé dans un délai convenable. La différence est que dans une grande entreprise, l’efficacité ajoutée est multipliée par un grand nombre de pièces produites. Dans mon cas, l’outil devait être finalisé dans un court laps de temps et pour un petit nombre de pièces en production.

Bien sûr, j’aurais pu acheter un outil de poinçonnage, mais il n’aurait pas pu s’installer sur ma perceuse à colonne et cet article aurait été … ennuyeux.

PiCano un boîtier de Raspberry Pi VESA, design et costaud

C’est avec plaisir que j’ai publié cet article de Steve. Son boîtier PiCano est superbe. Sa solidité est telle qu’on peut l’intercaler entre un support VESA et un écran sans aucun souci.

Si vous êtes intéressé(e), reportez vous aux articles précédents parus en  juin 2014 et en décembre 2014.

Le PiCano est vendu 39,95€ et les frais de port pour la France sont de  14,95€. Le paiement par PayPal est possible.

Conclusion

Merci à Steve Royd Marker (picano@markerdesign.be) pour cet article très intéressant sur l’évolution d’un projet et le cheminement d’un créateur pour apporter des améliorations à sa création.

C’est pour moi l’occasion de revenir sur un leitmotiv qui revient régulièrement sur framboise314 (vous me direz, c’est normal pour un leitmotiv 😉 ) : C’est trop cher !

Bin oui quand on se contente de recopier un objet existant on peut le proposer à des prix imbattables. Par contre celui (celle) qui développe un nouveau produit investit du temps, de l’argent, doit se dégager une paye pour nourrir ses enfants, payer les taxes, impôts, URSSAF, retraite, sécu et… j’en oublie. C’est impossible de vendre un produit au prix de la matière première…
Donc on peut râler que certains produits sont trop chers et qu’on en trouve des « pareils » (des copies ?) sur des sites de vente en ligne asiatique mais il y a des raisons.

J’ai retenu un commentaire d’Arthur, sur un post de la page facebook de framboise314 :
Un jour Picasso a fait un croquis sur une nappe de restaurant à la demande d’une riche cliente. Au moment de lui donner, il lui a demandé 10000 Fr.
La dame lui a dit « mais ça vous a pris 5 min! »
Ce à quoi Picasso a répondu « Non madame, ça m’a pris 30 ans »…

Je pense qu’il montre bien ce que j’ai essayé de vous expliquer dans les lignes précédentes.

Sources

PiCano : un boîtier VESA pour le Raspberry Pi B+

PiCano un boîtier à la norme VESA pour le Raspberry Pi

 

 

Cet article PiCano un boîtier VESA pour votre Raspberry Pi a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Carte pHAT infrarouge pour Raspberry Pi

Transformez votre Raspberry Pi en une puissante télécommande pilotée par LIRC, un logiciel open source avec une carte d’extension  ANAVI Infrared pHAT open-hardware.

Carte d’extension pHAT télécommande infrarouge intelligente pour le Raspberry Pi

====== Traduction de l’offre Indiegogo ======

La carte ANAVI infrarouge pHAT

La carte ANAVI pHAT Infrarouge est une carte d’extension qui convertit votre Raspberry Pi en une puissante télécommande et transporte votre ancienne TV, votre chaîne HiFi ou votre climatisation à l’ère de l’Internet des Objets (IoT). Les caractéristiques de cette carte :

  • 2 LED émettrices infrarouges de 5mm (IR LED)
  • 1 Récepteur infrarouge (IR photo sensor)
  • 3 Emplacements pour des capteurs I2C
  • des broches UART accessibles pour le débogage

Le démarrage de cette carte ANAVI pHAT infrarouge ne devrait pas être compliqué. Aucune soudure n’est nécessaire. Vous pouvez assembler le kit avec vos seules mains, sans outil, et commencer à l’utiliser immédiatement sur Raspbian, la distribution GNU/Linux la plus populaire pour Raspberry Pi. Un manuel utilisateur complet avec un descriptif de toutes les étapes est disponible en ligne. Au sortir de la boîte la carte ANAVI pHAT infrarouge accepte des capteurs de température, d’humidité, de pression barométrique et de lumière. Des exemples open-source écrits en Python et en C sont disponibles sur GitHub.

ANAVI pHAT infrarouge a commencé comme un projet de loisir pour Leon Anavi. Je vous avais déjà parlé d’un de ses précédents projets : RabbitMax. Les circuits imprimés sont conçus, fabriquées et assemblés dans sa ville natale de Plovdiv en Bulgarie (Union Européenne).

Est-ce que je peux contrôler mon téléviseur et ma chaîne hi-fi ?

Oui, avec la carte ANAVI pHAT infrarouge et le logiciel open-source LIRC, vous pouvez enregistrer les informations émises par la télécommande de votre téléviseur et/ou chaîne HiFi et ensuite contrôler l’appareil via votre Raspberry Pi.

Est-ce que je peux contrôler ma climatisation ?

Oui, même si les télécommandes de climatisation sont beaucoup plus sophistiquées, vous pouvez toujours les numériser et contrôler la climatisation avec la carte ANAVI pHAT infrarouge. Le manuel de l’utilisateur présente un exemple de configuration de LIRC pour allumer et éteindre un climatiseur.

Quels sont les capteurs pris en charge ?

La carte ANAVI pHAT infrarouge supporte nativement les modules capteurs I2C suivants :

  • HTU21 pour la température et l’humidité
  • BMP180 / BMP280 pour pression barométrique
  • BH1750 pour éclairage

Vous pouvez également brancher d’autres capteurs I2C, mais vous devrez assurer leur intégration logicielle.

Quelles versions et modèles de Raspberry Pi sont pris en charge ?

La carte ANAVI pHAT infrarouge est compatible avec les modèles et versions de Raspberry Pi suivants:

  • Raspberry Pi 3 Modèle B
  • RaspberryPi 2 Modèle B
  • Raspberry1 Modèle A +
  • Raspberry1 Modèle B +
  • Raspberry Pi Zero
  • Raspberry Pi Zero-W

Cette carte n’est pas compatible avec les modèles antérieurs à 26 broches du Raspberry Pi 1 (Model B & A).

La carte ANAVI pHAT infrarouge est-elle un projet Open Source ?

Oui, la carte ANAVI pHAT infrarouge est un projet matériel open source animé et créé avec des logiciels libres et open source. La carte est conçue avec la suite de conception d’électronique libre et ouverte KiCAD. Les schémas, PCB et logiciels open source sont disponibles sur GitHub.

Les exemples d’applications Open Source écrits en Python et en langage C sont fournis. En utilisant LIRC, le logiciel libre et open source pour Linux, vous pouvez scanner les télécommandes infrarouges et contrôler les appareils électroménagers comme la TV, la HiFi, la climatisation, etc. Consultez le manuel d’utilisation complet pour en savoir plus.

Quelles sont les récompenses ?

La campagne IndieGoGo vous permet de recevoir les récompenses suivantes:

La carte ANAVI pHAT infrarouge est incluse dans toutes les récompenses.

Le Raspberry Pi n’est PAS inclus dans les récompenses.

Comment expédiez-vous les récompenses ?

Toutes les récompenses sont expédiées dans le monde entier via le service de poste aérienne des Bulgarian Posts. Les frais de port dépendent de la récompense et de la localisation de votre domicile.

Les frais de port incluent l’emballage dans une boîte de carton individuelle et une enveloppe avec des bulles d’air pour plus de sécurité pendant le transport.

Pourquoi financer ANAVI pHAT infrarouge ?

La carte ANAVI pHAT infrarouge est déjà un produit stable. Des prototypes de travail et une petite série ont été réalisés. Maintenant le financement participatif va permettre de lancer une production de masse.

Ensemble, il est possible de diminuer les coûts de fabrication et de réduire le prix du produit final. Toute contribution a un impact et peut faire la différence.

Combien ça coûte ?

De 9$ pour la carte pHAT seule à 99$ pour 4 cartes avec tous les capteurs. Certaines récompenses incluent une télécommande infrarouge.

Vidéo

Conclusion

Avec un prix très abordable, cette carte donne accès aux signaux infrarouge de nombreuses télécommandes. Sa compatibilité avec les capteurs I2C (et on en trouve pour un faible coût sur les sites de vente en ligne) ouvre aussi la voie à de nombreuses expérimentations.

Sources

Manuel :

Github :

Utilitaires :

Raspberry Pi : Dupliquer sa télécommande IR

 

 

Cet article Carte pHAT infrarouge pour Raspberry Pi a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Conférence Raspberry Pi chez Eyrolles le 11 mars 2017

J’animerai une conférence sur le Raspberry Pi à la Librairie Eyrolles Boulevard Saint-Germain à Paris le 11 mars 2017 de 15h à 17h.

Conférence Raspberry Pi – Eyrolles

Après une approche technique des modèles Raspberry Pi 3 et Raspberry Pi Zero, je présenterai des applications de ces nano-ordinateurs dans divers domaines. A l’issue de la conférence nous pourrons échanger un moment et je dédicacerai pour ceux et celles qui le souhaitent mon livre « Raspberry Pi 3 ou Pi Zero » publié aux Editions ENI.
Attention, le nombre de place est limité et il faut réserver à l’avance! :

Rendez-vous :

Renseignements et inscription :

  • par téléphone au 01 44 41 11 31
  • ou directement à la librairie Eyrolles auprès des libraires

La conférence est également annoncée sur unidivers.fr

Cet article Conférence Raspberry Pi chez Eyrolles le 11 mars 2017 a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....