Pour plus de détails…

Nous avons utilisé l’interface offerte par le noyau à travers le pseudo-système de fichiers /sys pour écrire un oscillateur s’exécutant dans l’espace utilisateur. Nos premiers essais réalisés avec un script shell souffrait d’une granularité excessive (plusieurs millisecondes) dans la gestion du temps. Un programme en C offrait une bien meilleure résolution (de l’ordre de la centaine de microsecondes). Ordonnancé en temps partagé les fluctuations étaient parfois très importantes (plusieurs millisecondes au pire). En utilisant l’ordonnancement temps réel souple de Linux, les fluctuations étaient beaucoup plus limitées.

Nous allons à présent réaliser les mêmes opérations depuis l’espace kernel, en écrivant d’abord des modules pour le noyau Linux standard puis en nous intéressant à un module pour Xenomai.

Timer du noyau Linux vanilla

Le noyau Linux classique nous offre une interface simple pour programmer des actions différées, et éventuellement répétitives, les structures timer_list. Notre premier exemple est construit autour de ces structures. Il programme l’exécution périodique d’une fonction toutes les millisecondes. Cette fonction basculera une sortie GPIO comme nous l’avons fait dans l’article précédent, mais en s’appuyant sur l’API kernel <linux/gpio.h>.

oscillateur-gpio-timer.c : 
#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/fs.h>
#include <linux/gpio.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/version.h>
#include <asm/uaccess.h>

static void timer_oscillateur(unsigned long);
static struct timer_list timer;

// 138 Broche 10 du port J3 (Expansion A) de la Pandaboard
#define GPIO_OSCILLATEUR 138

static int __init init_oscillateur (void)
{
  int err;

  if ((err = gpio_request(GPIO_OSCILLATEUR, THIS_MODULE->name)) != 0) {
    return err;
  }
  if ((err = gpio_direction_output(GPIO_OSCILLATEUR, 1)) != 0) {
    gpio_free(GPIO_OSCILLATEUR);
    return err;
  }
  init_timer (& timer);
  timer.function = timer_oscillateur;
  timer.data = 0;
  timer.expires = jiffies + HZ/1000;
  add_timer(& timer);

  return 0;
}

static void __exit exit_oscillateur (void)
{
  del_timer(& timer);
  gpio_free(GPIO_OSCILLATEUR);
}

static void timer_oscillateur(unsigned long unused)
{
  static int value = 0;
  gpio_set_value(GPIO_OSCILLATEUR, value);
  value = 1 - value;
  mod_timer(& timer, jiffies + HZ/1000);
}

module_init(init_oscillateur);
module_exit(exit_oscillateur);
MODULE_LICENSE("GPL");

Comme nous le voyons, la durée de ces timers s’expriment en jiffies, en ticks système, dont la fréquence est contenue dans la constante symbolique HZ. IL y a HZ ticks par seconde. En programmant un déclenchement dans HZ/1000 ticks, on diffère donc l’action d’une milliseconde.

Pour compiler ce code (et les modules suivants), il va falloir utiliser un fichier Makefile spécifique. Lors de l’invocation de la commande make, nous devrons indiquer:

• ARCH=arm pour la Pandaboard
• CROSS_COMPILE= suivi du préfixe à employer pour utiliser la chaîne de compilation croisée
• KERNEL_DIR= suivi du chemin d’accès au répertoire contenant les sources du noyau de la Pandaboard

À titre d’exemple, sur mon poste l’invocation de make se fait ainsi:

$ make ARCH=arm CROSS_COMPILE=~/cross-panda/usr/bin/arm-linux- KERNEL_DIR=~/Projets/Panda/linux-2.6.38.8
make -C /home/cpb/Projets/Panda/linux-2.6.38.8 SUBDIRS=/home/cpb/Documents/Livres/Articles/Blog/article-2012-05-14  modules
make[1]: entrant dans le répertoire « /home/cpb/Projets/Panda/linux-2.6.38.8 »
  CC [M]  /home/cpb/Documents/Articles/Blog/article-2012-05-14/oscillateur-gpio-timer.o
  CC [M]  /home/cpb/Documents/Articles/Blog/article-2012-05-14/oscillateur-gpio-hrtimer.o
  CC [M]  /home/cpb/Documents/Articles/Blog/article-2012-05-14/oscillateur-gpio-rtdm.o
  Building modules, stage 2.
  MODPOST 3 modules
  CC      /home/cpb/Documents/Articles/Blog/article-2012-05-14/oscillateur-gpio-hrtimer.mod.o
  LD [M]  /home/cpb/Documents/Articles/Blog/article-2012-05-14/oscillateur-gpio-hrtimer.ko
  CC      /home/cpb/Documents/Articles/Blog/article-2012-05-14/oscillateur-gpio-rtdm.mod.o
  LD [M]  /home/cpb/Documents/Articles/Blog/article-2012-05-14/oscillateur-gpio-rtdm.ko
  CC      /home/cpb/Documents/Articles/Blog/article-2012-05-14/oscillateur-gpio-timer.mod.o
  LD [M]  /home/cpb/Documents/Articles/Blog/article-2012-05-14/oscillateur-gpio-timer.ko
make[1]: quittant le répertoire « /home/cpb/Projets/Panda/linux-2.6.38.8 »
$

Il faut ensuite transférer le code sur la cible, s’y connecter et charger le module.

$ scp oscillateur-gpio-timer.ko root@192.168.5.152:/root
root@192.168.5.152's password:
oscillateur-gpio-timer.ko                                          100%   92KB  92.4KB/s   00:00
$ ssh root@192.168.5.152
root@192.168.5.152's password:
[Panda]# /sbin/insmod /root/oscillateur-gpio-timer.ko 
[Panda]#

Sur l’oscilloscope, nous voyons bien un signal carré sur la broche 10 du connecteur d’extension de la Pandaboard.

Pourtant ce signal est plutôt décevant. Nous avons demandé au noyau d’invoquer notre routine qui bascule l’état de la sortie toutes les millisecondes, et nous observons que les fronts successifs du signal sont espacés d’un peu moins de 4 carreaux, ce qui correspond à 8 millisecondes (réglage Sweep sur 2ms/division).

Ceci s’explique par le fait que l’API timer du noyau s’appuie sur des ticks système. Or nous ne connaissons pas leur durée. Mais la constante symbolique HZ doit nous renseigner. Elle est configurée lors de la préparation de la compilation du noyau et se trouve donc dans fichier .config associé. Par habitude, j’active toujours les options « Kernel .config support » et « Enable access to .config through /proc/config.gz » (menu General setup) des noyaux que je compile afin d’embarquer une copie du fichier de configuration sur la cible.

[Panda]# zcat config.gz | grep CONFIG_HZ
CONFIG_HZ=128
[Panda]#

Le tick du système est donc de 1/128 secondes, ce qui correspond à 7,81 millisecondes. Le noyau ne peut pas nous fournir de timer de résolution plus fine avec cette configuration.

Retirons notre module du kernel et essayons d’améliorer le fonctionnement.

[Panda]# /sbin/rmmod /root/oscillateur-gpio-timer.ko 
[Panda]#

Les timers de haute précision du noyau Linux

Heureusement des timers de meilleure précision sont disponibles sous Linux. Ils ont été développés par Thomas Gleixner et Ingo Molnar dans le cadre de Linux-rt puis intégrés dans le noyau standard aux alentours de la version 2.6.26. Il s’agit de l’API <hrtimer.h> utilisable si l’option « High Resolution Timer Support » du menu « Kernel Features » a été activée lors de la compilation du kernel.

