Blaess Christophe

Pour pouvoir comprendre ou écrire du code kernel, il est important de bien assimiler les échanges d'informations entre les différents composants du système. Nous examinerons dans cet article les communications et notifications entre l'espace utilisateur (les applications), le noyau Linux et le matériel sous-jacent.

Les outils et les méthodes de débogage pour l'espace applicatif Linux sont plutôt bien connus : de Valgrind à Strace/Ltrace en passant par GDB et toutes ses déclinaisons (DDD, Eclipse, Gdbserver), la documentation et les exemples sont très répandus. En ce qui concerne l'espace noyau, la pratique du débogage est beaucoup plus limitée. Pourtant, certains outils comme Ftrace permettent non seulement d'aider à la mise au point du code kernel, mais également d'analyser finement les comportements des tâches de l'espace utilisateur.

La carte Beaglebone Black offre de nombreuses entrées-sorties de types assez variés : série asynchrone, SPI, i²c, GPIO, etc. Dans cet article, nous allons nous intéresser aux broches GPIO et PWM. Suivant les distributions et les configurations du noyau, l'accès à ces entrées-sorties n'est pas toujours identique. Heureusement, un overlay du Device Tree nous simplifie la tâche.

En utilisant Linux, FreeBSD ou les outils Gnu, nous évoluons dans un écosystème peuplé d'une myriade de logiciels libres. Leur cohabitation n'est pourtant pas toujours évidente et l'intégration de code propriétaire, par exemple pour des projets industriels, est possible, mais demande certaines précautions d'usage.

Le faible coût du Raspberry Pi en fait une plate-forme de choix pour essayer de construire un petit cluster de compilation. La mise en œuvre est très simple, mais quelles en seront finalement les performances ?

La notion de temps réel est source de nombreuses controverses dans le monde du développement informatique. Je commencerai donc par qualifier les différentes classes de systèmes temps réel que l'on considère habituellement. Nous pourrons alors voir quelles sont les différentes solutions utilisables pour le Raspberry Pi et les niveaux de qualité que nous pouvons en attendre.

Le protocole i2c est le plus épuré des bus de communication entre un processeur et ses périphériques. Très simple à employer par le hobbyiste, nous allons le mettre en œuvre pour lire et programmer un capteur de température externe. Ce dernier ne nous servira qu'à titre d'exemple, tout périphérique i2c pouvant convenir.

La communication suivant le protocole SPI est très rapide, car les fréquences sont élevées et le dialogue totalement bidirectionnel « full-duplex ». Ce type de communication sert typiquement pour établir un lien entre un processeur et des périphériques (capteurs, etc.), mais on peut aussi l'utiliser pour dialoguer avec un microcontrôleur, comme nous le ferons dans l'article suivant.

Nous avons vu dans l'article précédent le support SPI proposé par le Raspberry Pi. Nous allons mettre ceci en pratique en communiquant avec un petit microcontrôleur simple à programmer : le MSP430...