Depuis l’arrivée du Raspberry Pi, j’ai eu envie d’installer Xenomai dessus pour me faire une idée de ses capacités dans le domaine temps réel. J’ai trouvé enfin le temps de m’en occuper ; voici un petit compte-rendu de l’installation.
Archives de la catégorie ‘Temps-réel’
J’ai abordé dans plusieurs articles (Xenomai sur Pandaboard, GPIO, Pandaboard et temps réel – Gestion des interruptions, La Pandaboard au poteau de torture – Timers Xenomai…) la question des latences maximales de Xenomai. Mais il est aussi intéressant de connaître et de configurer correctement la latence minimale.
La nouvelle version stable de Xenomai a été annoncée mardi par Gilles Chanteperdrix, il s’agit de la 2.6.1. On peut la télécharger ici. La compilation se fait sur le même principe que la version précédente, j’en ai déjà parlé dans cet article (sur Pandaboard) et dans celui-ci (sur PC). Je l’ai testée depuis deux jours sur Pandaboard.
Dans les précédents articles nous avons observé les limites de performance des timers Linux et Linux-rt sur une Pandabaord. Cette fois nous allons comparer ces résultats avec ceux que nous obtenons sous Xenomai.
Aurons-nous une meilleure stabilité des tâches périodiques ?
J’ai poursuivi les tests entamés dans l’article précédent de cette série, en laissant tourner pendant de longues durées un programme qui vérifie les fluctuations d’un timer logiciel à 100 micro-secondes. Voici quelques résultats obtenus sur la Pandaboard avec un noyau Linux 3.4.1 en version « vanilla » pour commencer, puis avec l’application d’un patch Linux-rt par la suite.
Dans le précédent article, nous avons examiné les possibilités de fonctionnement en continu d’une carte Pandaboard. Il s’est avéré que l’ajout d’un dissipateur thermique était indispensable pour maintenir un régime permanent à 100% du CPU.
Nous allons dans cet article observer le comportement d’un timer logiciel Linux sur cette carte sous une haute charge – tant logicielle qu’en interruptions – et mesurer les fluctuations maximales.
Je conseille souvent à mes clients de faire des tests de longues durées pour leurs systèmes temps réel avec des charges extrémement élevées, tant en interruptions qu’en processus, afin de valider la bonne tenue de l’architecture choisie. Il s’agit d’aller sensiblement au-delà de la charge prévue lors de la conception, et de laisser le système en fonctionnement le plus longtemps possible (plusieurs jours au minimum) afin de pouvoir observer les cas rares où les latences maximales sont atteintes.
Nous allons réaliser ce genre de torture test pour la Pandaboard.
Suite à un petit commentaire de Yoann Sculo concernant l’avant dernier article, j’ai eu envie de détailler un peu le fonctionnement du multiplexage des GPIO sur un processeur OMAP (comme celui de la Pandaboard), et les paramètres auxquels nous pouvons avoir accès par l’intermédiaire du système de fichiers debugfs.
Nous avons vu dans les articles précédents comment écrire sur une broche de sortie du connecteur d’extension de la Pandaboard depuis l’espace utilisateur, puis depuis le kernel. Nous avons également réussi à lire l’état de broches GPIO d’entrée. Cette fois, nous allons améliorer cette lecture en gérant l’occurence d’événements par l’intermédiaire d’interruptions.
Dans les articles précédents, nous avons vu comment accéder aux sorties GPIO de la Pandaboard depuis l’espace utilisateur (premier article) et depuis l’espace noyau (second article) Linux et Xenomai. Nous allons maintenant nous intéresser à la lecture de l’état des entrées GPIO.