Cette fois la définition des durées se fait en nanosecondes (ce qui ne signifie évidemment pas que le noyau soit capable de respecter la précision de la nanoseconde). En voici un petit exemple, où la période peut être précisée au chargement du module (en microsecondes pour conserver une meilleure lisibilité).

oscillateur-gpio-hrtimer.c :
#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/fs.h>
#include <linux/hrtimer.h>
#include <linux/gpio.h>
#include <linux/ktime.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/version.h>
#include <asm/uaccess.h>

static enum hrtimer_restart timer_oscillateur(struct hrtimer *);
static struct hrtimer htimer;

static int periode_us = 1000;
module_param(periode_us, int, 0644);
static ktime_t kt_periode;

// 138 Broche 10 du port J3 (Expansion A) de la Pandaboard
#define GPIO_OSCILLATEUR 138

static int __init init_oscillateur (void)
{
  int err;

  kt_periode = ktime_set(0, 1000 * periode_us);

  if ((err = gpio_request(GPIO_OSCILLATEUR, THIS_MODULE->name)) != 0) {
    return err;
  }
  if ((err = gpio_direction_output(GPIO_OSCILLATEUR, 1)) != 0) {
    gpio_free(GPIO_OSCILLATEUR);
    return err;
  }
  hrtimer_init (& htimer, CLOCK_REALTIME, HRTIMER_MODE_REL);
  htimer.function = timer_oscillateur;
  hrtimer_start(& htimer, kt_periode, HRTIMER_MODE_REL);

  return 0;
}

static void __exit exit_oscillateur (void)
{
  hrtimer_cancel(& htimer);
  gpio_free(GPIO_OSCILLATEUR);
}

static enum hrtimer_restart timer_oscillateur(struct hrtimer * unused)
{
  static int value = 0;
  gpio_set_value(GPIO_OSCILLATEUR, value);
  value = 1 - value;
  hrtimer_forward_now(& htimer, kt_periode);
  return HRTIMER_RESTART;
}

module_init(init_oscillateur);
module_exit(exit_oscillateur);
MODULE_LICENSE("GPL");

Après compilation (comme précédemment) et transfert sur la cible, nous chargeons le module.

[Panda]# /sbin/insmod /root/oscillateur-gpio-hrtimer.ko
[Panda]#

Nous voyons tout de suite la différence.

Notre oscillateur semble bien basculer toutes les millisecondes, puisqu’il y a un cycle complet sur chaque division durant 2ms. Vérifions avec un calibre plus précis.

Le hrtimer est bien déclenché toutes les millisecondes. Essayons de diminuer cette durée en commençant par une période de 100 microsecondes.

[Panda]# /sbin/rmmod /root/oscillateur-gpio-hrtimer.ko
[Panda]# /sbin/insmod /root/oscillateur-gpio-hrtimer.ko periode_us=100
[Panda]#

Le résultat est concluant. Le calibre de l’oscilloscope est cette fois sur 20 microsecondes/division.

Continuons à diminuer la période avec 10 microsecondes.

[Panda]# /sbin/rmmod /root/oscillateur-gpio-hrtimer.ko
[Panda]# /sbin/insmod /root/oscillateur-gpio-hrtimer.ko periode_us=10
[Panda]#

L’oscillateur conserve sa précision. C’est remarquable.

Toutefois lorsque la charge système augmente ou si de nombreuses interruptions surviennent, les fronts du signal se décalent sensiblement. Pour charger fortement en appels système notre carte, il y a une astuce simple : invoquer la commande :

[Panda]# top -d 0

Il y a alors des fluctuations assez importantes sur notre oscillateur. Voici une capture sur laquelle on voit que le niveau haut du signal dure près de onze microsecondes, et le niveau bas presque douze. Il y a d’autres fluctuations beaucoup plus grandes (mais difficiles à capturer !).

Cette sensibilité aux interruptions et à la quantité d’appels système est typique des systèmes temps-réel souples comme le noyau Linux classique.

Un timer avec Xenomai et RTDM

Pour obtenir une meilleure tenue de notre signal, nous allons utiliser l’extension temps réel strict Xenomai. Pour l’installer sur la Pandaboard, on se reportera à cet article.

Xenomai offre une API pour le développement de drivers temps réel nommée RTDM (Real Time Driver Model). Nous en avons déjà eu un aperçu dans cet article. Nous allons utiliser ce principe pour basculer notre broche GPIO.

oscillateur-gpio-rtdm.c :
#include <linux/version.h>
#include <linux/device.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/cdev.h>
#include <linux/gpio.h>
#include <linux/fs.h>
#include <asm/uaccess.h>
#include <rtdm/rtdm_driver.h>

static int periode_us = 1000;
module_param(periode_us, int, 0644);

static void timer_oscillateur(rtdm_timer_t *);
static rtdm_timer_t rtimer;

// 138 Broche 10 du port J3 (Expansion A) de la Pandaboard
#define GPIO_OSCILLATEUR 138

static int __init init_oscillateur (void)
{
  int err;

  if ((err = gpio_request(GPIO_OSCILLATEUR, THIS_MODULE->name)) != 0) {
    return err;
  }
  if ((err = gpio_direction_output(GPIO_OSCILLATEUR, 1)) != 0) {
    gpio_free(GPIO_OSCILLATEUR);
    return err;
  }

  if ((err = rtdm_timer_init(& rtimer, timer_oscillateur, "Oscillateur")) != 0) {
    gpio_free(GPIO_OSCILLATEUR);
    return err;
  }

  if ((err = rtdm_timer_start(& rtimer, periode_us*1000, periode_us*1000, RTDM_TIMERMODE_RELATIVE)) != 0) {
    rtdm_timer_destroy(& rtimer);
    gpio_free(GPIO_OSCILLATEUR);
    return err;
  }
  return 0;
}

static void __exit exit_oscillateur (void)
{
  rtdm_timer_stop(& rtimer);
  rtdm_timer_destroy(& rtimer);
  gpio_free(GPIO_OSCILLATEUR);
}

static void timer_oscillateur(rtdm_timer_t * unused)
{
  static int value = 0;
  gpio_set_value(GPIO_OSCILLATEUR, value);
  value = 1 - value;
}

module_init(init_oscillateur);
module_exit(exit_oscillateur);
MODULE_LICENSE("GPL");

Il n’y a rien de compliqué dans ce module. Nous le compilons avec le même Makefile que précédemment, mais il doit pouvoir trouver les fichiers d’en-tête de Xenomai, en interrogeant le script xeno-config. Chargeons notre module (après avoir déchargé le précédent), en lui demandant directement une période de 10 microsecondes.

[Panda]# /sbin/rmmod /root/oscillateur-gpio-hrtimer.ko 
[Panda]# /sbin/insmod /root/oscillateur-gpio-rtdm.ko periode_us=10
[Panda]#

Nous observons que le signal est bien net et régulier, et ne fluctue pas avec la charge système.

Il est possible d’utiliser des périodes encore plus courtes. La capture ci-dessous a été obtenue avec un timer de période 2 microsecondes, alors qu’un top -d 0 tournait sur la carte.

Nous voyons que l’activité en appels système du noyau Linux (top) ne perturbe pas le timer implémenté par Xenomai.

Conclusion

Nous avons examiné plusieurs méthodes pour réaliser des sorties sur une broche GPIO de la Pandaboard. Il nous reste à présent à nous intéresser aux entrées… Ce sera l’objet du prochain article.

