Ficheux Pierre

La carte Raspberry Pi (RPi) est devenue célèbre grâce à sa simplicité d'utilisation. En effet l'installation se limite à l'insertion une carte SD coûtant quelques euros et contenant l'image de votre système d'exploitation favori (Linux, RTEMS, FreeRTOS, …). Plusieurs autres cartes utilisent ce principe mais le développeur exigeant et expérimenté est habitué à disposer d'un logiciel d'amorçage ou « bootloader » installé sur la carte. Dans cet article nous allons décrire l'utilisation du bootloader U-Boot puis nous verrons son installation sur la carte RPi.

Le système d'exploitation Android a su conquérir en quelques années le monde de la téléphonie mobile. Son architecture est proche d'un système GNU/Linux même s'il existe des différences notables. Si l'on se place du coté applicatif, sa simplicité d'utilisation a bien entendu tenté les industriels car le coût de développement d'une application graphique Android est souvent moins élevé que dans le cas de GNU/Linux avec Qt. Dans un avenir proche, Android pourrait donc être la référence des systèmes « Linux embarqué » avec IHM.Dans cet article nous avons donc évalué dans l'environnement Android les différentes fonctionnalités utilisées sous GNU/Linux dans un cadre industriel, en particulier l'approche temps réel en utilisant les patch PREEMPT-RT et Xenomai. La majorité des tests a été réalisé sur x86 (Atom) avec Android-x86.

La carte Rasperry Pi (RPi) est devenue très célèbre dans la communauté Linux. Les distributions Linux disponibles pour cette carte n'ont cependant rien à voir avec des versions « embarquées », en l'occurrence Debian (Raspbian) ou ArchLinux. Dans cet article, nous décrirons comment produire une distribution « Linux embarqué » pour RPi en utilisant les outils les plus célèbres, soit Buildroot et OpenEmbedded.Les sources des exemples sont disponibles sur http://pficheux.free.fr/articles/lmf/rpi_distrib.

Dans le numéro 151 de GLMF, Julien Delange a décrit l’utilisation de RTEMS dans le cas d’une cible x86. Il a de plus explicité les principales étapes pour la production de la chaîne de compilation croisée, la compilation de RTEMS et l’utilisation du réseau. Le présent article peut être considéré comme une « suite » puisque nous décrirons le cas d’utilisation de RTEMS sur une carte embarquée FriendlyARM Mini2440. Outre cela, nous introduirons la notion de pilote RTEMS en proposant l’exemple du contrôle des LED de la Mini2440.

Les FPGA (Field Programmable Gate Array) sont de plus en plus présents dans les systèmes embarqués modernes. Ils permettent de combiner les performances du matériel avec la souplesse de programmation du logiciel. Dans cet article, nous allons présenter un produit développé par la société californienne KNJN (http://www.knjn.com). Cette carte d’interface générique permet de construire des fonctions applicatives dédiées grâce au FPGA Xilinx Spartan 2 présent sur la carte. Au fur et à mesure du déroulement de l'article, nous verrons comment mettre en place un environnement de développement GNU/Linux alors que le constructeur fournit uniquement un support Windows.

Les pilotes réseau ou network drivers constituent une catégorie majeure dans le développement noyau Linux. La structure de ces pilotes est assez particulière par rapport aux pilotes en mode caractère ou bloc. Dans cette article, nous aborderons les principales étapes de la création d’un pilote réseau. Fidèle à notre réputation pragmatique, nous baserons la démonstration sur le développement d’un exemple complet - mais virtuel - d’interface réseau nommée fake0(en référence à eth0, l’interface réseau habituellement utilisée sous Linux).En plus de cet exemple, nous décrirons les principes de développement d’un pilote basé sur les deux principaux bus de communication actuels, soit PCI et USB. Pour ces deux bus, un squelette de pilote fonctionnel sera fourni.Les exemples liés à cet article sont disponibles sur http://pficheux.free.fr/articles/lmf/kernel_programming/net_drivers.

Le projet Xenomai (http://www.xenomai.org) propose une extension du noyau Linux et permet de développer des applications « temps réel dur ». Outre les applications, l'utilisation de périphériques spéciaux nécessite de développer des pilotes temps réel en utilisant RTDM (Real Time Driver Model). En nous basant sur trois exemples concrets, nous décrirons dans cet article les principaux éléments de cette API tant du côté du développement noyau que de celui de l'accès au pilote depuis l'espace utilisateur. Les sources des exemples sont disponibles sur http://pficheux.free.fr/articles/lmf/kernel_programming/rtdm_drivers.

Dans le numéro précédent, nous avons évoqué des méthodes de mise au point à distance pour un système embarqué en utilisant le débogueur GDB couplé à un agent distant comme gdbserver ou l’option KGDB du noyau. Les problèmes graves de fonctionnement (crash du noyau ou d’une application) nécessitent en effet l’utilisation d’un débogueur. Cependant, il est souvent nécessaire d’obtenir des informations sur le comportement du système en fonctionnement, ce qui correspond alors à de l'instrumentation. Ainsi, il est possible de prévenir les problèmes en amont ou bien d’assister le concepteur dans le choix de solutions plus optimisées.

La mise au point et l’optimisation sont des aspects fondamentaux du développement de logiciels industriels. En effet, les contraintes de qualité de fonctionnement y sont bien plus importantes que dans le cas des logiciels généralistes. Alors qu’un outil classique est utilisé au maximum quelques heures par jour, le logiciel embarqué doit fonctionner 24h/24, et le redémarrage du système est peu fréquent. La moindre fuite de mémoire ou écrasement de mémoire alloué, tolérables sur un logiciel généraliste, devient une véritable catastrophe dans le cas d’un logiciel embarqué.