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.
Archives de la catégorie ‘Embarqué’
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.
Nous avons réussi dans l’article précédent à compiler les bootloaders X-loader et U-boot, ainsi qu’un noyau Linux pour la carte Pandaboard. Le démarrage du système se déroulait très bien, le chargeur X-loader s’initialisant d’abord, puis passant le contrôle à U-boot. Ce dernier plaçait l’image du noyau Linux en mémoire et lui transmettait l’exécution.
Nous avons observé que le noyau commençait par s’auto-décompresser en mémoire, puis détectait les éléments matériels du système, initialisait tous ses composants logiciels, montait la seconde partition de la carte flash à la racine du système de fichiers, et cherchait – en vain – à démarrer le premier processus du système, le processus init.
J’ai enfin trouvé le temps de faire un essai d’installation d’un système totalement personnalisé (très incomplet pour le moment) sur ma carte Pandaboard reçue depuis quelques semaines.
Le 11 avril dernier Thomas Gleixner a publié un nouveau patch pour le projet Linux Preempt RT. Celui-ci s’applique sur les noyaux de la branche long terme 2.6.33 (linux 2.6.33.9 en particulier). Ce patch implémente des améliorations par rapport au précédent, sans ajouter de véritables nouveautés. Il peut toutefois être intéressant de le mettre en œuvre et de le tester pour vérifier si les performances temps-réel d’un système sont améliorées.
(Cet article est un extrait de la version préparatoire de mon livre « Applications temps-réel avec Linux » en cours d’écriture)
Lorsque l’on teste le fonctionnement d’un système temps-réel Posix, en particulier les priorités entre les différentes tâches, il est fréquent d’utiliser un petit programme comme celui-ci :
boucle-15s.c :
#include <unistd.h>:
int main(void)
{
alarm(15);
while(1)
;
}
Le nouveau noyau Linux 2.6.38 est disponible depuis ce matin.
Je l’ai testé sur la carte IGEPv2 (processeur Arm) que j’utilise pour mes formations « Linux temps-réel et embarqué ». Il fonctionne parfaitement (fichier de configuration kernel).
(Cet article est un extrait de la version préparatoire de mon livre « Applications temps-réel avec Linux » en cours d’écriture)
Économie ou performance : arbitrage pour le temps-réel embarqué (Partie 2)
Nous avons examiné dans le précédent billet le fonctionnement des governors, les modules qui permettent au noyau Linux de régler la fréquence du processeur, en tenant compte de certaines heuristiques (privilégier les économies d’énergie, la performance du calcul, ou s’adapter automatiquement).
Lire la suite de cette entrée »
(Cet article est un extrait de la version préparatoire de mon livre « Applications temps-réel avec Linux » en cours d’écriture)
Économie ou performance : arbitrage pour le temps-réel embarqué (Partie 1)
Sur la plupart des systèmes interactifs, la charge du processeur varie en permanence entre des états d’intense activité (calcul, compilation, compression, encodage, etc.) et des périodes de repos durant lesquelles aucune opération n’a lieu, jusqu’à la prochaine sollicitation provenant de l’utilisateur.