Dans le noyau 3.18 un nouveau système de fichiers est apparu : overlayfs. Je l’avais déjà utilisé à maintes reprises sur des systèmes embarqués, mais cela nécessitait jusqu’alors l’ajout de patches supplémentaires. J’ai eu envie de vérifier si cette fonctionnalité à présent disponible dans le nouveau noyau mainline fonctionnait comme je la connaissais auparavant.
Archives de la catégorie ‘Embarqué’
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 :
- SPI et Raspberry Pi,
- Dialogue en SPI avec un MSP 430,
- Communiquer en i²c avec un capteur de température,
- Raspberry Pi et temps réel.
Les sources des exemples, scripts, etc. se trouvent sur mon dépôt GitHub.
Je viens de publier sur GitHub un petit projet nommé Spi-tools, regroupant deux utilitaires pour communiquer sous Linux en utilisant le protocole SPI. Ce projet a été écrit pour illustrer le fonctionnement d’un lien SPI entre un microprocesseur sous Linux (Raspberry Pi en l’occurrence) et un microcontrôleur (T.I. MSP430), mais il doit pouvoir s’appliquer à la plupart des besoins de configuration et communication en SPI sous Linux.
Lire la suite de cette entrée »
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.
Il m’arrive fréquemment de développer de petits drivers Linux pour des clients afin de gérer des périphériques spécifiques. Ceci la plupart du temps dans un contexte de système embarqué.
Pour la construction d’un système Linux embarqué, ma préférence va généralement à l’environnement de production Buildroot. Celui-ci est plus léger (mais moins riche, il est vrai) que son principal concurrent Yocto.
La documentation de Buildroot est claire et bien fournie, toutefois il n’est pas très facile d’y trouver comment intégrer un driver Linux spécifique, développé pour une cible donnée. Voici donc un petit rappel des fichiers à ajouter ou modifier.
Lire la suite de cette entrée »
J’ai eu le plaisir aujourd’hui de présenter une conférence au séminaire Captronic « Du microcontrôleur au microprocesseur – Quelle architecture pour quel projet ? » à la C.C.I Nord Isère de Villefontaine.
Le contenu de ma présentation est disponible ici. J’avais déjà abordé ce thème en novembre dernier à Lille, mais j’ai pu enrichir la présentation avec divers approfondissements sur Linux embarqué, et quelques démonstrations de fonctionnement.
En outre, nous avons présenté avec mon ami François Beaulier une architecture hybride composée d’un microcontrôleur (STM32) couplé à un system-on-chip (Raspberry Pi), communiquant en utilisant une bibliothèque de notre création nommée LxMCU.
Cette bibliothèque libre, est prévue pour faire communiquer un système Linux (« Lx ») avec un microcontrôleur (« MCU ») en utilisant un lien SPI (ou I²C prochainement) et une GPIO. Elle sera bientôt mise en ligne.
PS: je n’ai malheureusement pas pu trouver le temps de rédiger d’article sur ce blog depuis bien longtemps, j’espère pouvoir y remédier dans les semaines à venir.
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.
- chronoboot.c : le programme utilisé sur le système de mesure,
- up-gpio.c : le premier programme de test,
- mount-sys-fs-up-gpio.c : le deuxième programme de test,
- mount-sys-fs-up-gpio-init.c : le troisième programme de test,
- config-01, config-02, config-03, config-04, config-05, config-06, config-07, config-08, config-09, config-10, config-11, config-12, config-13, config-14 : les fichiers de configuration du noyau correspondant aux différentes étapes d’optimisation,
- message-logo.ppm : le message affiché pendant pendant le boot à la place du manchot Tux habituel,
- RPI.jpg : la photo du Rasberry Pi que j’affiche à la fin du boot.
Je participe ce matin aux conférences « Les matinales de l’embarqué » du salon Enova Paris.
Je vais y présenter un tour d’horizon des cartes pour Linux embarqué disponibles « sur étagère » (Raspberry Pi, CubieBoard, BeagleBoard, OLinuXino, etc.) en essayant de dégager quelques critères de choix et en fournissant un aperçu des possibilités de ces Single-Board-Computers.
Le contenu de ma présentation est disponible ici.