Si vous souhaitez plus d’information sur les aspects temps réel abordés ici, je ne peux que vous conseiller mon nouveau livre « Solutions temps réel sous Linux » qui sera disponible en librairie (quel heureux hasard) à partir de demain !

Les GPIO (General Purpose Input Output) sont des broches du microprocesseur permettant de réaliser des opérations d’entrée-sortie électriques programmables. Chaque broche peut être affectée en entrée ou en sortie par programmation et utilisée aisément pour communiquer avec des périphériques externes.

La Pandaboard utilise un processeur Texas OMAP4430, construit autour d’un coeur Cortex A9. La documentation techique de l’OMAP4430 (plus de 5500 pages…) précise que le processeur dispose de six modules GPIO, chacun offrant 32 lignes d’entrées-sorties. Sur les 192 ports GPIO théoriquement présents, une bonne partie est déjà employée pour la carte elle-même mais quelques uns sont accessibles à l’utilisateur.

Connecteurs d’extension

Nous trouvons sur la Pandaboard deux connecteurs utlisables pour des expérimentations et extensions futures. Numérotés J3 et J6, ils sont également repérés par les libellés « Expansion Connector A » et « Expansion Connector B » comme on peut le voir sur la photo ci-contre.

Le détail des broches disponibles est fourni dans le manuel de référence de la Pandaboard (pages 43 et 44), certaines d’entre elles ayant une signification pour le système.

Par exemple, dans le tableau ci-dessous nous pouvons remarquer que la broche numéro 10 est associée à deux fonctionnalités : un signal Chip Select pour une communication avec une autre carte ou une entrée sortie GPIO numéro 138.

Certaines broches ont des affectations figées car elles sont reliées à des composants sur la carte, mais d’autres peuvent être utilisées pour réaliser des entrées sorties personnalisées.

Nous remarquons la présence sur la broche numéro 1 d’un signal d’alimentation +1.8 V que nous pourrons utiliser pour l’envoyer sur les entrées de notre choix (dans le prochain article) et de la masse du signal sur les broches 27 et 28.

Attention, les opérations sur ce connecteur sont très risquées car elles se répercutent directement sur les broches du processeur, sans protection. Je décline donc toute responsabilité si une manipualtion décrite ici sonne le glas de votre Pandaboard. Pour vous convaincre encore, sachez que j’ai grillé une carte Pandaboard (enfin, un processeur OMAP4 mais c’est le principal) simplement en confondant la broche 2 (alimentation +5V) et la broche 1 (alimentation +1.8V) pour envoyer un signal sur une entrée GPIO. Donc : prudence et concentration sont de rigueur !

 Nous allons donc souder sur le connecteur quelques fils afin d’accéder facilement aux broches 1, 10 et 28.

La broche 1 de chaque connecteur (en haut à gauche lorsqu’on le regarde de face) est repérée par un carré, la 2 se trouve en dessous, la 3 à droite du 1, la 4 en dessous de la 3 et ainsi de suite.

Naturellement, la soudure se fait plutôt sur la face opposée, où les numérotations sont inversées.

Pour cet article, nous n’utiliserons pas l’alimentation (broche 1), mais j’ai profité de l’occasion pour la souder en même temps les deux autres.

Accès aux GPIO depuis l’espace utilisateur avec le shell

Démarrons notre carte en utilisant un système fait maison, comme décrit dans les articles numéro 1, numéro 2, numéro 3, numéro 4 et numéro 5 d’une précédente série. Puis connectons depuis un PC distant en utilisant le protocole SSH.

[~]$ ssh root@192.168.5.152
root@192.168.5.152's password:
[Panda]#

Le prompt du shell sur la Pandaboard est préfixé par « [Panda] » pour éviter les confusions avec le système hôte.

Vérifions pour commencer la tension sur la broche 10 avec un simple voltmètre.

La tension est nulle, mais la broche est par défaut affectée en entrée (avec une haute impédance). Nous allons modifier cela.

[Panda]# cd /sys/class/gpio/
[Panda]# ls
export       gpio62       gpiochip128  gpiochip32   gpiochip96
gpio1        gpiochip0    gpiochip160  gpiochip64   unexport
[Panda]#

Par défaut, le port GPIO 138 n’est pas accessible depuis le pseudo système de fichier /sys/, mais nous pouvons le réclamer ainsi.

[Panda]# echo 138 > export 
[Panda]# ls
export       gpio138      gpiochip0    gpiochip160  gpiochip64   unexport
gpio1        gpio62       gpiochip128  gpiochip32   gpiochip96
[Panda]#

Le port 138 est maintenant accessible vérifions son sens de fonctionnement.

[Panda]# cd gpio138/
[Panda]# cat direction
in
[Panda]#

Il est affecté en entrée par sécurité au boot. Basculons-le en sortie.

[Panda]# echo out > direction 
[Panda]# cat direction 
out
[Panda]# cat value
0
[Panda]#

La valeur inscrite sur le port est 0, ce qui ne nous surprend pas puisque la tension sur la borne est nulle. Modifions la valeur.

[Panda]# echo 1 > value 
[Panda]#

Le voltmètre affiche maintenant 1,8 V (la tension de référence pour les GPIO, à ne pas dépasser pour les entrées !).

Écrivons à nouveau sur le port.

[Panda]# echo 0 > value 
[Panda]#

Le voltmètre affiche à nouveau 0.00. Libérons le port GPIO pour terminer cette expérience.

[Panda]# cd /sys/class/gpio/
[Panda]# echo 138 > unexport 
[Panda]#

Application des GPIO avec un script shell

Nous savons écrire une valeur sur une broche de sortie depuis la ligne de commande, automatisons cela dans un petit script shell qui va faire osciller la broche 10.

/usr/local/bin/oscillateur-gpio.sh :
#! /bin/sh

GPIO=138  # Broche 10 du port "Expansion A"

cd /sys/class/gpio

echo ${GPIO} > export

cd gpio${GPIO}

echo out > direction

while true
do
	echo 1 > value
	usleep 1000
	echo 0 > value
	usleep 1000
done

Le script réalise de petites pause de 1000 microsecondes, soit une milliseconde après chaque changement d’état de la broche.

Connectons un oscilloscope à la place du voltmètre pour voir évoluer le signal.

Nous apercevons sur l’écran un signal périodique qui alterne entre 0 et 1,8V. Toutefois, en regardant de plus près, les durées que nous avions indiquées dans le script ne sont pas respectées.

Le signal change de niveau toutes les 3,3 millisecondes environ et non pas à chaque milliseconde. Il s’agit de la granularité du usleep qui pose problème.Nous pouvons améliorer ceci en utilisant un petit programme en C qui réalise le même travail mais s’appuie directement sur la libC en passant outre les latences dûes au shell et aux utilitaires système (issus de la Busybox en l’occurrence).

oscillateur-gpio-user.c :
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

static volatile int exit_loop = 0;

void handler_signal(int unused)
{
    exit_loop = 1;
}

