TP de Temps Réel : Prise en main d'une cible embarquée sous Linux

Transcription

1 TP de Temps Réel : Prise en main d'une cible embarquée sous Linux ENSIBS 2 eme année, Spécialité Informatique 1 Objectif Ce TP fais partie des TP de Temps-Réel et vise à prendre en main une cible embarquée. Cette cible fonctionne sous Linux. L'objectif de ce TP est de prendre en main la conguration d'un système Linux Embarqué basé sur uclinux. Il s'agira donc de congurer le noyau linux, mais aussi les utilitaires présents sur le système déployé. Dans une deuxième partie vous réaliserez un driver pour le robot wibot. 2 Élements fournis 2.1 La carte NEEK Linux sera déployé sur une carte NEEK (NIOS II Embedded Evaluation Kit). Le système de compilation choisi est un uclinux. Celui-ci vient sous la forme d'une archive complète dans un répertoire nommé nios2-linux. Il contient plusieurs sous-répertoires dont deux qui nous intéressent plus particulièrement : linux-2.6 contient les sources du noyau, c'est dans ce répertoire que seront plus tard écrits les drivers uclinux-dist contient les chiers nécessaires à la compilation de la distribution uclinux complète, c'est depuis ce répertoire que l'on lancera les commandes de conguration et de compilation. Les autres répertoires contiennent les outils nécessaires à la compilation ainsi que les librairies. Pour faire tourner linux sur la carte NEEK et proter un maximum de ses possibilités, il nous faut utiliser une conguration du FPGA sur laquelle le processeur NIOS2 est conguré adéquatement et est assorti de contrôleurs qui permettent le pilotage des éléments de la carte et pour lesquels des drivers Linux existent. Cette conguration s'appelle neek_ocm_spi_mmu elle contient les drivers suivants : des GPIO standards, supportés par Linux et placés sur une LED ainsi que sur les ports I2C et SPI un framebuer altfb un touchscreen ADS7846 sur bus SPI un contrôleur PS/2 Altera UP PS/2 un contrôleur Ethernet (réseau) fourni par OpenCore 2.2 Le Robot Le robot utilisé dans ce TP est une base wibot sur laquelle a été branchée une carte NEEK. Le robot wibot possède 4 roues, chaque côté est propulsé de manière indépendante ce qui permet de réaliser des mouvements (un peu comme un char). Le robot est connecté sur le bus i2c de la carte NEEK et se trouve à l'adresse 0x51. 1

