Traduit en fran�ais par S�bastien Blondeel.

�crire � l'auteur
�crire au traducteur

Table des mati�res :
KU Real Time Linux (KURT)
� quoi sert le temps r�el ?
Modules chargeables
Notre premier programme temps r�el
Communications entre les t�ches
Conclusion
R�f�rences

Linux temps r�el II

R�sum� : Dans ce deuxi�me num�ro d�di� � RT-Linux je tenterai de proposer une vue plus pratique de RT-Linux. Avant de rentrer dans les d�tails, toutefois, je donnerai un aper�u rapide d'un syst�me d'exploitation temps r�el tr�s r�cent, appel� Linux KURT.

KU Real Time Linux (KURT)

Au d�but de cette ann�e (1998), on a vu sortir un nouveau syst�me d'exploitation temps r�el fond� sur GNU/Linux. KURT est un syst�me d'exploitation temps r�el souple (et non pas ferme), c.�.d. que l'ordonnanceur tente de satisfaire les temps d'ex�cution r�clam�s, mais si une t�che prend du retard ce n'est pas vraiment une trag�die et rien de dramatique ne se produit. Les t�ches temps r�el de KURT peuvent profiter de toutes les fonctionnalit�s de GNU/Linux, au contraire des t�ches de RT-Linux. Les am�liorations --- modifications --- apport�es au noyau sont :

• Am�lioration de la r�solution de l'horloge du syst�me. Dans Linux-i386, la fr�quence d'interruption de l'horloge est de 10 ms (100 fois par seconde), et c'est en utilisant cette r�solution de temps que le noyau prend des d�cisions de contr�le et mesure le temps. KURT utilise le m�me m�canisme que RT-Linux pour g�rer le temps. Il programme la puce de l'horloge (8254) pour engendrer des interruptions sur commande, au lieu de le faire p�riodiquement. De cette mani�re, on peut obtenir des r�solutions exprim�es en micro-secondes.
• L'ordonnanceur a �t� modifi� pour inclure une nouvelle politique d'ordonnancement, SCHED_KURT, en sus de celles qui sont d�j� implant�es dans le noyau Linux et qui sont d�finies par le standard POSIX : SCHED_FIFO, SCHED_RR et SCHED_OTHER.
• De nouveaux appels syst�me ont �t� ajout�s de mani�re � profiter de la nouvelle fonctionnalit� temps r�el.

Les t�ches temps r�el sont des modules charg�s dynamiquement.

Une des fonctionnalit�s les plus caract�risques de KURT est sa politique d'ordonnancement. Il a �t� d�cid� d'implanter un ordonnanceur cyclique. Ce type d'ordonnanceurs utilise une table appel�e plan qui contient les actions ordonnanc�es : moment de l'activation, t�che � ex�cuter, dur�e de la t�che, etc. Cette table est construite pendant la phase de mise au point du syst�me. Plus tard, pendant l'ex�cution, le travail de l'ordonnanceur consiste simplement � lire s�quentiellement la table en suivant ses instructions. Quand on atteint la fin de la table, l'ordonnanceur retourne au d�but et continue � ex�cuter les t�ches --- d'o� le nom d'ordonnanceur cyclique. Ce type d'ordonnanceur pr�sente de nombreux avantages :

• L'ordonnanceur est tr�s simple � implanter

• Il est efficace

