En complément de l’article sur la préparation d’une toolchain avec Buildroot pour Raspberry Pi, et comme Thomas Petazzoni (dont je vous recommande le blog) l’a suggéré en commentaire, on peut préférer construire la chaîne de compilation avec crosstool-NG. Celle-ci offre plusieurs avantages : la toolchain sera relogeable (déplaçable où l’on souhaite dans l’arborescence sans imposer d’emplacement absolu) et elle pourra s’appuyer sur la bibliothèque GlibC ou la eGlibC plutôt que la bibliothèque uClibC. J’ai choisi ici de sélectionner la bibliothèque eGlibC, plus adaptée à un environnement embarqué.
Archives de la catégorie ‘Embarqué’
En réponse à un commentaire de Ugo concernant l’article sur Xenomai pour Raspberry Pi, voici les étapes pour créer rapidement la toolchain avec Buildroot.
Lire la suite de cette entrée »
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.
J’ai reçu il y a quelques semaines un exemplaire du fameux Raspberry Pi, une carte à processeur Arm à faible coût (environ 33 £, soit 42 €). Je l’ai exploré en détail pour rédiger quelques articles à paraître prochainement dans Gnu/Linux Magazine France sur la création d’un système « from scratch » pour le Raspberry Pi.
Il existe déjà plusieurs distributions prêtes à l’emploi (ArchLinux, QtOnPi, etc.) mais l’une d’elles semble plus complète que les autres, il s’agit de Raspbian Wheezy un projet basé sur la distribution Debian Testing actuelle portée sur Raspberry Pi. Je l’ai parcourue rapidement pour me faire une idée de ses caractéristiques.
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.