Nous avons examiné récemment le temps de réveil d’une tâche endormie dans un appel-système. Je voulais compléter cette expérience en m’intéressant au passage d’un signal depuis le noyau vers l’espace utilisateur. Nous allons plus particulièrement mesurer le temps d’activation d’un processus lorsqu’un signal temps réel lui est envoyé depuis le noyau.
Archives de la catégorie ‘Embarqué’
Une application classique a souvent besoin de réaliser des appels système pour accéder à des ressources matérielles ou logicielles contrôlées par le noyau. Que l’on veuille écrire dans un fichier, communiquer sur une socket, accéder à un port d’entrée-sortie, obtenir un supplément de mémoire ou même simplement lire notre numéro de processus (pid), il faudra réaliser un appel système. Mais combien de temps durera-t-il ?
J’ai remarqué une question récurrente, tant durant mes sessions de formation sur Linux industriel qu’au cours de prestations d’ingénierie concernant des systèmes temps-réel ou embarqués : « Quelles sont les options du noyau qui influent sur [un sujet donné] ? » Le sujet en question a généralement trait aux mécanismes d’ordonnancement, à la vitesse de boot, à la taille du code produit, etc.
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.
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 !
