Pilote Linux du contrôleur de servomoteurs

Rejoignez la communauté SCIencextrA . .

http://www.unixgarden.com/

Dans la première partie, nous avons conçu un nouveau périphérique basé sur un FPGA : le contrôleur matériel de servomoteurs. Il est l’équivalent d’un circuit électronique capable d’une concurrence vraie tout en ayant la souplesse d’une  conception logicielle.

Comme tout périphérique, il nécessite un peu de logiciel pour être utilisable sous un système d’exploitation tel que Linux. Tout d’abord, nous aborderons le pilote de périphérique ou driver. Il est au sein du noyau Linux et assure la communication entre le matériel et l’espace utilisateur. Ensuite, nous verrons le serveur de commandes. Il reçoit les ordres d’un client distant et les exécute. Pour clore le sujet loin des arcanes du mode noyau, un exemple de client graphique Qt est présenté, qui permet de faire bouger les servomoteurs avec une souris.

1 Le pilote Linux du contrôleur de servos

La gestion du matériel étant l’une des fonctions régaliennes du noyau Linux, l’accès au contrôleur de servos FPGA est réalisé via un pilote de périphérique implanté dans un module noyau. Une application en mode utilisateur, comme le serveur de commandes que nous verrons plus loin, communiquera avec ce pilote plutôt que de dialoguer directement avec le matériel. Je ne reviendrai pas sur la nécessité d’adopter une telle architecture tant elle est acceptée et utilisée aujourd’hui.

1.1 L’environnement de compilation croisée et Linux Kbuild

La compilation du code source pour le système cible ARM9 nécessite une chaîne de compilation croisée pour créer les fichiers exécutables ARM9 sur le système hôte qui est le plus souvent du type x86. Le SDK Armadeus est basé sur Buildroot [34], GCC [35], GNU Binutils [36] et la uClibc[37]. Buildroot permet d’ordonnancer la construction d’un système embarqué complet. La chaîne GCC et Binutils assurent les compilations croisées. La uClibc apporte la bibliothèque C standard pour le code en mode utilisateur. D’autres logiciels libres sont bien sûr utilisés, mais ces quatre éléments constituent le cœur du SDK, que nous appelleronstoolchain. L’installation de la toolchain est décrite en [15]. Lors de l’installation initiale, Buildroot lance la compilation de tous ces outils, ce qui explique le temps pris par cette première étape. À l’issue, la toolchain est installée dans le répertoire  $ARMADEUS_BASE_DIR/buildroot/build_armvXX/staging_dir/usr/binoù $ARMADEUS_BASE_DIR est le répertoire de base du SDK Armadeus et XX vaut 4t pour une APF9328 et 5te pour une APF27. Toutes les compilations à destination du système cible devront utiliser les outils présents dans ce répertoire.

Ce chemin sera simplifié dans les prochaines versions du SDK Armadeus qui utiliseront une version plus récente de Buildroot. Il est contenu dans la variable$ARMADEUS_TOOLCHAIN_PATH définie en sourçantarmadeus_env.sh. armadeus_env.sh est obtenu en lançantmake shell_env dans le répertoire$ARMADEUS_BASE_DIR.

Cette remarque s’applique aussi à la compilation du noyau Linux. Mais le SDK Armadeus et Buildroot nous facilitent le travail en masquant toute cette complexité et en plaçant les variables requises par Kbuild. Kbuild est le système de compilation du noyau Linux. Il est assez complexe mais permet de simplifier grandement l’écriture des fichiers de configuration Kconfig et des fichiers Makefilenécessaires à la compilation d’un module noyau Linux. Le pilote est distribué sous la forme d’un patch qui crée le répertoire$ARMADEUS_BASE_DIR/target/linux/modules/fpga/armadeusservodriver. Celui-ci contient les fichiers suivants : - Kconfig : fichier de configuration du module noyau ; - Makefile : fichierMakefile permettant la compilation du module ; - servo.h : fichier d’en-tête du pilote ; - servo.c : fichier source du pilote. Le répertoire$ARMADEUS_BASE_DIR/target/linux/modules contient tous les pilotes spécifiques aux systèmes Armadeus. Il est intégré à l’arborescence du noyau Linux via un lien symboliquedrivers/armadeus qui pointe vers lui. Le fichier Kconfig ajoute une entrée sous Device Drivers  ---> Armadeus specific drivers  ---> FPGA Drivers dans l’outil de configuration de Linux obtenu habituellement par make menuconfig. Le fichier Kconfig du répertoire parent l’inclut par :

