Je vais partir du postulat que vous connaissez les bases de GStreamer (source, sink, pipeline, etc ...) sinon, je vous conseille fortement d'aller jeter un coup d'œil sur le blog de nicolargo section GStreamer. Vous y trouverez toutes les informations nécessaires à la compréhension de la suite du billet.
Je me suis même inspiré d'un de ses billets (j'ai streamé avec GStreamer) pour rédiger le mien.
Les tests réalisés sont :
Streaming UDP avec encodage vidéo Theora d'une vidéo test (Mire)
Streaming UDP avec encodage vidéo H264 d'une vidéo test (Mire)
Streaming TCP avec encodage vidéo H264 d'une vidéo test (Mire)
Streaming RTP/RTCP avec encodage vidéo H264 d'une vidéo test (Mire)
Streaming RTSP avec encodage vidéo H264 d'une vidéo test (Mire)
Ce petit billet pour faire part des quelques modifications à apporter à la dernière release (1.19.0) de crosstool-NG pour créer une chaîne de compilation croisée pour la raspberry pi sur une distribution arch-linux x86_64.
Ce tutoriel va nous permettre de construire, grâce à une raspberry pi, un serveur de streaming vidéo et/ou audio et notamment diffuser un flux vidéo provenant d'une caméra. N'ayant pas encore en ma possession le module caméra de la raspberry pi, je vais utiliser une webcam USB du commerce compatible avec la raspberry pi (USB Webcam).
Le serveur de streaming que nous allons installer est basé sur le protocole RTSP (Real Time Streaming Protocol). Ce protocole RTSP est implémenté sur la couche 7 du modèle OSI (couche applicative) et utilise les couches de transports RTP/RTCP pour faire circuler les flux de données sur un réseau IP.
L'avantage du RTSP est de diffuser un ou plusieurs flux seulement quand un client se connecte au serveur et ce même client peut interagir avec le flux de données (lecture, pause, retour en arrière, en avant, etc ...).
Ce tutoriel est divisé en deux billets, Ce billet est consacré à la construction et l'installation d'un serveur RTSP basé sur le framework GStreamer sur notre raspberry pi et le second billet est consacré à l'introduction de GStreamer avec des cas simples d'utilisation et notamment la démonstration de notre serveur RTSP.
Pour ce billet, nous allons travailler avec :
Notre environnement de compilation : buildroot-2013.08.1.
Kernel 3.12.0.
Chaîne de compilation croisée construite avec crosstool-NG 1.15.0.
Packages rpi-userland et rpi-firmware.
Framework GStreamer version 1.2.0 et ses plugins standards (base, bad, ugly et good) en version 1.2.0.
Plugin OMX (OpenMAX IL wrapper) version Git, qui nous permettra d'encoder les vidéos grâce aux GPU de la raspberry pi.
Ce billet est consacré à la transformation d'une raspberry pi en hotspot wifi grâce au dongle wifi DWA-121.
J'ai déjà présenté ce dongle et comment l'interfacer avec une raspberry pi dans un précédent billet.
On va reprendre tout ça pour l'utiliser avec le nouveau noyau linux 3.12.0.
J'utilise le terme "hotspot" mais il faudrait plus utiliser le terme "point d'accès" puisque je n'aborderai pas la partie partage de connexion Internet grâce aux iptables. De nombreux tutoriels existent sur le net sur le partage de connexion.
Les outils principaux abordés sur ce billet seront :
8192cu.ko : Driver pour le dongle DWA-121
wireless tools (iwconfig, iwlist, ...) : Utilitaires pour la gestion du wifi.
hostapd : Utilitaire de création de point d'accès wifi.
dhcpd : démon de serveur dhcp permettant l'attribution d'adresses IP aux appareils se connectant à la raspberry pi.
Dans un précédent billet, on a vu comment s'interfacer avec l'afficheur LCD 2x16 caractères depuis un code écrit en C. On va maintenant s'intéresser à un module python pour afficher des informations sur l'afficheur.
L'un des principaux avantages du python par rapport au langage C est que l'on a pas besoin de compiler le code pour le lancer sur la raspberry pi, donc moins galère pour faire du prototypage.
La base de l'environnement embarqué de travail est :
Mon dernier achat est un dongle WIFI. Avant cet achat compulsif, j'ai vérifié dans la liste fournie sur le wiki de raspberry pi, quel modèle acheter. C'est déjà pas forcément facile avec du matériel certifié alors si on part dans l'inconnu, c'est encore plus galère....
L'heureux élu est le dongle DWA-121 de la marque D-LINK.
Le but de ce tutoriel est de configurer le dongle wifi sur une distribution de type buildroot (oubliez network-manager et tout ce qui va avec ....)
L'architecture logicielle de la carte contrôleur est relativement simple.
On reçoit des trames provenant du bus I²C via le handler d'interruption et les empiler dans une file d'attente (FIFO), ensuite, périodiquement, on dépile la file d'attente et traite les trames enregistrées pour afficher les informations sur l'écran LCD.
Ce projet consiste à interfacer un afficheur alphanumérique 2x16 caractères avec la raspberry pi. Il va pouvoir indiquer différentes informations sur l'état de la raspberry pi en fonctionnement (exemples : information sur la mémoire, le micro processeur, les process, etc ...).
Ça a l'air d'être à la mode d'interfacer un afficheur à la raspberry pi. Vous trouverez sur la toile, de nombreux tutoriels pour le faire directement.
Je vais complexifier un peu la chose, rien de bien méchant, je vous rassure ;-)
L'afficheur va être contrôlé avec un micro contrôleur 8bits de la marque Microchip (Pic 16f876a) et dialoguera avec la raspberry pi via le bus I2C. Cela permettra d'appréhender la communication entre 2 micros via un bus série.
Architecture générale du projet
J'ai choisi ce micro contrôleur 8 bits parce qu'il est possible :
d'écrire le programme en C (je suis pas un grand fan de l'assembleur)
de compiler le programme sous Linux à l'aide du compilateur HI-TECH C compiler (il existe, de plus, une version demo et lite)
de le faire évoluer pour d'autres fonctionnalités.
de pouvoir découvrir de nouveaux aspects des systèmes embarqués.
de réduire les coûts de développement (quelques euros, voir dizaines d'euros avec le programmateur)
Le premier billet va illustrer les différents éléments de ce projet.
Le second billet va aborder les différents modules du micro contrôleur PIC 16f876a à mettre en place et finalement, le dernier billet montrera l'interface avec la raspberry pi.
Voici un petit outil de supervision, créé par Nicolargo dont voici le lien du blog : blog de nicolargo. Cet outil s'appelle Glances, et permet surveiller son système en mode console depuis un terminal. Cet outil est développé en python et utilise différentes librairies python, notamment psutil qui récupère les informations systèmes de la raspberry pi.
Les différentes statistiques sont classées et visibles grâce à différentes couleurs :
VERT : la statistique est OK
BLEU : la statistique est à surveiller
VIOLET : la statistique est en alerte
ROUGE : la statistique est critique
De nombreux raccourci clavier permettent d'activer ou désactiver différentes fonctions, de trier certaines statistiques, etc ...
On m'a refiler 2 commodores 64 pour "essayer" de les réparer et d'en faire un fonctionnel. Donc je me suis retrouvé avec 2 châssis pour une seule carte électronique, et j'ai eu l'idée en parcourant différents site web d'électronique, DIY, blog, etc ... de me faire un RPI mod C64.
Le cahier des charges de ce projet est relativement simple, utiliser un châssis + clavier de commodore 64 pour jouer à des jeux de commodore 64 mais sur une Raspberry Pi, et pour rajouter un peu plus de fun dans tout ça, pouvoir l'utiliser en tant que média center.
Voici le résultat final :
2 interrupteurs, le premier pour l'alimentation électrique et le second pour changer de mode (émulateur ou media center)
1 led d'état du contrôleur de clavier
et l'intérieur de la bête :
Les différentes grandes étapes du projet sont :
Compiler XBMC (media center) pour buildroot et l'intégrer au système de fichiers
Compiler Vice C64 (émulateur commodore C64) pour buildroot et l'intégrer au système de fichiers
Créer un programme qui contrôle le démarrage et l'arrêt du mediacenter/émulateur en fonction de la position d'un switch
Créer une carte contrôleur pour la gestion du clavier C64 en USB.
Il y a eu quelques évolutions sur la dernière version de buildroot et ses différents composants, du coup, certaines petites modifications sont nécessaires par rapport au tutoriel que j'ai pu vous présenter précédemment.
J'ai essayé de faire les choses proprement et je vous ai pondu un patch à appliquer à la version de buildroot pour pouvoir générer notre système sans trop de souci.
Il est possible de télécharger des fichiers (légaux ou pas, ce n'est pas le débat ;-)) grâce à différents outils. Nous allons nous intéresser aux newsgroupset à un des lecteurs de news existants sur la toile, SABnzbd. SABnzbd est un lecteur de groupes de discussion multi-platforme open source. Il a l'avantage de pouvoir être utilisé en tant que service, configurable via une page internet et simplifie le téléchargement de fichiers.
Il est écrit en python, ce qui va nous permettre de comprendre comment installer python et ses modules (internes et externes) sur la raspberry pi et les utiliser.
Pré-requis :
SABnzbd requiert différents paquets avant l'installation de celui-ci :
Python (version 2.5.x, 2.6.x, 2.7.x (recommandé)) - Pas encore la version 3.0
La librairie python Cheetah (moteur de templates)
La librairie python yEnc (encodage/décodage)
La librairie python sqlite
La librairie python openssl
La librairie python CherryPi
binaire par2 et unrar
Les différents modules python demandés ne sont, nativement, pas présents sur buildroot, donc il va falloir les installer.
Pour ce billet de rentrée, je vais expliquer comment intégrer un serveur UPnP (Universal Plug & Play) à notre Raspberry Pi. Le serveur UPnP servira à partager tous types de documents multimédia sur un réseau (audio, image et vidéo).
Il est biensur possible d'utiliser le fameux media center XBMC (porté pour la raspberry pi) pour partager et visualiser les documents, mais dans mon cas, je souhaite quelque chose de leger, de facile à administrer et j'ai toujours pas envie de brancher ma RasPi sur ma télévision. ;-).
Je me suis tourné vers le serveur GPL UPnP MediaTomb. Il me permet entre autre d'administrer mon serveur via une page web, de faire du transcodage, de faire des miniatures et pleins de bonnes choses encore.
Nativement, le packge MediaTomb n'est pas présent dans l'environnement Buildroot, on va commencer par ajouter ce paquet à buildroot pour le configurer, le compiler et l'installer sur notre cible.
Avant de proposer la deuxième partie de mon tutoriel sur la gestion d'une entrée GPIO à travers un driver Linux, je vais montrer comment intégrer le driver de led, précédemment créé, directement dans les sources du noyau pour pouvoir le compiler et l'installer en même temps que les autres modules.
Je rappelle que le fichier source du module est disponible sous github.
git://github.com/sinseman44/rpiled.git
Mon noyau Linux ayant été compilé avec l’environnement buildroot. les sources du kernel se trouve dans le dossier buildroot/output/build/linux-HEAD.
A partir de ce dossier parent, je vais copier le fichier source du module (raspberrypi_test_led.c) dans la partie drivers/gpio.
Dans ce dossier, 2 fichiers vont être modifiés pour l'intégration (Kconfig et Makefile).
Le premier Kconfig, fichier d'interface permettant de sélectionner via le menuconfig, les modules à installer avec le noyau :
menuconfig GPIOLIB
bool "GPIO Support"
depends on ARCH_WANT_OPTIONAL_GPIOLIB || ARCH_REQUIRE_GPIOLIB
select GENERIC_GPIO
help
This enables GPIO support through the generic GPIO library.
You only need to enable this, if you also want to enable
one or more of the GPIO drivers below.
If unsure, say N.
if GPIOLIB
config RPI_GPIO_LED
tristate "Raspberry Pi led GPIO"
depends on GPIOLIB
help
driver to test a led connected to the raspberry pi
config DEBUG_GPIO
bool "Debug GPIO calls"
depends on DEBUG_KERNEL
help
Say Y here to add some extra checks and diagnostics to GPIO calls.
These checks help ensure that GPIOs have been properly initialized
before they are used, and that sleeping calls are not made from
non-sleeping contexts. They can make bitbanged serial protocols
slower. The diagnostics help catch the type of setup errors
that are most common when setting up new platforms or boards.
Il y a deux possibilités pour la compilation soit statique, le noyau va construire le fichier objet et inclure le module directement l'image finale, soit dynamique, le driver va être compilé en module et c'est à l'utilisateur de charger/décharger par la suite le module sur le système embarqué.
Certains drivers ont la variable bool à la place de tristate, dans ce cas, le driver est soit compilé en statique, soit pas. La variable tristate, laisse le choix à l'utilisateur de compiler le driver en statique (X), en module (M) ou pas du tout.
La capture d'écran montre que notre driver va être compilé en module.
La carte raspberry pi offre la possibilité d'interagir (facilement) avec quelques entrées/sorties (connecteur 2x13 pins présents sur un coté de la carte). Ce tutoriel va se concentrer sur l'utilisation d'une entrée (partie 1) et d'une sortie (partie 2) pour montrer les différentes possibilités que nous offrent cette carte.
Les GPIOs sont présentes sur le connecteur 2x13 pins, avec d'autres signaux, tels que les alimentations +3,3v et +5v et la masse.
Certaines de ces GPIOs (0, 1, 4, 7, 8, 9, 10, 11, 14, 15, 18, 21) sont multiplexées avec d'autres fonctionnalités (Ex : GPIO 14 est multiplexé avec la transmission UART, soit on l'utilise en tant que GPIO ou en tant que transmission UART, mais pas les deux en même temps).
Pour ce billet, je vais me concentrer sur deux GPIOs (la 17 en sortie, reliée à une led et la 18 en entrée, reliée au bouton poussoir).
Le schéma de câblage est du plus basique. Une LED standard orange, avec une tension à ses bornes de 2,1v et une résistance de 60 Ohms pour fournir les 20 mA nécessaires. Une résistance de tirage d'une centaine d'ohms pour la liaison avec le bouton poussoir.
Accès aux GPIOs depuis l'espace utilisateur :
On va commencer à jouer avec les GPIOs depuis l'espace utilisateur, puisque il est possible d'interagir avec chaque GPIO du système depuis l'interface /sys/class/gpio.
Au démarrage du système, les GPIOs sont configurées par le noyau et de ce fait, non visible depuis l'espace utilisateur. Pour les rendre visible, il suffit de les exporter en indiquant le numéro de la pin souhaitée.
[raspberry_pi]# ls gpio17
active_low direction power subsystem uevent value
[raspberry_pi]# cat gpio17/direction
in
On va configurer la GPIO17 en sortie et allumer (ou éteindre) la led grâce au fichier value.
[raspberry_pi]# echo out > gpio17/direction
[raspberry_pi]# cat gpio17/direction
out
[raspberry_pi]# cat gpio17/value
0
[raspberry_pi]# echo 1 > gpio17/value (la LED s'allume)
[raspberry_pi]# cat gpio17/value
1
[raspberry_pi]# echo 0 > gpio17/value (la LED s'éteint)
[raspberry_pi]# cat gpio17/value
0
On va configurer la GPIO18 en entrée et vérifier l'état du bouton grâce au fichier value.
[raspberry_pi]# echo in > gpio18/direction
[raspberry_pi]# cat gpio18/direction
in
[raspberry_pi]# cat gpio18/value
0
(on appuie sur le bouton)
[raspberry_pi]# cat gpio18/value
1
(on relâche le bouton)
[raspberry_pi]# cat gpio18/value
0
Accès aux GPIOs depuis l'espace noyau :
Préambule
Je conseille, surtout un peu de lecture (pour les plus courageux), sur l'utilisation des GPIOs dans un driver Linux. Cette documentation nommée, gpio.txt, se trouve dans les sources du noyau, LINUX_PATH/Documentation/gpio.txt.
Pilotage d'une LED
Grâce aux drivers, nous avons la possibilité de contrôler un périphérique avec des interactions (ou pas) depuis l'espace utilisateur. Pour cet exemple, je vais contrôler une LED via le driver (Activation, désactivation et clignotement).
Ce driver est présent sur github à cette adresse :
git://github.com/sinseman44/rpiled.git
La récupération des sources et du module (déjà compilé) se fera via la commande :
Pour ceux qui veulent re-compiler leur module, passer au chapitre suivant, sinon passer directement au chapitre "utilisation du module.
Compilation du module
(La chaîne de compilation croisée a été préalablement installée dans le PATH)
Dans ce tutoriel, le module est compilé en dehors du noyau linux, un guide est fourni dans les docs du noyau linux, chapitre "How to build external modules" dans LINUX_PATH/Documentations/kbuild/modules.txt. Un makefile est fourni dans le package pour la compilation de celui-ci.
Pour obtenir un module à partir de ce code source, il va falloir le compiler en utilisant les sources du noyau et le compilateur croisée :
# cd rpiled
# make ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnueabi-
On indique l'architecture de la cible et la chaîne de compilation croisée.
A la sortie de compilation, plusieurs fichiers se sont créés ainsi que le module, raspberrypi_test_led.ko :
Au chargement du module, un nœud nommé rpiled va être créé dans le dossier dev avec comme numéro de majeur 252 et numéro de mineur 0. Ce nœud va servir à l'utilisateur pour interagir avec le périphérique via une application (utilisation des méthodes open, read, close). exemple :
# cat /dev/rpiled
Conclusion
Maintenant que le gestion d'une GPIO en sortie est traitée (driver et application), nous allons nous intéresser à la gestion d'une GPIO en entrée (bouton poussoir) à l'aide d'un driver Linux.
Après avoir compiler nos différents éléments, nous allons maintenant les insérer sur une carte SD. avant cela, nous allons la formater suivant le tutoriel fourni sur le wiki de raspberry pi. Il suffit simplement de suivre le tutoriel à une petite modification près. Au lieu de formater la partition linux au format Ext3, nous allons la formater au format Ext4.
ensuite, décompressez les deux archives boot.tar.gz et rootfs.tar.gz trouvées dans le dossier de buildroot output/images, dans respectivement, les partitions boot (FAT32 LBA) et rootfs (EXT4) créées précédemment.
A noter que l'extraction de l'archive rootfs doit se faire avec les droits super utilisateurs.
# tar xzf output/images/boot.tar.gz -C /media/FAT32_PARTITION
# sudo tar xzf output/images/rootfs.tar.gz -C /media/EXT4_PARTITION
ensuite démonter la carte SD et insérer la sur la carte raspberry pi.
Une fois que l'on a une chaine de compilation fonctionnelle, il ne sert à rien d'en reconstruire une à chaque fois, c'est pourquoi je propose ma chaîne de compilation croisée (~ 228 Mo) pour la carte raspberry pi, compilée sur une machine X86, donc fonctionnelle sur les machines X86 ou 64bits.
Si tout de fois, une chaîne de compilation croisée a déjà été compilée, il est préférable de nettoyer l'environnement avec d'utiliser la nouvelle chaîne.
# make clean
Pour l'utiliser, il faut tout d'abord la décompresser puis configurer buildroot, pour cela, on reprend la commande :
# tar xvzf arm-unknown-linux-gnueabi.tar.gz -C CHEMIN_INSTALLATION
# make menuconfig
Dans le menu, on entre dans le sous menu toolchain :
Dans ce sous-menu, on choisi external toolchain type et custom toolchain, dans les deux premiers champs. Le suivant sert à entrer le chemin de la chaîne de compilation croisée, la libc est une glibc et elle a le support c++.
Il ne reste plus qu'à compiler l'environnement avec cette nouvelle chaine et le tour est joué ...
La plupart des utilisateurs utiliseront leur carte avec une distribution Linux adaptée, telle que Debian squeeze ou Arch Linux pour ne citer qu'eux (disponible en téléchargement sur le site de raspberry pi). Elles offrent la possibilité d'avoir une suite complète de logiciel pour l'administration du système, la programmation, le multimédia et autres.
Ces distributions nécessitent d'avoir une carte SD avec une taille adaptée, environ 2 Go minimum.
Je vais partir du postulat que je n'ai ni le besoin, ni l'envie, d'utiliser ce genre de distribution. Pour cela, je vais me construire un environnement minimaliste pour ma carte.
Cet environnement sera constitué d' :
Une chaine de compilation croisée
Un bootloader
Un Noyau Linux
Un système de fichiers (avec tout ce qui va bien dedans, ex : busybox, etc ...)
Dans cette première partie, On va s’intéresser à la construction de notre système et la deuxième partie abordera la mise en route de notre système sur la carte.
