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.
Il y a pas mal de projets de boiter de protections pour le raspberry pi. Certains déjà abouti, d'autres pas encore. Je vous propose ma solution "Do It Yourself".
Je me suis procuré un boîtier plastique standard (transparent pour le fun) chez électronique-diffusion (quelques boutiques en France, dont une sur Toulouse, mais on peut aussi commander online), pour 6- 7 euros, correspondant au mieux aux dimensions de la carte.
A première vue, la carte est trop large de quelques millimètres pour rentrer dans le boîtier, et il va falloir le raboter et le découper pour un accès aux différents connecteurs (les cotes ont été prises "à l’œil").
Une fois les modifications faites, voici ce que ça donne :
Le boîtier fermé :
Une protection à faire soi-même pour quelques euros et de l'huile de coude. ;)
Ça y est j'ai craqué, La console sur la télévision (seule entrée HDMI disponible) ce n'était pas génial pour déboguer les éventuels problèmes sur le chargement de mon firmware. J'ai décidé de me construire un module grâce aux PINs UART sortantes.
Une console série permet de contrôler un système à partir d'un terminal branché sur le port série d'un ordinateur. Il existe du matériel permettant de convertir des signaux série en signaux USB, donc d'utiliser une console série avec une connexion USB, c'est ce que je vais utiliser.
Je me suis acheté un module FTDI (UART vers USB) sur Ebay (environ une quinzaine d'euros avec frais de port).
Seuls les PINs Rx, Tx et GND seront soudés sur le module FTDI et les signaux Rx et Tx seront inversés entre les cartes, comme indiqué sur le schéma suivant.
Sur la raspberry pi, le schéma des Entrées Sorties est le suivant :