source "drivers/armadeus/fpga/armadeusservodriver/Kconfig"

En voici son contenu :

config ARMADEUS_SERVO_DRIVER
        tristate "Armadeus Servo driver"
        depends on ARMADEUS_FPGA_DRIVERS
        ---help---
                  This driver allow you to use the servo FPGA firware

config ARMADEUS_SERVO_DRIVER définit une variableCONFIG_ARMADEUS_SERVO_DRIVER accessible dans tous les fichiers Makefile et par le préprocesseur C. Elle sera stockée dans le fichier de configuration.config de Linux.tristate "Armadeus Servo driver" indique que cette variable pourra prendre une valeur parmi trois et affiche le texte "Armadeus Servo driver" dans le menu. Enfin, ---help---contient le texte le l’aide contextuelle de l’outil de configuration. Le fichier Makefile pourrait être réduit à :

obj-$(CONFIG_ARMADEUS_SERVO_DRIVER)     += servo.o

Kbuild nous rend là un grand service : une seule ligne pour définir la compilation croisée du module.  CONFIG_ARMADEUS_SERVO_DRIVER pourra prendre trois valeurs : - y : Le code correspondant sera compilé et lié au sein du noyau. - m : Un module sera créé dans ce cas. - non définie : Le code est ignoré. Dans notre cas, un module sera créé, donc CONFIG_ARMADEUS_SERVO_DRIVER=m. Makeétend cette variable et la ligne devient obj-m += servo.o.obj-m est une directive Kbuild qui signifie qu’un moduleservo doit être compilé à partir d’un fichierservo.c. Comme pour le fichier Kconfig, ce fichierMakefile doit être référencé par celui du répertoire parent par :

obj-$(CONFIG_ARMADEUS_FPGA_DRIVERS)     += dev_tools/ others/ POD/ wishbone_example/ armadeusservodriver/

Lorsque les directives obj-y ou obj-m contiennent des répertoires dans leurs membres droits, Kbuild explorera ces répertoires à la recherche de fichiers Makefile. Ainsi, grâce au toolchain et à Kbuild, une simple dizaine de lignes suffisent à définir la configuration et la compilation du pilote du contrôleur de servos. Maintenant que le module peut être compilé facilement, passons à son contenu : du code noyau.

1.2 Architecture et description du pilote

Le pilote assure la liaison bidirectionnelle entre l’application en mode utilisateur et le matériel. Du côté matériel, les fonctions readw() et writew() sont utilisées pour communiquer avec le contrôleur FPGA. Par ailleurs, le système de fichiers virtuel sysfs permet à une application en mode utilisateur d’effectuer des accès au pilote en lecture et en écriture via certains fichiers dans /sys créés par le pilote. Du point de vue du pilote, le contrôleur de servos FPGA est constitué d’un périphérique de type contrôleur principal et de 32 périphériques indépendants de type servo. Le périphérique principal prend en charge les propriétés globales que sont l’identifiant magique, le numéro de version du firmware, la remise à zéro et l’activation globale des 32 servos. Les périphériques servos gèrent les propriétés de chaque servo individuellement, qui sont : – la position de consigne ; – la position courante ; – le décalage de position ; – la butée logicielle basse ; – la butée logicielle haute ; – l’état d’activation ; – la vitesse des mouvements.

Retrouvez cet article dans : Open Silicium 3

undefined