int main(int argc, char * argv[])
{
    int value = 1;
    char path[256];
    int gpio = 138;
    FILE * fp;

    // En argument on peut preciser un GPIO different de 138
    if ((argc > 2) || ((argc == 2) && (sscanf(argv[1], "%d", & gpio) != 1))) {
        fprintf(stderr, "usage: %s [gpio]\n", argv[0]);
        exit(EXIT_FAILURE);
    }

    // Exporter le GPIO dans le systeme de fichiers
    snprintf(path, 256, "/sys/class/gpio/export");
    if ((fp = fopen(path, "w")) == NULL) {
        perror(path);
        exit(EXIT_FAILURE);
    }
    fprintf(fp, "%d\n", gpio);
    fclose(fp);

    // Intercepter Controle-C pour finir proprement
    signal(SIGINT, handler_signal);

    // Basculer le GPIO en sortie
    snprintf(path, 256, "/sys/class/gpio/gpio%d/direction", gpio);
    if ((fp = fopen(path, "w")) == NULL) {
        perror(path);
        exit(EXIT_FAILURE);
    }
    fprintf(fp, "out\n");
    fclose(fp);

    // Ecrire alternativement la valeur du GPIO
    snprintf(path, 256, "/sys/class/gpio/gpio%d/value", gpio);
    if ((fp = fopen(path, "w")) == NULL) {
        perror(path);
        exit(EXIT_FAILURE);
    }
    while (! exit_loop) {
        fprintf(fp, "%d\n", value);
        fflush(fp);
        value = 1 - value;
        usleep(1000);
    }

    // De-exporter le GPIO du systeme de fichiers
    if ((fp = fopen("/sys/class/gpio/unexport", "w")) == NULL) {
        perror("/sys/class/gpio/unexport");
        exit(EXIT_FAILURE);
    }
    fprintf(fp, "%d\n", gpio);
    fclose(fp);
    return EXIT_SUCCESS;
}

Après compilation (en utilisant un cross-compiler comme indiqué dans cet article), nous transférons le code sur la cible.

$ ~/cross-panda/usr/bin/arm-linux-gcc -Wall -o oscillateur-gpio-user oscillateur-gpio-user.c
$ scp oscillateur-gpio-user root@192.168.5.152:/root/
root@192.168.5.152's password:
oscillateur-gpio-user                                               100% 6270     6.1KB/s   00:00
$

Sur la cible nous lançons le programme (et nous pouvons l’arrêter avec Contrôle-C).

[Panda]# /root/oscillateur-gpio-user 
    (Contrôle-C)
[Panda]#

Le signal est plus précis, nous pourrions calibrer la durée des sommeils pour avoir exactement une milliseconde, ou utiliser un timer logiciel comme ceux founis par setitimer().

Toutefois, sur l’écran de l’oscilloscope, le signal n’est pas très stable, ses fronts montants et descendants tremblent en permanence, signe classique d’un comportement lié à l’ordonnancement en temps partagé.

Pour améliorer la précision nous pouvons lancer le programme en ordonnancement temps réel souple avec chrt.

[Panda]# chrt -f99 /root/oscillateur-gpio-user
    (Contrôle-C)
[Panda]#

Le signal est beaucoup plus stable, mais il y a encore des petits « sauts » de temps à autres. Avec un oscilloscope à mémoire, nous pourrions voir apparaître parfois des fronts décalés d’une durée assez significative.

Conclusion

Afin d’améliorer la précision d’un signal, il est nécessaire d’adopter une approche temps réel. Ceci peut se réaliser de différentes manières. Dans le prochain article nous verrons comment gérer les GPIO depuis l’espace kernel en écrivant un module pour le noyau Linux standard, puis nous nous rapprocherons du temps réel strict en pilotant les GPIO depuis un module kernel de Xenomai, avec l’API RTDM.

Module dans l’espace noyau

Notre module va installer un timer avec une période d’une milliseconde. A chaque déclenchement, le timer mesurera l’écart par rapport au déclenchement précédent et proposera ses résultats dans une interface RTDM accessible depuis l’espace utilisateur.

Voici un exemple d’implémentation, les fichiers sources se trouvent dans cette archive.

mesure-periode-rtdm.c: 
#include <linux/version.h>
#include <linux/device.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/cdev.h>
#include <linux/fs.h>

#include <asm/uaccess.h>

#include <rtdm/rtdm_driver.h>

#define nom_device_rtdm "mesure_periode_rtdm"

static int read_mesure_periode(struct rtdm_dev_context * contexte, rtdm_user_info_t * info, void * buffer, size_t lg);
static int open_nonrt_mesure_periode (struct rtdm_dev_context * contexte, rtdm_user_info_t * info, int flags);
static int close_nonrt_mesure_periode (struct rtdm_dev_context * contexte, rtdm_user_info_t * info);
static void handler_mesure_periode (rtdm_timer_t * timer);

static struct rtdm_device rtdev_mesure_periode = {
    .struct_version = RTDM_DEVICE_STRUCT_VER,
    .device_flags   = RTDM_NAMED_DEVICE,
    .context_size   = 0,
    .device_name    = nom_device_rtdm,
    .open_nrt       = open_nonrt_mesure_periode,
    .ops = {
        .close_nrt = close_nonrt_mesure_periode,
        .read_nrt  = read_mesure_periode,
    },
    .device_class     = RTDM_CLASS_TESTING,
    .device_sub_class = 1,
    .profile_version  = 1,
    .driver_name      = nom_device_rtdm,
    .driver_version   = RTDM_DRIVER_VER(1,0,0),
    .peripheral_name  = nom_device_rtdm,
    .provider_name    = "cpb",
    .proc_name        = nom_device_rtdm,
};

static nanosecs_abs_t  periode_mini;
static nanosecs_abs_t  periode_maxi;
static nanosecs_abs_t  somme_periodes;
static int             nb_periodes;
static rtdm_mutex_t mtx_statistiques;

static rtdm_timer_t rtimer;
static nanosecs_rel_t periode_desiree = 1000000; // 1 ms

static int __init init_mesure_periode (void)
{
    int err;

    rtdm_mutex_init(& mtx_statistiques);

    periode_mini = -1;
    periode_maxi = 0;
    somme_periodes = 0;
    nb_periodes = 0;

    rtdm_dev_register(& rtdev_mesure_periode);
    if ((err = rtdm_timer_init(& rtimer, handler_mesure_periode, "Timer_mesure_periode")) != 0) {
        rtdm_dev_unregister(& rtdev_mesure_periode, 0);
        rtdm_mutex_destroy(& mtx_statistiques);
        return err;
    }

    if ((err = rtdm_timer_start(& rtimer, 1000000000, periode_desiree, RTDM_TIMERMODE_RELATIVE)) != 0) {
        rtdm_timer_destroy(& rtimer);
        rtdm_dev_unregister(& rtdev_mesure_periode, 0);
        rtdm_mutex_destroy(& mtx_statistiques);
        return err;
    }

    return 0;
}

static void __exit exit_mesure_periode(void)
{
    rtdm_timer_stop(& rtimer);
    rtdm_timer_destroy(& rtimer);
    rtdm_dev_unregister(& rtdev_mesure_periode, 0);
    rtdm_mutex_destroy(& mtx_statistiques);
}

static int read_mesure_periode(struct rtdm_dev_context * contexte, rtdm_user_info_t * info, void * buffer, size_t lg)
{
    char local_buffer[80];
    nanosecs_abs_t  _periode_mini;
    nanosecs_abs_t  _periode_maxi;
    nanosecs_abs_t  _somme_periodes;
    int             _nb_periodes;

    rtdm_mutex_lock(& mtx_statistiques);
    _periode_mini   = periode_mini;
    _periode_maxi   = periode_maxi;
    _somme_periodes = somme_periodes;
    _nb_periodes    = nb_periodes;
    rtdm_mutex_unlock(& mtx_statistiques);

    snprintf(local_buffer, 80, "%lld %lld %lld %d\n",
        _periode_mini, _periode_maxi, _somme_periodes, _nb_periodes);
    if (rtdm_safe_copy_to_user(info, buffer, local_buffer, strlen(local_buffer)) != 0)
        return -EFAULT;
    return strlen(local_buffer);
}