2 On peut lui envoyer une commande, on lui envoie alors le numéro du registre dans lequel écrire, puisqu'il n'y a qu'un registre, c'est toujours 0x00. Ensuite, on lui envoie un octet pour le moteur gauche et un octet pour le moteur droit sous la forme proposée à la gure 1. B7 B6 B5 B4 B3 B2 B1 CTRL DIR VITESSE B0 1 : boucle fermee 0 : boucle ouverte 1 : marche avant 0 : marche arrirere Valeur de la vitesse sur 6 bit en boucle ouverte : valeur fournie aux moteurs en boucle fermee la valeur correspond au nombre de ticks par periode (10ms) Figure 1 Octet de commande pour chaque moteur On peut aussi récupérer des informations, on lui envoie un octet contenant l'unique registre (0x00) et sans faire de stop, on demande la lecture de 15 octets qui contiennent les informations en provenance du robot. La fonction wb_ctrl_read contient le code permettant d'interpréter ces 15 octets et de les placer dans la structure robot_data. 3 Conguration de uclinux 3.1 Conguration et exécution d'un système de base Dans cette première partie du TP vous allez réaliser la première conguration d'un système Linux, et l'exécuter Conguration du système Vous lancez la conguration à l'aide de la commande : make menuconfig Lancée depuis le répertoire uclinux-dist. Un premier menu vous est présenté, dans lequel vous devez choisir la cible pour laquelle vous compilez (Altera Nios2 ) puis vous choisissez ce que vous allez modier (Customize Kernel Settings). Note : Pour pouvoir compiler les sources du noyau, il est nécessaire de choisir le bon GPIO dans NiosII Conguration->Additional NiosII Device Drivers. Ainsi que la bon contrôleur Ethernet dans Device Drivers->Network Device Support->Ethernet 10/ Exécution Pour pouvoir exécuter le système, il faut tout d'abord charger le chier de conguration (.sof) dans le FPGA. L'exécution du système se fait ensuite en chargeant directement à l'aide de nios2-download l'image du noyau qui se trouve dans le répertoire images/zimage. Une fois que vous avez lancé Linux, vous devriez le voir booter sur un terminal attaché à travers le JTAG (nios2-terminal). Quand vous arrivez à la ligne de commande, vous pouvez utiliser ifcong pour congurer votre carte réseau et communiquer avec votre PC (vous pouvez utiliser un telnet pour vous connecter à la carte. 2

3 3.2 Pilotage d'une LED sur la carte Vous allez congurer le noyau Linux pour qu'il supporte la LED qui est congurée dans l'application. Pour cela, il faut tout d'abord que le GPIO soit bien conguré. Ensuite, il vous faudra congurer la LED dont le menu se trouve dans Device Drivers->LED Support. Une fois la LED congurée, vous pourrez la contrôler en accédant au chier brightness correspondant. En eet, le driver pour les LED présent dans Linux crée des chiers dans le sysfs pour contrôler celles-ci. Les diérentes LED se trouvent dans le répertoire /sys/class/led. Lorsque vous aurez vérié que la LED peut-être pilotée à l'aide d'un programme de l'espace utilisateur, vous retournerez dans le menu de conguration pour congurer la LED avec le LED Heartbeat Trigger. 3.3 Obtention du système complet L'objectif de cette partie du TP est de faire fonctionner l'ensemble des entrées-sorties de la carte et de congurer le serveur d'achage. Congurez les périphériques suivants Clavier FrameBuer TouchScreen Congurez tslib pour pouvoir exécuter ts_calibrate Lancez l'image Linux ainsi conguré et testez Nano-X Pour pouvoir congurer et compiler tslib, vous utiliserez un menu diérent de celui permettant de congurer le noyau. Ce second menu est le menu de conguration du système uclinux, il reprend les mêmes outils que les outils de conguration du noyau mais pour congurer l'espace utilisateur. Pour pouvoir accéder à ce menu, il faut sélectionner Customize Application/Library Settings dans le premier menu de conguration. 3.4 Conguration de l'i2c Cette question a pour but d'obtenir un système Linux proche de celui utilisé dans la seconde séance de TP. Il s'agit de vérier le le sous-système I2C fonctionne bien sur votre système. Activez le support de l'i2c à travers l'utilisation du driver dit bit-bang Vériez l'accès à l'eeprom en achant le contenu du chier eeprom situé dans le périphérique à l'adresse 0x50 du bus i2c numéro 1. 4 Réalisation d'un programme utilisant l'écran tactile Vous allez réaliser un programme fonctionnant dans l'espace utilisateur pour la gestion de l'écran tactile. Ce programme servira de base a la réalisation de votre interface utilisateur. Inspirez-vous du tutoriel fourni a l'adresse suivante : 5 Création d'un driver pour le wibot L'objectif de cette section est, en s'inspirant du driver pour le ltc4306, d'écrire le driver pour le wibot. L'écriture de ce driver se fera à partir du chier wb_ctrl.c qui vous est proposé. 5.1 Compilation et chargement du driver ltc4306 L'objectif de cette première étape est de prendre en main le processus de compilation. Le driver pour le ltc4306 se trouve dans un chier ltc4306.c. 3

4 Créez un répertoire wifibot dans le répertoire drivers d noyau et dans lequel vous placerez vos drivers Modiez les chiers Makefile et Kconfig du répertoire drivers an de permettre la compilation de votre driver Ecrivez le chier Makefile et le chier Kconfig à placer dans le répertoire wifibot et permettant la compilation du driver ltc4306 Compilez un module contenant le driver Lancez linux et vériez le fonctionnement du driver en ajoutant le périphérique ltc4306 à l'adresse 0x44. Une fois le driver chargé, la LED doit normalement s'allumer. 5.2 Initialisation du driver A l'aide du driver pour le ltc4306, complétez la partie i2c du driver pour le robot an que le driver puisse se charger dans le noyau. 5.3 Test du bon fonctionnement de l'i2c Pour tester le bon fonctionnement de l'i2c, on va lancer une commande au robot lors de l'enregistrement du driver. Les drivers pour l'i2c sont un peu particuliers en ce sens qu'on ne sait qu'au moment du fonctionnement combien de périphériques seront instanciés et quelles sont leurs adresses. En plus de la traditionnelle fonction d'initialisation du driver, il existe une fonction appelée lors de l'insertion du périphérique Envoi d'une commande au robot Identiez cette fonction dans le driver du ltc4306 et proposez une écriture pour le wibot lançant une commande de déplacement du robot. Les primitive que vous utiliserez pour envoyer une commande I2C au robot est : i2c_send. Testez votre fonction, lors de l'insertion du driver, vous devriez voir les roues tourner brièvement. Encapsulez l'envoi de la commande de déplacement dans une fonction utilitaire, vous nommerez cette fonction wb_ctrl_send Récupération des paramètres du robot Complétez la fonction wb_ctrl_read pour qu'elle remplisse la structure data en fonction de l'état actuel du robot. Pour compléter cette fonction, vous utiliserez la fonction i2c_transfer. Une fois la fonction remplie, les paramètres devraient s'acher. 5.4 Interface avec l'utilisateur via sysfs L'objectif d'un driver est normalement de permettre une interaction avec l'utilisateur. Dans le cadre de l'i2c, il est intéressant d'utiliser sysfs en lieu et place d'un device parce que ce dernier est dynamique. Sysfs permettra donc de créer un ensemble de noeuds du système de chiers pour chaque nouveau périphérique branché, les commandes sont alors disponibles dans un sous-répertoire de /sys/bus/i2c/devices/i2c-0/, dans le cas du robot puisqu'il est présent à l'adresse 0x51. 4

5 5.4.1 Gestion des déplacements Analysez le fonctionnement de set_speed et show_speed et complétez les pour permettre l'envoi d'une vitesse au robot et la lecture de la vitesse actuelle à l'aide des fonctions précédemment réalisées. Le format de la chaîne de caractère lue ou écrite dans le chier est le suivant : <vitesse gauche> <vitesse droite>. Un nouveau chier speed doit apparaître dans le répertoire du périphérique Récupération des paramètres d'odométrie Réalisez et enregistrez votre propre noeud dans l'arborescence sysfs pour récupérer les valeurs de l'odométrie. 5.5 Envoi périodique de la vitesse Vous avez remarqué que la commande en vitesse des roues du robot expire au bout de quelques milisecondes. Ce fonctionnement a été déni pour que le robot s'arrête en cas de dysfonctionnement de la carte de commande. Pour que le robot fonctionne en continu, il est donc nécessaire d'envoyer périodiquement une nouvelle commande de déplacement. Deux alternatives sont possibles : réaliser cet envoi périodique depuis le programme (depuis l'espace utilisateur) réaliser cet envoi dans le driver (depuis le noyau) Le noyau fournit la possibilité de réaliser des traitements périodiques au travers des timers. Il s'agit d'armer un timer qui exécute une fonction passée en paramètre de manière asynchrone, pour avoir un comportement périodique, le timer doit être réarmé depuis la fonction en question. Il vous est maintenant demandé de réaliser ce comportement périodique en utilisant un timer dans le driver. 5.6 Complétion de l'interface sysfs Implémentez le reste de l'interface entre le robot et le système de chier an de récupérer tous les paramètres depuis le robot. Pour cela, vu que la récupération des autres paramètres est similaire, vous utiliserez le mécanisme de macro oert par le pré-processeur C. 5