Ingénierie et formations sur les systèmes libres
Le nouveau Linux Magazine Hors Série (numéro 75) vient de paraître aujourd’hui.
Il s’agit d’un guide sur le Raspberry Pi, « niveau avancé ».
J’ai eu le plaisir de signer quatre articles de ce numéro :
Les sources des exemples, scripts, etc. se trouvent sur mon dépôt GitHub.
Depuis une quinzaine de jours, nous pouvons disposer d’une nouvelle version du Raspberry Pi nommée « Model B+« . La plupart des critiques que l’on faisait au modèle précédent ont été prises en considération dans cette nouvelle mouture.
On m’a demandé à plusieurs reprises comment compiler les modules pour le noyau du Raspberry Pi que j’ai présenté dans différents articles ou ceux que je propose en illustration de mes sessions de formation. J’emploie généralement une cross-compilation, c’est à dire un compilateur spécifique installé sur un PC pour produire du code pour le processeur à cœur ARM du Raspberry Pi. J’ai déjà présenté cette solution dans plusieurs articles (par exemple celui-ci, celui-ci ou la série d’articles pour Linux Magazine).
Il existe toutefois une autre solution plus simple : la compilation native en utilisant une distribution courante pour Raspberry Pi.
Lire la suite de cette entrée »
Un lecteur m’a interrogé par mail pour savoir comment mesurer la fréquence d’un signal reçu en entrée sur une broche GPIO du Raspberry Pi. Je lui ai répondu que le plus simple est de mesurer le temps s’écoulant entre deux interruptions successives déclenchées par des fronts montants et de calculer l’inverse. J’ai voulu vérifier que cela fonctionnait, et ai écrit un petit driver pour ce faire.
J’ai le plaisir de voir mon article « Optimisation du temps de boot d’un système embarqué » faire la couverture d’Open Silicium numéro 9.
[EDIT 2017/01] L’article est dorénavant disponible au format PDF.
Les fichiers accompagnant les expérimentations de l’article sont disponibles dans cette archive ou individuellement ci-dessous.
Le Raspberry Pi ne comporte pas de bouton « reset » – ni d’ailleurs aucun autre bouton – et la plupart du temps on le redémarre soit logiciellement (en utilisant la commande reboot par exemple) soit électriquement en le débranchant puis le rebranchant.
Il est pourtant pratique de disposer d’un bouton de réinitialisation hard lors de développement de modules kernel susceptibles de geler le système en cas d’erreur ou si des tâches temps réel se mettent à boucler frénétiquement.
Il y a un quart d’heure de cela, un livreur a déposé sur mon bureau deux exemplaires (pour limiter les frais de port) d’un nouveau terrain de jeu pour hackers de Linux embarqué : le BeagleBone Black. Je vous propose un petit tour de piste rapide…
Nous avons déjà vu dans plusieurs articles qu’il était facile de manipuler les GPIO sous Linux depuis l’espace utilisateur avec l’interface /sys. Jusqu’à présent je ne m’étais intéressé qu’aux lectures et écritures, mais il est également possible de faire des attentes passives de changement d’état avec select() ou poll(). Voyons-en une mise en œuvre sur le Raspberry Pi.
J’ai continué mes expériences avec la gestion d’interruptions par un driver RTDM-Xenomai sur les ports GPIO d’un Raspberry Pi que j’avais entamées dans le précédent article. Jusqu’alors j’avais pu déterminer « à l’œil » en utilisant un oscilloscope que le temps de réponse était de l’ordre de 3 à 4 micro-secondes, avec des pointes régulières à 8 micro-secondes environ. Ce sont justement ces pointes – et celles plus longues – qui m’intéressent et j’aimerais en avoir un aperçu plus complet. Mon objectif est de pouvoir déterminer le temps de réponse que peut garantir dans le pire des cas un système temps réel construit sur Xenomai avec l’API RTDM.