static int open_nonrt_mesure_periode(struct rtdm_dev_context * contexte, rtdm_user_info_t * info, int flags)
{
    return 0;
}

static int close_nonrt_mesure_periode(struct rtdm_dev_context * contexte, rtdm_user_info_t * info)
{
    return 0;
}

static void handler_mesure_periode (rtdm_timer_t * timer)
{
    nanosecs_abs_t         heure;
    static nanosecs_abs_t  precedente;
    nanosecs_abs_t         periode;

    heure = rtdm_clock_read();
    rtdm_mutex_lock(& mtx_statistiques);
    if (nb_periodes > 0) {
        periode = heure - precedente;
        if (periode > periode_maxi)
            periode_maxi = periode;
        if ((periode_mini == -1) || (periode_mini > periode))
            periode_mini = periode;
        somme_periodes += periode;
    }
    nb_periodes ++;
    rtdm_mutex_unlock(& mtx_statistiques);
    precedente = heure;
}

module_init(init_mesure_periode);
module_exit(exit_mesure_periode);
MODULE_LICENSE("GPL");

Compilons ce module, chargeons-le et vérifions qu’il soit bien enregistré. Naturellement, il est nécessaire d’avoir installé un noyau Linux/Xenomai comme décrit dans cet article ou celui-ci.

# make
make -C /lib/modules/2.6.38.8-xenomai/build SUBDIRS=/home/cpb/Documents/Livres/Articles/Blog/article-2012-05-07  modules
make[1]: entrant dans le répertoire « /usr/local/src/linux-2.6.38.8-xenomai »
  CC [M]  /home/cpb/Documents/Livres/Articles/Blog/article-2012-05-07/mesure-periode-rtdm.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /home/cpb/Documents/Livres/Articles/Blog/article-2012-05-07/mesure-periode-rtdm.mod.o
  LD [M]  /home/cpb/Documents/Livres/Articles/Blog/article-2012-05-07/mesure-periode-rtdm.ko
make[1]: quittant le répertoire « /usr/local/src/linux-2.6.38.8-xenomai »
gcc -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall -Werror-implicit-function-declaration -pipe -D__XENO__ -lrtdm -L/usr/xenomai/lib -lxenomai -lpthread -lrt -L /usr/xenomai/lib -o mesure-periode mesure-periode.c -lrtdm -lxenomai
# insmod ./mesure-periode-rtdm.ko 
# cat /proc/xenomai/rtdm/named_devices
Hash	Name				Driver		/proc
24	rttest-timerbench0             	xeno_timerbench	rttest-timerbench0
55	rttest-switchtest0             	xeno_switchtest	rttest-switchtest0
EE	mesure_periode_rtdm            	mesure_periode_rtdm	mesure_periode_rtdm
#

Application dans l’espace utilisateur

Contrairement aux drivers Linux habituels, RTDM ne fournit pas de fichier spécial (avec un type, un numéro majeur et un numéro mineur) pour accéder aux fonctionnalités implémentés. Le driver n’est pas accessible par un appel open() sur un fichier de /dev mais par une opération spécifique rt_dev_open() employant le nom du périphérique.

Voici un petit utilitaire qui ouvre le périphérique mesure_periode_rtdm et lit les valeurs. Il affiche sur sa sortie standard les informations obtenues.

mesure-periode.c: 
#include <fcntl.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

#include <rtdm/rtdm.h>

#define LG_BUFFER 80

int main (int argc, char * argv[])
{
    int fd;
    int i;
    char buffer[LG_BUFFER];
    long long int min, max, somme;
    int nb;
    fd = rt_dev_open("mesure_periode_rtdm", O_RDONLY);
    if (fd < 0) {
        fprintf(stderr, "%s: %s\n", argv[1], strerror(-fd));
        exit(EXIT_FAILURE);
    }

    while ((i = rt_dev_read(fd, buffer, LG_BUFFER)) > 0) {
        buffer[i] ='\0';
        if (sscanf(buffer, "%lld %lld %lld %d", &min, &max, &somme, &nb) == 4)
            printf("min = %lld, max = %lld, moy = %lld\n", min, max, somme / nb);
    }
    rt_dev_close(fd);
    return EXIT_SUCCESS;
}

Nous pouvons lancer le programme, il affichera sur sa sortie standard les valeurs statistiques obtenues.

# export LD_LIBRARY_PATH=/usr/xenomai/lib/
# ./mesure-periode
[...]
min = 968234, max = 1036666, moy = 999995
min = 968234, max = 1036666, moy = 999995
min = 968234, max = 1036666, moy = 999995
min = 968234, max = 1036666, moy = 999995
min = 968234, max = 1036666, moy = 999995
min = 968234, max = 1036666, moy = 999995
min = 968234, max = 1036666, moy = 999995
min = 968234, max = 1036666, moy = 999995
min = 968234, max = 1036666, moy = 999995
[...]
#

Résultats

Sur ce poste, nous voyons que le timer à 1kHz a subi des fluctuations maximales de 37 microsecondes environ, après un quart d’heure de fonctionnement. La machine n’était pas excessivement chargée, ni en interruptions ni en processus. Avec une charge beaucoup plus élevée, on pourrait probablement s’attendre à des fluctuations approchant la centaine de microsecondes.

Cette exécution s’est faite sur un poste de bureautique d’entrée de gamme, qui n’est donc pas particulièrement conçu pour le temps réel (notamment dans la gestion des interruptions SMI). Avec un PC industriel et un noyau bien configuré, j’ai déjà observé des fluctuations inférieures à 35 microsecondes sur deux jours alors que la machine était très fortement chargée, tant en activité CPU (processus, appel-système) qu’en interruptions diverses.

Si vous obtenez des résultats intéressants avec cette expérience, communiquez-les moi et je serai heureux de les faire figurer ici.

Configurer la vitesse CPU avec /sys

La première opération nécessaire est de connaître la liste des fréquences supportées par un CPU. Cette liste est accessible grâce au pseudo système de fichier /sys.

# ls /sys/devices/system/cpu/
cpu0  cpu1  cpu2  cpu3  cpufreq  cpuidle  kernel_max  offline  online  possible  present  probe  release  sched_mc_power_savings
# cat /sys/devices/system/cpu/online 
0-3
# cat /sys/devices/system/cpu/possible 
0-7
# cat /sys/devices/system/cpu/present 
0-3
#

Ici, le noyau peut gérer sept CPU (paramètre possible), mais il n’y en a que quatre connectés (present). Ils sont tous actifs (online). Choisissons, arbitrairement, le CPU numéro 1 et vérifions ses fréquences de fonctionnement.

# ls /sys/devices/system/cpu/cpu1/
cache  cpufreq  crash_notes  online  thermal_throttle  topology
# ls /sys/devices/system/cpu/cpu1/cpufreq/
affected_cpus               related_cpus                   scaling_max_freq
bios_limit                  scaling_available_frequencies  scaling_min_freq
cpuinfo_cur_freq            scaling_available_governors    scaling_setspeed
cpuinfo_max_freq            scaling_cur_freq               stats
cpuinfo_min_freq            scaling_driver
cpuinfo_transition_latency  scaling_governor
# cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_available_frequencies 
2400000 2133000 1867000 1600000
# cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq 
2400000
#

Le CPU accepte quatre fréquences, il est actuellement configuré avec la plus rapide : 2,4GHz. On peut la modifier ainsi.

# echo userspace > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor 
# echo 1867000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed 
# cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq 
1867000
#