• Apr�s la construction du plan, on peut d�terminer imm�diatement si le syst�me est faisable (certains chercheurs maintiennent que c'est l� la seule mani�re de garantir � 100 % des performances correctes pour un OTR.)

La difficult� principale r�side � g�n�rer le plan lui-m�me. De plus, d�s qu'un des param�tres des t�ches est modifi�, il est n�cessaire de reconstruire le plan, et il faut souvent beaucoup de m�moire pour le stocker.

� quoi sert le temps r�el ?

Nombreux sont ceux qui pensent peut-�tre que les techniques temps r�el ne sont utilis�es que par la NASA (Agence spatiale d'Am�rique du Nord), ou avec des missiles ou des artefacts semblables. Cela �tait vrai il y a quelques ann�es, mais de nos jours la situation a bien chang� --- et ce n'est pas fini --- � cause de l'int�gration de syst�mes d'information et d'�lectronique dans la vie de tous les jours des gens. On trouve par exemple le temps r�el dans les t�l�communications et les applications multimedia. Par exemple, si on souhaite que l'ordinateur joue un fichier son stock� sur le disque dur, un programme devrait contin�ment (ou mieux, p�riodiquement) lire, d�compresser et envoyer les donn�es sonores � la carte son. Si en m�me temps qu'en �coute la musique, on travaille avec une application, comme un traitement de texte ou la simple compilation du noyau lui-m�me, il est certain que des blancs se feront entendre p�riodiquement, pendant que le noyau g�rera d'autres t�ches. Si au lieu de produire du son, on produisait de la vid�o sur notre syst�me, on obtiendrait une diffusion avec des arr�ts sur image intermittents. On appelle ce genre de syst�mes temps r�el souple (le viol d'une p�riode d'ex�cution ne produit pas un r�sultat d�sastreux, mais il d�grade les services propos�s par le syst�me).

Les applications de RT-Linux vont plus loin que les applications temps r�el normales. Gr�ce � RT-Linux, on peut prendre le contr�le total du PC (je dis PC et non par ordinateur car pour le moment on ne trouve RT-Linux que pour cette architecture), comme c'est le cas avec MS-DOS. Pendant une t�che temps r�el il est possible d'acc�der � tous les ports du PC, installer des gestionnaires d'interruptions, d�sactiver temporairement les interruptions, ... en d'autres termes, on peut � ï¿½crouler ï¿½ le syst�me comme s'il s'agissait d'un syst�me MS-Windows. Cette opportunit� est toutefois tr�s attrayante � ceux d'entre nous qui aiment attacher de petits � gadgets ï¿½ �lectroniques � l'ordinateur.

Modules chargeables

Pour comprendre RT-Linux et pouvoir l'utiliser, il faut conna�tre les modules de Linux qu'on peut charger dynamiquement. Matt Welsh a r�dig� un article complet o� il explique en d�tail tout ce qui concerne les modules.

Qu'est-ce que c'est ?

Dans la plupart des implantations d'Unix, la seule mani�re d'acc�der au mat�riel (les ports, la m�moire, les interruptions, etc.) et de passer par des fichiers particuliers et d'avoir install� au pr�alable les pilotes de p�riph�riques. M�me si les livres de qualit� expliquant comment �crire des pilotes de p�riph�riques ne manquent pas, c'est souvent un travail long et ennuyeux, puisqu'il est n�cessaire d'�crire de nombreuses fonctions pour lier le pilote au syst�me.

Les modules sont des �fragments du syst�me d'exploitation� qu'on peut ins�rer et extraire au moment de l'ex�cution. Quand on compile un programme comprenant plusieurs fichiers source, chaque fichier est compil� s�par�ment, dans un premier temps, pour engendrer un fichier objet �.o�, puis les objets sont li�s ensemble, en r�solvant toutes les r�f�rences et en engendrant un fichier ex�cutable unique. Supposons que le fichier objet comportant la fonction main puisse �tre ex�cut�, et que le syst�me d'exploitation soit capable de charger en m�moire et de proc�der � l'�dition de liens des autres fichiers objets quand cela s'av�re n�cessaire. Et bien, le noyau est capable de cela vis-�-vis de lui-m�me. Quand le syst�me GNU/Linux d�marre, seul l'ex�cutable vmlinuz est charg� en m�moire, il contient les �l�ments indispensables au noyau, et plus tard, pendant l'ex�cution, il peut charger ou oublier de mani�re s�lective les modules requis.

Les modules forment une fonctionnalit� optionnelle du noyau Linux, qu'il faut pr�ciser au moment de la compilation du noyau. Les noyaux de toutes les distributions que je connais ont �t� compil�s avec cette option activ�e.

Il est m�me possible de cr�er de nouveaux modules et de les charger sans devoir recompiler ou r�amorcer le syst�me

Quand un module est charg�, il se transforme en partie int�grante du syst�me d'exploitation donc :

• Il peut utiliser toutes les fonctions et acc�der � toutes les variables et � toutes les structures du noyau.

• Le code du module est ex�cut� avec le niveau maximal de privil�ges du processeur. Sur l'architecture i386, il est ex�cut� au niveau 0 (ring level 0), en cons�quence de quoi il peut disposer de tout type d'acc�s aux entr�es/sorties et ex�cuter des instructions privil�gi�es.

• Le m�moire du programme et de ses donn�es est directement r�serv�e en m�moire physique, et il n'est pas possible de la �paginer�. C'est pourquoi il est impossible d'engendrer une faute de page pendant l'ex�cution d'un module.

Comme on peut le voir, un module charg� dynamiquement dispose d�j� de certaines des caract�risques d'un programme temps r�el : il �vite les retards provoqu�s par des fautes de pages et il peut acc�der � toutes les ressources du mat�riel.

Comment les construire et les utiliser ?

Un module est construit � partir d'un code source �crit en langage �C�. Voici un exemple de module minuscule (pour ex�cuter la plupart des commandes suivantes il faut �tre super utilisateur ou root) :

exemple1.c

  #define MODULE
  #include <linux/module.h>
  #include <linux/cons.h>
  static int output=1;

  int init_module(void) {
    printk("Output= %d\n",output);
    return 0;
  } 
  void cleanup_module(void){   
    printk("Adi�s, Bye, Ciao, Ovuar, \n");
  }

Pour le compiler on utilise les param�tres suivants :

Le commutateur -c indique au programme gcc qu'il doit s'arr�ter apr�s avoir engendr� le fichier objet, et ne pas effectuer la phase d'�dition de liens. Le r�sultat final est un fichier appel� exemple1.o.

Le noyau ne dispose pas de sortie standard, aussi ne pouvons-nous pas utiliser la fonction printf()... � sa place, le noyau propose sa propre version de cette fonction, appel�e printk(), qui fonctionne presque comme la premi�re, � ceci pr�s qu'elle envoie son r�sultat � un tampon circulaire du noyau C'est dans ce tampon que tous les messages du syst�me aboutissent, et ce sont en r�alit� les messages qu'on peut observer en amor�ant le syst�me. � tout instant, on peut examiner le contenu du tampon en utilisant la commande dmesg ou plus directement, en examinant le fichier /proc/kmsg.

Remarquez l'absence de la fonction main() ; � sa place, on trouve la fonction init_module() qui n'accepte pas de param�tres. La fonction cleanup_module() est la derni�re fonction appel�e avant d'�ter un module de la m�moire. On effectue le chargement d'un module avec la commande insmod.

  # insmod exemple1.o

On a maintenant install� le module exemple1 et ex�cut� sa fonction init_module(). Pour observer le r�sultat, tapez :

  # dmesg | tail -1
  Output= 1   

La commande lsmod liste les modules actuellement charg�s dans le noyau :

# lsmod
Module    Pages   Used by:
exemple1      1          0
sb            6          1
uart401       2  [sb]    1
sound        16  [sb uart401]  0 (autoclean) 

Enfin, on utilise la commande rmmod pour �ter un module de la m�moire :

  # rmmod exemple1
  # dmesg | tail -2
  Output= 1
  Adi�s, Bye, Ciao, Orvua,     

La sortie de la commande dmesg nous montre que la fonction cleanup_module() a bien �t� ex�cut�e.

Il ne nous reste plus qu'� savoir comment passer des param�tres � un module. De fa�on surprenante, rien n'est plus simple. On peut affecter des valeurs aux variables globales en passant des param�tres � la fonction insmod. Par exemple :

  # insmod exemple1.o output=4
  # dmesg | tail -3
  Output= 1
  Ad�os, Bye, Chao, Ovuar,
  Output= 4                

Maitenant qu'on sait tout ce qu'il faut savoir sur les modules, revenons � RT-Linux.

Il faut d'abord se rappeler que pour utiliser RT-Linux, il faut d'abord pr�parer le noyau Linux � proposer une assistance pour les modules temps r�el — on a parl� de cette op�ration dans l'article pr�c�dent.

Il y a deux mani�res d'utiliser RT-Linux :

1. En tant que syst�me temps r�el classique, avec un ordonnanceur fond� sur des priorit�s fixes.

2. Sur un PC nu, rien ne ressemble � ce qu'on peut faire sous MS-DOS : intercepter les interruptions et avoir un contr�le total sur la machine.

Cette fois-ci, je discuterai de la mani�re d'utiliser RT-Linux en tant que syst�me disposant de priorit�s fixes. L'exemple que nous allons voir ne fait rien d'"utile", il se permet de mettre en place une t�che temps r�el (une simple boucle) :

  #define MODULE
  #include <linux/module.h>
  #include <linux/kernel.h>
  #include <linux/version.h>
  #include <linux/rt_sched.h>
  RT_TASK task;
	  
  void fun(int je_calcule) {
    int boucle,x,limite;
    limite = 10;
    while(1){
      for (boucle=0; boucle<je_calcule; boucle++)
        for (x=1; x<limite; x++);
      	
      rt_task_wait();
    }
  }
  
  int init_module(void) {

    RTIME now = rt_get_time(); 

    rt_task_init(&task,fun, 50 , 3000, 1);
    rt_task_make_periodic(&task,
          now+(RTIME)(RT_TICKS_PER_SEC*4000)/1000000,
	 (RTIME)(RT_TICKS_PER_SEC * 100)/1000000);
    return 0;
  }

  void cleanup_module(void){
    rt_task_delete(&task);
  }

Une fois encore, on compile cet exemple en utilisant la commande suivante :

Puisque ce programme est un module, le point d'entr�e est la fonction init_module(). La premi�re chose qu'elle fait est de lire l'heure qu'il est et de stocker cette valeur dans une variable locale ; la fonction rt_get_time() renvoie le nombre RT_TICKS_PER_SEC �coul� depuis le temps d'amor�age (dans l'implantation actuelle, RT_TICKS_PER_SEC vaut 1.193.180, ce qui donne une r�solution de 0.838 micro-secondes). La fonction rt_task_init() initialise la structure de "t�che" mais ne l'ex�cute pas encore. Le programme principal de la t�che r�cemment cr��e est fun(), qui est le second param�tre. Le param�tre suivant est la valeur de donn�es pass�e � la nouvelle t�che quand son ex�cution d�marre. Remarquez que la fonction fun() s'attend � recevoir un param�tre de type int. Le param�tre suivant est la taille de la t�che ; puisque chaque t�che dispose de son propre processus l�ger d'ex�cution, chaque t�che a besoin d'une pile propre. Le dernier param�tre est la priorit�&nsbp;; dans le cas pr�sent, si le syst�me ne compte qu'une t�che, on peut lui attribuer la valeur qu'on veut.

La fonction rt_task_make_periodic() transforme la t�che en t�che p�riodique. Elle prend deux valeurs de temps, d'abord l'instant, exprim� en temps absolu, o� la t�che sera activ�e pour la premi�re fois, et la p�riode s�parant les activations successives apr�s la premi�re activation.

La t�che temps r�el (la fonction fun()) est une boucle infinie o� on ne fait que deux actions : une boucle qui se contente de perdre du temps et qui appelle ensuite la fonction rt_task_wait(). La fonction rt_task_wait() est une fonction qui suspend l'ex�cution de la t�che qui l'a invoqu�e jusqu'� la prochaine activation, moment o� l'ex�cution va continuer � partir de l'instruction suivant imm�diatement l'appel � la fonction rt_task_wait(). Il faut comprendre qu'une t�che p�riodique n'est pas ex�cut�e � nouveau � chaque activation, au lieu de cela la t�che suspend elle-m�me son ex�cution (apr�s avoir termin� son travail) et attend la prochaine activation. Cela permet d'�crire une t�che qui n'ex�cute qu'un certain nombre d'initialisations la premi�re fois qu'elle est appel�e.

Pour ex�cuter le programme exemple2, il faut d'abord installer le module rt_prio_sched, puisque notre programme a besoin des fonctions rt_task_make_periodic(), rt_task_delete() et rt_task_init(). La fonction rt_get_time() n'est pas contenue dans le module mais elle se trouve dans le noyau Linux, par cons�quent nul besoin d'installer quoi que ce soit pour l'utiliser

  # modprobe rt_prio_sched
  # insmod ./exemple2.o

�tant donn� que le module rt_prio_sched est un module du syst�me, il a �t� cr�� pendant la compilation du noyau Linux et il a �t� par cons�quent copi� dans le r�pertoire /var/modules/2.0.33/. On utilise la commande modprobe car c'est un outil plus pratique pour charger les modules (il recherche les modules dans les r�pertoires de modules) (voir modprobe(1)).

Si tout s'est bien pass�, la commande lsmod devrait annoncer que les deux modules ont �t� correctement charg�s.

Bien, � ce point ci le lecteur dispose d�j� d'un programme temps r�el en cours d'ex�cution. Remarquez-vous quoi que ce soit ? Si le processeur est un peu lent, le lecteur remarquera probablement que Linux fonctionne un peu moins vite que d'habitude. Vous pouvez tenter d'incr�menter le nombre d'it�rations � l'int�rieur de la boucle de fun() en modifiant le troisi�me param�tre de la fonction rt_task_init(). Je vous recommande d'utiliser le programme ico pour appr�cier dans quelle mesure le temps disponible sur le processeur a �t� r�duit, puisque le temps utilis� par les programmes temps r�el affecte tous les programmes de l'espace utilisateur comme si le processeur fonctionnait � une vitesse moins �lev�e. Par cons�quent, Linux pensera que tous ses processus auront besoin de plus de temps pour effectuer les m�mes t�ches. Si le temps de calcul (le temps requis pour ex�cuter toutes les it�rations de la boucle) est sup�rieur � 100 micro-secondes Linux "g�lera" puisque Linux est la t�che de fond et la t�che temps r�el consomme 100 % du temps. En fait Linux ne g�le pas vraiment, il ne dispose plus jamais de temps sur le processeur.

Sous le syst�me RT-Linux, il n'existe qu'un seul moyen de communication : les files de type FIFO temps r�el. Leur mode de fonctionnement est tr�s semblable � celui des tuyaux (pipe) sous Unix, une communication par flot de donn�es sans structure. Une file FIFO est un tampon d'un nombre d'octets fix� sur lequel on peut effectuer des op�rations de lecture et d'�criture.

En utilisant des files de type FIFO, il est possible d'�tablir des communications entre t�ches temps r�el aussi bien qu'entre des t�ches normales sous Linux.

Du point de vue d'un processus normal, une file de type FIFO est un fichier � caract�re particulier. On les trouve habituellement sous les noms /dev/rtf0, /dev/rtf1, etc. Ces fichiers n'existent pas sous Linux aussi faut-il les cr�er comme suit :

S'il vous faut plus de files de type FIFO, vous pouvez facilement les cr�er en utilisant la m�me proc�dure pour les fichiers rtf4, rtf5, etc. Les fichiers sp�ciaux se comportent comme une interface � un handler sur le syst�me d'exploitation, mais si le handler n'existe pas, les fichiers sp�ciaux ne servent � rien. En r�alit�, toute tentative d'ouvrir un fichier sp�cial �choue quand le syst�me d'exploitation ne dispose pas du handler associ�.

On utilise les files de type FIFO comme si elles �taient des fichiers normaux (avec les fonctions open, read, write, close). Pour qu'un processus normal de Linux puisse les utiliser, il est n�cessaire qu'un programme temps r�el cr�e d'abord la file de type FIFO correspondant.

Du point de vue d'une t�che temps r�el, les files de type FIFO sont utilis�es � travers des fonctions sp�cifiques :

• rt_create(unsigned int fifo, int taille) : cr�e une file de type FIFO avec un tampon de taille taille. � partir de ce moment, et jusqu'� sa destruction, le p�riph�rique auquel on acc�de par le fichier /dev/rtf[fifo] existe et peut �tre utilis�.

• rt_destroy(unsigned int fifo) : la file de type FIFO correspondante est d�truite et sa m�moire est r�-allou�e.

• rt_fifo_put(fifo, char *tampon, int compte) : tente d'�crire compte octets � partir du tampon tampon. S'il ne reste pas suffisamment d'espace dans le tampon de la file de type FIFO, cette fonction renvoie -1.

• rt_fifo_get(fifo, char *tampon, compte) : tente de lire compte � partir de la file de type FIFO, et s'il n'y reste pas suffisamment de donn�es cette fonction renvoie -1.

Consid�rons maintenant un exemple de syst�me qui utilise ces fonctions. Cet exemple est une petite modification d'un des exemples dans la distribution de RT-Linux (sound) :

  #define MODULE
  #include <linux/module.h>
  #include <linux/rt_sched.h> 
	 
  #include <linux/rtf.h>
  #include <asm/io.h>

  RT_TASK tache;  

  static int filter(int x){
    static int vieil_x;
    int ret;
    if (x & 0x80) {
      x = 382 - x;
    }
    ret = x > vieil_x;
    vieil_x = x;
    return ret;
  }

  void fun(int mannequin) {
    char donnees;
    char temp;
    while (1) {
      if (rtf_get(0, &donnees, 1) >  0) {
        donnees = filter(donnees);
        temp = inb(0x61);            
        temp &= 0xfd;
        temp |= (donnees & 1) <<  1;
        outb(temp,0x61);
      }
      rt_task_wait();
    }
  }

  int init_module(void){
    rtf_create(0, 4000);
    
    /* met en place le compteur num�ro 2 */
    outb_p(inb_p(0x61)|3, 0x61);
    
    /* pour s'assurer que le compteur renvoie 1 */
    outb_p(0xb0, 0x43);
    outb_p(3, 0x42);
    outb_p(00, 0x42);
    
    rt_task_init(&tache, fun,  0 , 3000, 1);   
    rt_task_make_periodic(&tache, 
                   (RTIME)rt_get_time()+(RTIME)1000LL, 
                   (RTIME)(RT_TICKS_PER_SEC / 8192LL));

    return 0;
  } 

  void cleanup_module(void){
    rt_task_delete(&tache);  
    rtf_destroy(0);
  }

Comme dans le deuxi�me exemple, on a besoin des services du module rt_prio_sched, mais cette fois-ci, pour pouvoir utiliser la file de type FIFO, il nous faut aussi charger le module rt_fifo_new.

Une t�che temps r�el p�riodique de fr�quence 8192 Hz est cr��e. Cette t�che lit des octets dans la file de type FIFO num�ro 0, et si elle trouve quelque chose elle l'envoie au port du haut-parleur de l'ordinateur personnel de type PC. Si on copie un fichier son au format ".au" sur la file /dev/rtf0 on peut maintenant l'�couter. Il n'est pas n�cessaire de mentionner que la qualit� d'un tel son est terrible puisque le mat�riel des ordinateurs personnels de type PC ne dispose que d'un seul bit pour moduler le signal. Le r�pertoire testing/sound de la distribution contient le fichier linux.au qui a �t� utilis� pour les tests.

Pour le compiler et l'ex�cuter :

Remarquez de quelle mani�re on peut utiliser l'outil cat pour �crire dans tout fichier, y compris dans des fichiers sp�ciaux. On pourrait aussi utiliser la commande cp.

Pour comparer la mani�re dont les fonctionnalit�s du temps r�el affectent la qualit� de la reproduction, il nous suffit d'�crire un programme qui fasse la m�me op�ration, mais � partir d'un processus utilisateur normal de Linux :

  #include <unistd.h>
  #include <asm/io.h>
  #include <time.h>

  static int filter(int x){
    static int vieil_x;
    int ret;
    if (x & 0x80)
      x = 382 - x;
    ret = x > vieil_x;
    vieil_x = x;
    return ret;
  }
  attends(int x){
    int v;
    for (v=0; v<x; v++);
  }
  void fun() {
    char donnees;
    char temp;

    while (1) {
      if (read(0, &donnees, 1) >  0) {
        donnees = filter(donnees);
        temp = inb(0x61);
        temp &= 0xfd;
        temp |= (donnees & 1) << 1;
        outb(temp,0x61);
      }
      attends(3000);
    }
  }

  int main(void){
    unsigned char mannequin,x;
    ioperm(0x42, 0x3,1); ioperm(0x61, 0x1,1);

    mannequin= inb(0x61);attends(10);
    outb(mannequin|3, 0x61);

    outb(0xb0, 0x43);attends(10);

    outb(3, 0x42);attends(10);
    outb(00, 0x42);

    fun();
  }

On peut compiler ce programme comme tout programme normal :

  # gcc -O2 exemple4.c -o  exemple4

Et pour l'ex�cuter :

  # cat linux.au | exemple4

Pour acc�der aux ports mat�riels de l'ordinateur � partir d'un programme normal de Linux il faut l'autorisation du syst�me d'exploitation. C'est une mesure de protection �l�mentaire et n�cessaire pour �viter de programmer des acc�s directs au disque dur, par exemple. L'appel ioperm() dit au syst�me d'exploitation qu'on souhaite acc�der � un certain intervalle d'adresses d'entr�e/sortie. Seuls les programmes qui sont ex�cut�s avec les privil�ges du super utilisateur recevront cette permission. Il faut remarquer un autre d�tail, c'est la mani�re dont on engendre la fr�quence de 8192 Hz, qui module le son. M�me s'il existe un appel syst�me appel� nanodelay(), il ne dispose que d'une r�solution exprim�e en milli-secondes, aussi nous faut-il utiliser une horloge de temps en utilisant une boucle d'attente. Cette boucle est ajust�e de telle sorte qu'elle fonctionne plus ou moins sur un ordinateur de type Pentium cadenc� � 100 MHz.

Je sugg�re maintenant au lecteur de tester l'exemple4 avec le programme ico. Comment l'entendez-vous maintenant ? En quoi cela ressemble-t-il � la version temps r�el ? Alors, le temps r�el est-il utile � quelque chose ?

Conclusion

Ce deuxi�me article a mis l'accent sur les d�tails de programmation des t�ches temps r�el. Les exemples pr�sent�s sont tr�s simples et manquent d'utilisation pratique, mais dans l'article suivant je proposerai une application plus utile. Nous serons capables de contr�ler le t�l�viseur � partir de GNU/Linux ou, plus surprenant encore, de contr�ler une linuxette gr�ce � une t�l�commande ! .