L’installation de la dernière version de Xenomai (2.6.0) sur une carte Pandaboard ne devrait en principe pas présenter de difficultés. En principe. Mais en pratique je crois être tombé dans tous les pièges possibles avant d’arriver à faire fonctionner correctement mon système. Je vous fais grâce de mes mésaventures, et voici donc un petit résumé des opérations à réaliser pour pouvoir disposer de temps-réel strict sur la carte Pandaboard.
Archives de la catégorie ‘Embarqué’
Cet article est extrait de la version préparatoire de mon livre « Solutions temps-réel sous Linux » (parution envisagée au début 2012).
J’ai eu envie de mettre en évidence la différence de comportement entre un noyau préemptible (avec l’option CONFIG_PREEMPT activée durant sa compilation) et un noyau non-préemptible classique. Toutefois, cette mise en évidence n’est pas très simple, car elle concerne précisément des cas rares et difficiles à reproduire.
Nous allons nous intéresser à une interruption déclenchée par le port de communication série RS-232. Nous allons envoyer un caractère sur une liaison série à destination d’un système Linux sur lequel fonctionnera un processus temps-réel qui renverra le même caractère dans l’autre sens sur la même liaison série.
Depuis quelques années il existe des versions spécifiques du noyau Linux dont la maintenance est planifiée pour une durée plus longue que les autres. Il s’agit des longterm kernels. La semaine passée Greg Kroah-Hartman qui assure une part importante de la maintenance des noyaux stables et longterm a proposé d’établir de nouvelles règles de fonctionnement pour ces noyaux. La discussion est encore active, mais quelques remarques peuvent déjà être faites.
Suite à une question posée par Chriss en commentaire d’un précédent article, j’ai eu envie de revenir rapidement sur un élément essentiel pour la mise au point d’un système embarqué : le signe de vie. Il s’agit simplement de faire effectuer par le système une tâche régulière, avec un effet facilement observable par l’utilisateur, afin de s’assurer du bon fonctionnement global du dispositif. Ce signe de vie peut prendre diverses formes : signal électrique visible à l’oscilloscope sur une broche de test de la carte, trame vide émise régulièrement sur un port réseau, compteur incrémenté périodiquement dans une zone de mémoire partagée, etc. Le signe de vie le plus simple à mettre en oeuvre sur un système embarqué est le clignotement d’une LED.
Nous avons compilé dans le précédent article une toolchain embarquée native, c’est-à-dire la chaîne de compilation qui pourra s’exécuter sur une cible embarquée (à processeur Arm dans notre cas) et qui sera susceptible de produire du code pour ce même processeur Arm.
Nous allons valider le fonctionnement de cette chaîne de compilation en lui soumettant un gros morceau de code : le noyau Linux.
Certains projets posent des problèmes difficiles à surmonter lorsqu’il s’agit de les cross-compiler pour une plate-forme différente du poste de compilation. Citons par exemple Apache ou PHP que nous avons laborieusement réussi à cross-compiler dans les quatrième et cinquième articles de notre série « Construire son système personnel sur Pandaboard« . Il peut être utile de disposer sur la cible embarquée d’une chaîne de compilation native c’est-à-dire capable de produire du code exécutable pour le processeur sur lequel la compilation a eu lieu.
Nous allons mettre ceci en oeuvre sur une carte à processeur Arm à l’aide de Buildroot.
Nous avons installé dans l’article précédent un serveur Apache sur une carte Pandaboard en le cross-compilant – non sans mal. En effet, ce serveur n’est pas particulièrement prévu pour être compilé sur un système embarqué.
Nous allons aborder une seconde étape assez épique : la compilation de PHP. Comme on peut s’y attendre, il n’est pas non plus prévu pour être facilement cross-compilé (après tout, un éléphant sur un système embarqué…) et nous devrons emprunter des voies détournées pour atteindre notre but !
Après avoir obtenu un système minimal sur notre carte Pandaboard (voir les articles 1, 2 et 3), nous allons pouvoir l’enrichir un peu, en commençant par un serveur HTTP plus puissant que le précédent : Apache.
Lorsqu’on entame un projet de développement sur Linux embarqué, il est nécessaire de disposer d’un cross-compiler (souvent traduit un peu maladroitement par le terme « compilateur croisé » ) c’est-à-dire un compilateur fonctionnant sur la machine de développement (appelé poste hôte) capable de produire des fichiers exécutables qui pourront s’exécuter sur le processeur du système embarqué (la cible). Ce compilateur est généralement mis à disposition (gratuitement ou non) par le fournisseur de la carte embarquée. Toutefois, il y a de nombreux cas où l’on aimerait pouvoir choisir sa propre chaîne de compilation, pour des raisons de compatibilité entre outils ou entre bibliothèques par exemple.
La génération du cross-compiler a longtemps été une opération compliquée, longue et fastidieuse, mais de nos jours plusieurs projets encadrent cette étape préliminaire et simplifient grandement la vie des développeurs pour l’embarqué.
Dans les articles précédents (1 et 2) nous avons réussi à installer un système minimal sur notre Pandaboard. Toutefois, nous n’avons pour le moment pas abordé le problème du réseau. Je vous propose cette semaine d’initialiser l’interface Ethernet et d’installer quelques services, par exemple pour se connecter à distance ou transférer des fichiers sur la carte.