Mesurer les effets de la vitesse CPU

Nous expliquerons la première ligne de l’exemple ci-dessus dans le prochain paragraphe.
Pour voir les effets de la configuration précédente, on peut utiliser un petit programme qui incrémente un compteur pendant une durée donnée (cinq secondes ici).

compte-iterations.c :
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/time.h>

int main(void)
{
	struct timeval tv;
	struct timeval tv_debut;
	long long int compteur;

	// Attendre le debut d'une nouvelle seconde
	gettimeofday(& tv_debut, NULL);
	do {
		gettimeofday(& tv, NULL);
	} while (tv.tv_sec == tv_debut.tv_sec);

	// Compter pendant cinq secondes
	compteur = 0;
	tv_debut = tv;
	do {
		compteur ++;
		gettimeofday(& tv, NULL);
	} while (tv.tv_sec < (tv_debut.tv_sec + 5));

	printf("Resultats : %lld\n", compteur);
	return EXIT_SUCCESS;
}

Essayons de l’exécuter avec différentes fréquences.

# echo 1600000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed 
# taskset -pc 1 $$
pid 9778's current affinity list: 0-3
pid 9778's new affinity list: 1
# ./compte-iterations 
Resultats : 17263876
# ./compte-iterations 
Resultats : 16733090
# ./compte-iterations 
Resultats : 16810727
# echo 1867000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed 
# ./compte-iterations 
Resultats : 19926359
# ./compte-iterations 
Resultats : 19868890
# ./compte-iterations 
Resultats : 19681040
# echo 2133000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed 
# ./compte-iterations 
Resultats : 22517877
# ./compte-iterations 
Resultats : 23028619
# ./compte-iterations 
Resultats : 22310298
# echo 2400000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed 
# ./compte-iterations 
Resultats : 25317042
# ./compte-iterations 
Resultats : 25806554
# ./compte-iterations 
Resultats : 25916774
#

Nous voyons bien que le nombre d’itérations fluctue en fonction de la fréquence configurée.

Configurer le comportement du CPU

Plutôt qu’agir directement sur la fréquence, ce qui nécessite de lire la valeur et d’inscrire celle choisie, le noyau nous propose des comportements, des heuristiques, qu’il nomme governors, qui vont assurer la modification de la fréquence CPU afin de l’ajuster aux besoins de l’utilisateur.
On trouvera des explications plus détaillées sur les governors dans cet article. Il existe (suivant la configuration du noyau à la compilation) jusqu’à cinq governors, dont les noms sont visibles ainsi.

# cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_available_governors 
conservative ondemand userspace powersave performance
#

Leurs comportements :

• powersave : économiser la batterie (d’un ordinateur portable) en utilisant la fréquence la plus faible possible.
• performance : optimiser la vitesse de traitement en adoptant la fréquence disponible la plus élevée.
• ondemand : faire varier la fréquence en fonction de la charge système afin d’optimiser la vitesse de traitement lorsqu’il y a une forte demande, tout en économisant la batterie lorsqu’il y a peu de tâches en cours.
• conservative : adopter le même comportement que ondemand, en évitant les modifications trop fréquentes de la vitesse du CPU.
• userspace : laisser l’utilisateur fixer lui-même la vitesse qui lui convient, comme nous l’avons fait dans les paragraphes précédents.

Essayons les effets des principaux governors sur notre programme.

# echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor 
# cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq 
2400000
# ./compte-iterations 
Resultats : 25932762
# ./compte-iterations 
Resultats : 25937413
# ./compte-iterations 
Resultats : 25335626
# echo powersave > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor 
# cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq
1600000
# ./compte-iterations 
Resultats : 17625101
# ./compte-iterations 
Resultats : 16788736
# ./compte-iterations 
Resultats : 17017337
# echo ondemand > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor 
# cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq
1600000
# ./compte-iterations 
Resultats : 25371803
# ./compte-iterations 
Resultats : 25294453
# ./compte-iterations 
Resultats : 25920801
#

Conclusion

Il est intéressant de pouvoir configurer facilement la vitesse du processeur indépendamment des fréquences exactes, en employant par exemple une heuristique powersave sur un portable, performance sur un serveur, ou ondemand sur un poste de travail généraliste.

Pour les systèmes embarqués, les choix ne sont pas toujours évidents, comme on peut le voir dans ces articles : Temps réel et économie d’énergie 1 et 2.

Il peut néanmoins être parfois nécessaire de gérer des lancements en arrière-plan, comme cela m’est arrivé une fois.

Situation

Un système aéroportuaire de traitement de plots radar m’envoyait des informations en continu sur un port réseau UDP/IP. Je devais les enregistrer dans des fichiers horodatés. Chaque fichier contenait une heure d’enregistrement environ. Je devais également, à l’issue de chaque enregistrement, effectuer une analyse des données qui durait environ cinq minutes.

Logiciels existants

Deux logiciels, écrits en C, étaient disponibles.

Le premier, appelons-le enregistreur prenait plusieurs arguments sur sa ligne de commande

• L’adresse IPv4 du groupe multicast dans lequel s’inscrire. Ceci n’a pas d’intérêt pour ce qui nous concerne ici, prenons par exemple 224.10.10.10.
• Le numéro de port UDP pour recevoir les données. La valeur ne nous concerne pas plus que la précédente. Fixons-la arbitrairement à 2012.
• La durée en secondes de l’enregistrement à réaliser. Pour une durée d’une heure, nous passerons 3600.
• Le nom du fichier où stocker l’enregistrement. Pour que les fichiers soient aisément manipulables par la suite, il est nécessaire que leurs noms contiennent un horodatage compréhensible.

Le second logiciel, que nous appellerons statistiques était un outil étudiant les données reçues (qu’il lisait depuis un fichier), et sortant des éléments d’information sur sa sortie standard. Ce programme prenait uniquement en argument le nom du fichier d’enregistrement à traiter.

Ces deux logiciels fonctionnaient très bien, et je devais les enchaîner dans un script shell afin qu’ils tournent 24H/24H.

Problème

Tout d’abord il fallait générer le nom du fichier en incluant un horodatage lisible. Pour cela le plus simple est souvent de s’appuyer sur la commande date dont les options permettent facilement de construire une chaîne de caractères en insérant des éléments de date et d’heure.

NOM_FICHIER=$(date +"enregistrement-LFPG-%Y-%m-%d-%H-%M.dat")

La variable NOM_FICHIER contiendra une chaîne de caractères comme enregistrement-LFPG-2012-04-21-09-00.dat.

Le second problème était plus gênant. Si l’on pouvait tolérer la perte d’une seconde de messages entre deux enregistrements, il n’était pas envisageable d’avoir un « trou » de cinq minutes (durée du programme statistiques). Je ne pouvais donc pas utiliser le shéma évident suivant.

#! /bin/sh
ADRESSE_IP=224.10.10.10
PORT_UDP=2012
while true
do
    # Generer le nom du fichier d'enregistrement
    FICHIER=$(date +"enregistrement-LFPG-%Y-%m-%d-%H-%M.dat")

    # Declencher l'enregistrement
    enregistreur ${ADRESSE_IP} ${PORT_UDP} 3600 "${FICHIER}"

    # Traiter l'heure ecoulee
    statistiques "${FICHIER}" > fichier-resultat.txt
done

Il fallait donc paralléliser le traitement statistique et l’enregistrement des données.

Première idée

On peut tout d’abord imaginer un schéma où le traitement statistique fonctionne en arrière-plan, la boucle principale étant cadencée par l’enregistreur. En voici un exemple.

#! /bin/sh
[...]
while true
do
    # Generer le nom du fichier d'enregistrement
    FICHIER=$(date +"enregistrement-LFPG-%Y-%m-%d-%H-%M.dat")

    # Declencher l'enregistrement
    enregistreur ${ADRESSE_IP} ${PORT_UDP} 3600 "${FICHIER}"

    # Traiter l'heure ecoulee
    statistiques "${FICHIER}" > fichier-resultat.txt &
done

On remarquera, à la fin de la ligne de la commande statistiques, le & qui provoque le passage à l’arrière-plan. Ceci permet au shell de reprendre immédiatement son exécution en début de boucle et donc de démarrer un nouvel enregistrement.

Cette méthode fonctionnait, mais elle présentait néanmoins un petit inconvénient. A l’issue du traitement statistique, le fichier de résultats devait être renommé en utilisant un numéro d’ordre séquentiel et copié dans un répertoire indépendant ; ceci seulement dans le cas où le fichier n’était pas vide. Il devenait compliqué de réaliser ces opérations dans une exécution en arrière-plan.

L’idée fut donc d’inverser le principe précédent, en effectuant l’enregistrement en arrière-plan et le traitement statistique dans la boucle principale.

Seconde idée

Voici un premier aperçu de la nouvelle solution.

#! /bin/sh
[...]
NUMERO_RESULTAT=1

while true
do
    # Generer le nom du fichier d'enregistrement
    FICHIER=$(date +"enregistrement-LFPG-%Y-%m-%d-%H-%M.dat")

    # Declencher l'enregistrement
    enregistreur ${ADRESSE_IP} ${PORT_UDP} 3600 "${FICHIER}" &

    # Traiter l'heure ecoulee
    statistiques "${FICHIER}" > fichier-resultat.txt

    # si le fichier n'est pas vide
    if [ -s fichier-resultat.txt ]

        # Le renommer et le déplacer
        mv fichier-resultat.txt "resultat-${NUMERO_RESULTAT}.txt"
        mv "resultat-${NUMERO_RESULTAT}.txt"  ~/resultats-statistiques/

        # Incrémenter le numéro d'ordre
        NUMERO_RESULTAT=$(( NUMERO_RESULTAT + 1 ))
    fi
done

Si cette idée semble séduisante au premier abord, elle ne fonctionne pas du tout en réalité. Lorsqu’on lance l’enregistreur en arrière-plan, le traitement statistique s’exécute en quelques minutes et relance un nouvel enregistreur alors que le précédent n’est pas terminé, et ainsi de suite.

Pour que cette méthode soit utilisable, il faudrait s’assurer avant de démarrer un enregistrement que le précédent soit fini. Pour cela, nous allons noter après le lancement en arrière-plan de l’enregistreur son numéro de processus (PID), et avant le lancement nous attendrons que le processus enregistreur précédent soit terminé.

Le shell nous fournit dans la variable $! le PID du dernier processus lancé en arrière-plan. Ajoutons donc la ligne suivante dans notre code.

[...]
    enregistreur ${ADRESSE_IP} ${PORT_UDP} 3600 "${FICHIER}" &
    PID_ENREGISTREUR=$!
    # Traiter l'heure ecoulee
    [...]

Pour attendre la fin d’un processus lancé par le shell, celui-ci nous propose la commande wait que l’on peut faire suivre du numéro de PID. Ajoutons cette attente avant le lancement.

[...]
    wait ${PID_ENREGISTREUR}
    enregistreur ${ADRESSE_IP} ${PORT_UDP} 3600 "${FICHIER}" &
    [...]

Nous devons bien sûr prendre en considération le démarrage de notre script, où aucun enregistreur ne tourne encore. Pour cela, il suffit d’initialiser la variable PID_ENREGISTREUR à un numéro impossible de processus (les PID sont toujours supérieurs à zéro) et de la tester avant d’appeler wait.

Troisième essai

Notre code devient :

#! /bin/sh
ADRESSE_IP=224.10.10.10
PORT_UDP=2012
REPERTOIRE_STATISTIQUES="~/resultats-statistiques/"
PID_ENREGISTREUR=0
while true
do
    # Generer le nom du fichier d'enregistrement
    FICHIER=$(date +"enregistrement-LFPG-%Y-%m-%d-%H-%M.dat")

    # Attendre la fin de l'enregistreur precedent
    if [ $PID_ENREGISTREUR -gt 0 ]
    then
        wait $PID_ENREGISTREUR
    fi
    # Declencher l'enregistrement
    enregistreur ${ADRESSE_IP} ${PORT_UDP} 3600 "${FICHIER}" &
    PID_ENREGISTREUR=$!

    # Traiter l'heure ecoulee
    statistiques "${FICHIER}" > fichier-resultat.txt

    # si le fichier n'est pas vide
    if [ -s fichier-resultat.txt ]
        # Le renommer et le deplacer
        mv "fichier-resultat.txt" "resultat-${NUMERO_RESULTAT}.txt"
        mv "resultat-${NUMERO_RESULTAT}.txt" "${REPERTOIRE_STATISTIQUES}"

        # Incrementer le numero d'ordre
        NUMERO_RESULTAT=$(( NUMERO_RESULTAT + 1 ))
    fi
done

Pourtant, en observant le script, on peut s’apercevoir d’un gros défaut : le traitement statistique démarre sur le même fichier que l’enregistreur en cours ! Il faut bien sûr qu’il travaille sur l’enregistrement précédent. Modifions encore notre script.

Solution

#! /bin/sh
ADRESSE_IP=224.10.10.10
PORT_UDP=2012
REPERTOIRE_STATISTIQUES="~/resultats-statistiques/"
PID_ENREGISTREUR=0
FICHIER_COURANT=""
FICHIER_PRECEDENT=""

while true
do
    # Attendre la fin de l'enregistreur precedent
    if [ ${PID_ENREGISTREUR} -gt 0 ]
    then
        wait ${PID_ENREGISTREUR}
        FICHIER_PRECEDENT="${FICHIER_COURANT}"
    fi

    # Generer le nom du nouvel enregistrement
    FICHIER_COURANT=$(date +"enregistrement-LFPG-%Y-%m-%d-%H-%M.dat")

    # Lancer l'enregistreur en arriere-plan
    enregistreur ${ADRESSE_IP} ${PORT_UDP} 3600 "${FICHIER_COURANT}" &
    PID_ENREGISTREUR=$!

    # Traiter l'enregistrement de l'heure ecoulee
    statistiques "${FICHIER_PRECEDENT}" > fichier-resultat.txt

    # si le resultat n'est pas vide
    if [ -s fichier-resultat.txt ]
        # Le renommer et le deplacer
        mv "fichier-resultat.txt" "resultat-${NUMERO_RESULTAT}.txt"
        mv "resultat-${NUMERO_RESULTAT}.txt" "${REPERTOIRE_STATISTIQUES}"

        # Incrementer le numero d'ordre
        NUMERO_RESULTAT=$(( NUMERO_RESULTAT + 1 ))
    fi
done

Cette fois le script est correct et fonctionne.

Conclusion

Nous voyons que l’encadrement par un script shell de programmes existants n’est pas toujours évident surtout lorsqu’il existe une dépendance temporelle entre eux (synchronisation). Ici, certains points du script ont été ignorés (gestion des erreurs d’exécution comme la saturation du disque par exemple), mais il nous a quand même fallu quatre versions pour obtenir enfin un programme correct. On retiendra égtalement que le soin apporté à la lisibilité et à la clarté du script est un gage de facilité de maintenance ultérieure, surtout lorsque l’algorithme global sort quelque peu de l’ordinaire (parallélisme par exemple).

ZX-81, imprimante et extension 16ko

J’ai voulu en avoir le cœur net, et j’ai tenté de le remettre en marche pour fêter le trentième anniversaire de son acquisition. En vain, il n’y a aucun signe de fonctionnement – bien que l’alimentation soit toujours correcte. En outre le câble plat qui reliait le clavier à la carte à microprocesseur à mal supporté l’usure du temps et s’est cassé net en plusieurs endroits ce qui me paraît difficilement réparable.

Tant pis, il ne se rallumera pas, mais cela ne m’empêchera aucunement de le conserver sur une étagère avec un certain nombre d’autres rescapés de la même époque. J’éprouve une affection particulière pour ce petit ordinateur sur lequel j’ai découvert la programmation en basic et en assembleur.

Pour ceux qui n’ont pas connu le ZX-81 (TS-1000 dans sa version américaine), il faut savoir que c’était le premier ordinateur vraiment grand public, et que les choix économiques rigoureux faits par son concepteur (Sir Clive Sinclair) en rendait l’utilisation assez… particulière. Tout d’abord le gros défaut de cet ordinateur était le manque de fiabilité des connexions sur le bus d’extension (où l’on branchait entre autre le bloc d’extension mémoire) ce qui provoquait des coupures inopinées d’alimentation en cas de mouvement de l’unité centrale, avec toutes les pertes de données que l’on peut imaginer.

Le système reposait sur un processeur huit bits, le Zilog Z-80-A, cadencé  à 3.5 MHz, et sur une mémoire RAM de 1 kilo-octet extensible à 16ko, voire 64ko pour les plus fortunés. Et aussi étonnant que cela puisse paraître, nous disposions de nombreux programmes (jeux, utilitaires, programmation, etc.) qui tenaient dans ces dimensions réduites de mémoire. La sauvegarde de la mémoire se faisait sur des cassettes audios par l’intermédiaire d’un magnétophone externe, le chargement d’un programme de quelques kilo-octets pouvant durer plusieurs longues minutes avec une fiabilité plutôt aléatoire.

Dès la mise sous tension, l’utilisateur disposait d’un prompt permettant de saisir des lignes de codes dans une version simplifiée du langage BASIC. Deux instructions, PEEK et POKE, permettaient de lire ou d’écrire des octets directement dans la mémoire et la fonction USR autorisait l’exécution d’un code à une adresse quelconque, généralement après y avoir inséré du code assembleur personnel.

3D Monster Maze

Les capacités vidéo étaient très limitées : 32 x 24 caractères monochromes. 16 caractères spéciaux étaitent constitués d’une matrice de quatre petits carrés, qui pouvaient se combiner pour offrir des graphiques avec la résolution de 64×48 pixels ! L’ingéniosité des programmeurs permettait de disposer quand même de jeux graphiques, comme le fameux « 3D Monster Maze » dans lequel le joueur se trouvait plongé dans un labyrinthe chassé par un tyrannosaure. J’ai pu en prendre la copie d’écran ci-contre sur un émulateur en-ligne. Mes jeux favoris étaient également « Space Invaders » et « Flight Simulation » (copie d’écran ci-dessous) ainsi que tous les programmes que l’on trouvait sous forme de listing dans les revues de l’époque.

Flight Simulation

J’ai appris sur cet ordinateur la programmation en BASIC, en écrivant notamment quelques outils de calculs pour l’astronomie (à usage personnel), et la programmation assembleur pour des jeux – inspirés de Pac-man ou Centipède – qui n’ont à ma connaissance jamais été diffusés en dehors d’un cercle très restreint d’amis possesseurs de la même machine.

 Il faut souligner la pédagogie du manuel (en français) du ZX-81 qui permettait de découvrir progressivement les principes de la programmation, et la bonne qualité des livres – disponibles en français également – pour approfondir l’étude de l’assembleur par exemple.

Même s’il ne redémarre pas, ce petit ordinateur continuera à trôner sur une étagère de mon bureau, attirant les regards surpris, amusés et parfois nostalgiques des visiteurs qui l’aperçoivent.

La bibliothèque µClibc regroupe les fonctionnalités communes dont les applications de haut-niveau ont besoin (par exemple des traitements de chaîne de caractères, des fonctions de calcul, des méthodes d’accès aux fichiers, etc.) en fournissant les points d’entrée pour le noyau Linux (les appels-système). La particularité de la µClibc par rapport aux bibliothèques « C » plus classiques comme la Gnu Glibc est d’être écrite en essayant de réduite au maximum la taille du code exécutable, et de pouvoir ainsi être employée dans les systèmes embarqués avec de fortes contraintes de place mémoire.

La plupart des systèmes embarqués construits avec des outils comme Buildroot (comme ceux que nous avons mis en oeuvre dans plusieurs articles) s’appuient sur la µClibc, et la Freebox v.6 ne fait apparemment pas exception, même si la bibliothèque n’est pas explicitement mentionnée dans la liste de logiciels libres décrites ici.

Dans la dernière version stable de la µClibc (0.9.33 du 1er février), un bug a été corrigé, comme cela est mentionné dans sa page de ChangeLog. Voici la portion qui nous intéresse :

commit 47f3da1cf49377c25772bb54d07db55225bbb142
Author: Guillaume Bourcier
Date:   Tue Oct 11 13:45:33 2011 +0200

    libc: fix daylight saving time handling

    The algorithm computing daylight saving time incorrectly adds a day for
    each month after January for leap years. The clock shift from/to DST can
    be delayed if the last Sunday of a transition month is exactly seven
    days before the first of the following month.

    This change adds a day for the February month only.

    Signed-off-by: Guillaume Bourcier
    Signed-off-by: Richard Braun
    Signed-off-by: Carmelo Amoroso

Pour les années bissextiles (comme 2012), l’algorithme de calcul de la date de passage à l’heure d’été ajoutait par erreur un jour au mois de février.

Ainsi le dernier dimanche du mois de mars (ce qui définit officiellement la date du changement d’heure) était considéré comme le dimanche 31 mars (alors que le 31 mars tombe en réalité un samedi). Visiblement le firmware de la Freebox ne contient pas encore cette correction, aussi pense-t-elle que le changement horaire doit avoir lieu dimanche prochain.

Si cette explication est la bonne, nos Freebox devraient basculer en heure d’été dimanche 1er avril à 02:00. Peut être Free va-t-il plaider l’hypothèse d’un poisson d’avril sophistiqué et anticipé ? À moins qu’une mise à jour du firmware intervienne d’ici là.

Une touche d’humour supplémentaire : dans le message ChangeLog ci-dessus j’ai supprimé la fin des adresses mails des personnes mentionnées pour leur éviter le spam. Il faut quand même savoir que l’adresse de G.Bourcier qui a détecté et corrigé le bug est « Free.fr » !

[AJOUT le 30/03/2012]: Free annonce avoir modifié le firmware du Freebox Server (version 1.1.5) pour corriger l’erreur. Il faut le redémarrer pour que la mise à jour ait lieu. Je ne l’ai pas fait sur ma Freebox pour vérifier dimanche si le changement horaire est bien décalé d’une semaine.

[AJOUT le 01/04/2012]: Comme on pouvait s’y attendre, le changement horaire a eu lieu cette nuit et l’afficheur de la Freebox indique bien l’heure correcte. Il est temps de faire la mise à jour du firmware, car sa nouvelle version intègre plusieurs corrections.