Implantation logicielle

d’applications temps réel

Mise en oeuvre sur des éléments de RTAI

R.KOCIK – Département Systèmes Embarqués

1
PLAN

I.  Développement d’une application temps réel

II.  Quel Système d’exploitation (OS) utiliser ?
III.  Un OS Multi-tâches : Linux
IV.  Linux temps réel
V.  Développer avec RTAI
VI.  Taches RT et ordonnancement avec RTAI
VII.  Synchroniser, Communiquer
VIII. RTAI: conclusion
IX.  Et les autres RTOS ….

2
I. DÉVELOPPEMENT D’UNE
APPLICATION TEMPS-REEL

3
Cycle de développement

•  Définir Tâches
Spécification •  Définir contraintes temporelles

•  Choix d’algorithme d’ordonnancement

Analyse •  Analyse d’ordonnançabilité

•  Tâches
Mise en
oeuvre •  Ordonnancement

•  Tâches
Validation •  Comportement temps réel

4
Mise en œuvre d’un ordonnancement TR

l  Plusieurs solutions possibles

-  Sans exécutif temps réel
-  Avec exécutif temps réel

l  Dépend:
-  Caractéristiques des tâches
-  Politique d’ordonnancement (Priorité fixe/dynamique,
Préemption/sans préemption)
-  Architecture matérielle
-  Criticité de l’application (fiabilité, sûreté)
5
Sans exécutif temps réel : principes (1)

l  scrutation
faire
(attendre prochaine échéance)
faire
Processeur E/S vérifier capteur
tant que données non disponibles
Bus
lire capteurs
traiter les données
Acquisition faire
Calcul vérifier les actionneurs
Restitution tant que actionneurs non accessibles
ecrire actionneurs
jusqu ’à arrêt du système

6
Sans exécutif temps réel : principes (2)

l  Interruption (IT ou IRQ)

-  Matérielle (E/S, réseau,…), logicielle (exception), Timer
-  événement qui provoque un changement dans l’exécution
normale d ’un programme

IT Sur interruption faire

Processeur E/S lire capteurs
traiter les données
Bus
faire
vérifier les actionneurs
Acquisition tant que actionneurs non accessibles
Calcul écrire actionneurs
Restitution acquitter interruption

7
Scrutation : méthode (1)
l  Analyse : choix et validation d’un
ordonnancement
l  Construction de l’ordonnancement
Hyperpériode

T1

T2

T3 t

l  Construction d’une séquence d’exécution sur

l’hyperpériode
séquence

8
Scrutation : méthode (2)
séquence

l  Construction du code
1 seule exécution : allocation mémoire,
Initialisations Initialisations capteurs et actionneurs …

faire
T3();
T1();
Séquence de tâches
T2(); Exécution périodique
T1();
T2();
T1();
attente_fin_hyperpériode();
jusqu ’à arrêt du système
1 seule exécution : désallocation mémoire,
Finalisations sauvegardes, on met le système dans une
Configuration sécurisée

9
Scrutation (3)
l  Garantir la périodicité
1ère sol :En début (ou fin) de séquence on attend la date de début
(ou de fin) de l’hyperpériode suivante (ou courante)
Fonction attente_debut_hyperpériode()
Début
Faire
Date_courante ß lecture timer
Tant que date_courante < date_debut_next_HP
Date_debut_next_HP ß Date_debut_next_HP + Hyperperiode
fin

2ème sol : On programme une interruption Timer qui déclenche

périodiquement l’exécution de la séquence

l  Sinon système autocadencé :

Dans ce cas Période = Durée d’exécution de la séquence
10
Scrutation (4)

!
l  Ordonnancement oisif

T1

T2

T3 t

-  Exécution de la séquence :

Il faut insérer des temps

d’attente dans la séquence
-  Comportement souhaité

11
Scrutation (5)
! Ordonnancement préemptif
T1

T2

T3 t

Séquence :

Le code de la tâche T2 doit être découpé en 4 morceaux

Code_T2(){ Séquence à exécuter

instruction 1; Code séquence {
T3();T1();T2a();T1();
instruction n; T2b();T2c();T1();T2d();
}
}

12
Scrutation (6)

l  Autre méthode
-  Exécution d’une fonction d’ordonnancement avec une
période = PGCD des périodes des tâches
-  Chaque tâche est appelée par la fonction
d’ordonnancement 1 fois toutes les n exécutions de la
fonction d’ordonnancement avec n=Période_tâche/PGCD

l  Outils synchrones utilisent ce type de méthode

13
Scrutation: conclusion

l  Avantages
Nécessite peu de mémoire, code simple et déterministe,
temps de réaction facile à déterminer

l  Inconvénients
-  Très peu flexible
-  Limité aux ordonnancements non préemptifs
-  Pas adapté au déclenchement par évènement (event
trigged)

Plutôt utilisé dans les systèmes simples, lorsque les contraintes

de coût sont fortes, ou lorsqu’il faut pouvoir certifier le code de l’application (fiabilité)

14
Implantation avec RTOS Objet de ce cours

l  Avantages
-  Différents modèles de tâche:
Tâche cyclique, tâche en attente d’1 déclencheur, tâche traitant une
séquence d’événements déclencheurs, tâche traitant un choix
d’événements déclencheurs (automate)
-  Différents modes d’interaction entre tâches
ASYN/ASYN, ASYN/SYN, SYN/SYN, SYN/ASYN

-  Flexible
l  Inconvénients
-  Indéterminisme, surcoût d’exécution et de mémoire
La simplicité apparente de conception et la flexibilité rendent cette approche très
populaire
15
 interchangeable

II. QUEL SYSTEME

D’EXPLOITATION UTILISER ?

16
Cahier des charges d’un RTOS

l  Minimum pour gérer plusieurs tâches temps réel

-  support des IT
-  support d’une base de temps
-  déclaration de tâches : 3 états principaux (prêt, courant,
en attente)+création
-  ordonnanceur
-  éléments de synchronisation (ATTENDRE SIGNALER)
-  code chargé avec l’application (ROM/RAM)
l  Surcharge minimale par rapport à un processeur nu

17
Services supplémentaires
l  Orienté gestion tâches
-  Gestion de la mémoire
-  Structuration des échanges avec le monde extérieur
(E/S, IT) : pilote de périphérique (driver)
-  outils de synchronisation et communication
supplémentaires
l  Orienté IHM
-  rajouter des services
-  intégrer des services temps réel dans un OS
« standard »

18
Architecture de développement I
l  Développement croisé
Machine de développement
• écriture des sources
• mise au point
• compilation croisée
par simulation
(cross compilation)
• éditions des liens :
• téléchargement
-code
• console de déboguage
-bibliothèque T.R et noyau
-chargeur

Machine cible
• kit de développement
• système embarqué
• E/S
• Procédé
• Clavier/Ecran parfois

19
Architecture de développement II

l  IDEM développement croisé, mais la machine

de développement est aussi la cible

20
III. UN OS MULTITÂCHES : LINUX

21
LINUX quelques propriétés
l  Linux est un système d’exploitation libre
l  Gère les E/S standards
-  Disque
-  IHM (clavier, souris, écran)
-  Réseaux

l  Multitâches
-  Equilibre
-  Utilisation des ressources
-  Temps de réponse moyen
22
Linux, son noyau, ses modules
Espace
Emacs Bash Mozilla
Utilisateur
API
Espace
PROTOCOLE
Noyau COM
MODULE
DRIVER

KERNEL
Non autorisé
CERTAINS
FILESYSTEM

Matériel CPU RAM DISK NETWORK

23
Le noyau linux (KERNEL)
l  fonctions
-  ordonnancement, ses fonctions et son système de priorité
-  gestion des processus
-  gestion du temps système
-  accès aux ressources matérielles
-  gestion des interruptions
-  timers de signaux ALARME
-  files de tâches
-  gestions des identificateurs des utilisateurs et des groupes
-  gestion des modules
-  fonctions de trace, de debug (printk)
-  cas d ’instabilité système
-  accès aux informations système

!
Le noyau n’est pas multitâche et il est non préemptible

24
Les modules

l  Pourquoi des modules ? Modularité !!!

_permet d’éviter de recompiler le noyau lors de l’ajout
de drivers ou de consommer de la mémoire sur des
modules non utilisés et intégrés au noyau
l  un module peut utiliser toutes les fonctions, accéder à
des variables et structures du noyau
l  code exécuté avec niveau maximal de privilèges
l  Un module peut accéder aux E/S et exécuter des
instructions privilégiées

!
Les exceptions sont fatales au système lorsque provoquées
dans un module
25
Modules : quelques principes

l  Modules référencés dans une liste maintenue

par le système (accès par lsmod)
l  Un module ne peut appeler que les fonctions
exportées par le noyau (pas n’importe quelle
bibliothèque)
l  Module chargé en mémoire que par superviseur
(root) ou s’il en a donné le droit (sudo)
l  Le noyau maintient un compteur de liens sur le
module (pour savoir quand on peut le détruire)

26
Linux et le temps réel

l  Processus
-  Date de réveil non garantie
-  Ordonnanceur basé sur le principe du tourniquet :
répartir le temps d’exécution de manière équitable
-  noyau (appels systèmes) non préempté
l  Mémoire
-  Swap sur la Ram
-  Swap sur les process
l  Interruptions
-  dévalidées régulièrement par le noyau

!
_ LINUX N’EST PAS TEMPS REEL
27
IV. LINUX TEMPS RÉEL

28
Implémentation KURT

Linux classique KURT

l  rajouter une API « temps réel » dans le noyau

l  Rendre le noyau préemptif
l  Dévalider les IT le moins longtemps possible
l  Temps réponse ≈ qq 100µs

! Pour applications à contraintes TR relatives

29
Implémentation RT-Linux, RTAI

ou RTAI

l  Ajout d’un micro-noyau

l  Linux exécuté en tâche de fond au même titre qu’une RT-
Task
l  Cohabitation Linux / exécutif temps réel
l  Distribution fichiers : https://www.rtai.org/
l  Temps réponse < 20µs

Adapté aux applications à contraintes TR strictes

30
Autres solutions autour de LINUX
l  RTLinux
l  RTAI (variante de RTLinux)
l  eCos
l  ...
l  et leurs distributions commerciales
-  FSMLAbs (RTLinux)
-  MontaVista HardHat
-  Lineo Embedix Realtime
-  TimeSys Linux/RT
-  LynuxWorks BLueCat Linux (Lynx Real Time Systems)

31
A LIRE

l  Articles de Ismaël Ripoll

-  http://www.linuxfocus.org/Francais/May1998/
article44.html
-  http://www.linuxfocus.org/English/July1998/
article56.html
l  http://kadionik.developpez.com/cours/systeme/
linux-realtime/
l  « Linux embarqué », Pierre Ficheux, edition
Eyrolles

32
RTAI en quelques mots

l  Exécutif léger temps réel

l  Intègre au fur et à mesure de nouvelles
fonctionnalités
-  multi ordonnanceurs
-  communications
-  sources disponibles

l  Découpé en différents modules fonctionnels

-  on ne charge que ce dont on a besoin
-  la philosophie des créateurs de RTLinux est de garder un noyau
minimal, pas chez RTAI
l  support de l’unité arithmétique : FP
33
RTAI vit avec LINUX

l  Linux est fonctionnellement inchangé

l  offre tous les avantages et la puissance des environnements
modernes
l  Séparation du temps réel (RTAI) et du non temps
réel (Linux) :
l  tâches RT : pas d’appel système pour les services
l  Communication spéciale avec tâches non temps réel
-  Lecture/écriture mémoire
-  files d ’attente (fifo) temps réel, sorte de pipe avec propriétés
spéciales

l  Remarque : sans contrainte « temps réel », il existe des

équivalents plus sûrs (voire simples) en Linux de tous les
services systèmes que nous allons étudier

34
V. DÉVELOPPER AVEC RTAI

35
Comment intégrer une application RT ?
l  Modifier le noyau
-  installation de RTAI, suivez le guide
l  patcher Linux
l  compiler un nouveau noyau
l  installer les modules

l  Ecrire l’application sous forme de modules

-  connecté directement au noyau (espace kernel)
-  incorpore tâches RT
-  1 ou plusieurs module

l  Exécuter l’application
-  Compilation des modules applicatifs
-  Chargement des modules RTAI
-  Chargement des modules applicatifs

36
Développer un module (linux 2.4)

#define MODULE
#include<linux/init.h>
#include <linux/module.h>
#include<linux/version.h>

static int output=1;

int init_module(void) {
printk("Output= %d\n",output);
return 0;
}

void mon_code(void) {
output++;
}

void cleanup_module(void){
printk("Adiós, Bye, Ciao, Ovuar, \n");
}

37
Développer un module (linux 2.6)

#define MODULE
#include<linux/init.h>
#include <linux/module.h>
#include<linux/version.h> plus nécessaire

static int output=1;

int mon_init(void) {
printk("Output= %d\n",output);
return 0;
}

void mon_code(void) {
output++;
}

void mon_cleanup(void){
printk("Adiós, Bye, Ciao, Ovuar, \n");
}
module_init(mon_init);
module_exit(mon_cleanup);
38
Comment mettre en œuvre l’application ?

l  Compiler le module :
Ø  Linux 2.4 : gcc -I /usr/src/linux/include/linux -O2 –Wall
D__KERNEL__ -c exemple1.c
Ø  Linux 2.6 : nécessite les sources du noyau + makefile

l  Charger le module
> insmod exemple1.ko (exemple1.o sous noyau 2.4)

l  Printk écrit sur la console

> dmesg | tail -1
Output= 1

l  Liste des modules actifs

# lsmod
Module Pages Used by:
exemple1 1 0
sb 6 1
39
Etapes du chargement (résumé)

1)  Vérification des symboles externes référencés

2)  Vérification de version de noyau
3)  Allocation mémoire noyau pour contenir le code
et les données du module (mémoire physique)
4)  Copie du code du module dans l’espace alloué
5)  Maintenance de la table des symboles du
module (output et mon_code)
6)  Exécution de la routine d ’initialisation du
module init_module (point d’entrée)

40
Comment nettoyer le système ?

l  Enlever le module
-  exécutera la fonction cleanup_module()

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

41
Passer des données au module ?
-  En affectant des valeurs aux variables globales
# insmod exemple1.ko output=4
# dmesg | tail -3
Output= 1
Adiós, Bye, Ciao, Orvua,
Output= 4

l  Toutes ces commandes peuvent être

regroupées dans un makefile et/ou dans un
fichier de commande

42
Makefile

l  Interprété par la commande make

l  Ensemble de règles
l  Règle : dit comment exécuter une série de
commande pour construire une cible à partir de
fichiers sources. Définit aussi les dépendances
(fichiers d’entrées) nécessaires aux
commandes
règle : dépendances
commande

l  www.gnu.org/software/make/manual
43
Modules de RTAI
•  rtai_hal : fonctions de base
•  rtai_sched : ordonnanceur mono processeur
•  rtai_sem : gestion des sémaphores
•  rtai_fifos : interface « fichier » entre modules RT
et processus standards

+ vos modules applicatifs

-  liaison matériel
-  définition de tâches
l  A charger au démarrage de chaque lancement
d ’une application RT
_ script de commandes
44
Exemple script lancement

l  Utilisation des commandes linux

l  rt_modprobe

45
Structure d’une application
l  Découpler partie temps réel / fonctions non temps réel

X Windows Process utilisateur

RT RT
Fifo Fifo

Tâche Tâche
Noyau Linux RT RT

RTAI

Ecran Disques Réseau Périphériques

46
VI. TÂCHES RT ET
ORDONNANCEMENT AVEC RTAI

47
Tâches et organisation sur le processeur

l  Définition
-  Une tâche est une unité de travail séquentielle qui peut
être exécutée sur un processeur, composée de :
l  1 programme
l  1 pile d ’exécution
l  1 zone de données
l  registres particuliers processeur (compteur ordinal, pointeur de
pile) : sauvegardés lors du changement de tâche
-  En général et en temps réel
une tâche est exécutée
l  périodiquement (sur initiative de l’horloge)
l  sur arrivée d ’un événement (boucle et attente d ’événement)

48
Tâches sous Linux/RTAI

l  Sous Linux, 2 niveaux :

-  processus
Intègre des mécanismes de protection

-  thread (processus léger)

l  à l ’intérieur d’1 processus peuvent coexister plusieurs threads
l  partage de la même zone mémoire commune
l  changement de contexte (de tâche) plus rapide

l  Tâche RTAI = thread

49
RTAI : Gestion de tâches

l  RTAI
-  chaque tâche RT est un thread RT_TASK
-  Noyau Linux(noyau) = thread de priorité idle

l  Ordonnancement des tâches

-  par défaut
l  préemptif
l  priorité fixe ou EDF
l  risque de surcharge processeur
l  Linux : tâche de fond

50
Créer une tâche
#include <rtai_sched.h>
MODULE_LICENSE("GPL");
static RT_TASK tache;
#define STACK_SIZE 2000

iret = rt_task_init(&tache, // pointe sur la tache

routine, // nom de la fonction à exécuter
1, // entier passé à la routine
STACK_SIZE, // taille de la pile d’exécution
1, // int priorité, 0=plus haute priorité
0, // int 0 => n’utilise pas le fpu
0 // signal (voir rt_task_signal_handler)
);

l  iret = 0 si ok, <0 sinon

l  la création d’une tâche s’effectue dans le init_module

! rt_task_init ne déclenche pas la tâche

51
Rendre une tâche périodique
•  Dans init_module
iret = rt_task_make_periodic(&tache,
date_depart, nano2count(PERIODE));
_ rend périodique, unités en comptes internes

l  Dans la tâche
boucle infinie contenant le corps de la tâche
+ fonction rt_task_wait_period ();
_ suspend l’exécution jusqu’au début de la prochaine
période

52
Suspendre et détruire une tâche

l  Suspension
rt_task_suspend( rt_whoami() );

l  Reprise
rt_task_resume( &tache);
_ Permet aussi de déclencher la tâche en mode
non-périodique

l  Terminaison
rt_task_delete( &tache);

53
Gérer le temps

l  Timer : 2 modes de fonctionnement

-  rt_set_oneshot_mode()
l  Pentium récents utilise le CPU TSC (Time Stamp Clock) =>
base de temps variable
l  Sur 386,486 et premiers pentium pas de CPU TSC => lecture
du timer 8254 => couteux
-  rt_set_periodic_mode()
l  Mode par défaut
l  Période fixe
l  Les tâches dont la période n’est pas multiple de la période du
timer sont servies au mieux

54
Gérer le temps (2)
l  Avant tout il faut démarrer le timer
tick_per = start_rt_timer(per);
-  En mode one shot : per ignoré

-  En mode periodic : per = période du timer en count,

tick_per = période attribuée (count)

l  Prise d’infos sur le temps

rt_get_time(); en unités internes
rt_get_time_ns(); en nanosecondes

l  Conversions
RTIME tn, tc;
tc = nano2count(tn);
tn = count2nano (tc);
l  Arrêter le timer
stop_rt_timer();

55
RTAI : Ordonnancement

l  Politiques d ’ordonnancement combinables

-  EDF > priorités fixes
-  Préemptif priorité fixe : tâche de plus haute priorité depuis le plus
longtemps en attente
-  Linux est vu comme une tâche de fond (thread de priorité idle)

l  Priorité
-  Fixe : de 0 à RT_LOWEST_PRIORITY
ma_prio = rt_get_prio( rt_whoami());
ancienne = rt_change_prio(rt_whoami(),
ma_prio+1);
-  Dynamique
rt_task_set_resume_end_times(date_reveil, date_echeance);
rt_task_set_resume_end_times(-periode,-echeance);

56
RTAI : Etat des tâches

l  3 catégories
-  -1 unrunnable
-  0 runnable : liste des tâches prêtes
-  >0 stopped
l  1 : endormie : peut être réveillée par un signal ou l ’expiration
d ’un timer
l  2 : endormie mais non susceptible d ’être réveillée par
événement
l  4 : terminée (zombie)
l  8 : stoppée par signal de contrôle ou par instruction de debug
ptrace
l  16 : en train d ’être paginée
l  32 exclusive (seule à être réveillée lors d ’une attente)
57
Gestion SMP
l  SMP : Symetric Multi Processor
l  2 solutions
-  1 ordonnanceur gère les n processeurs
l  attribue les n threads les plus prioritaires parmi les t prêts
-  1 ordonnanceur par processeur
l  chaque thread est attribué à un couple {processeur, ordonnanceur}

l  les données/ synchros restent communes aux différents

tâches

l  RTAI : solutions intechangeables (modules spécifiques)

58
VII. SYNCHRONISER,
COMMUNIQUER

59
Synchroniser / Communiquer: pourquoi ?

l  Transmission d ’événement
-  fugitif, mémorisé, incrémenté
-  avec ou sans valeur associée
l  Assurer un ordre
-  avant / après
-  nombre d ’exécution
l  échanger des données
-  avec synchronisation
-  sans synchronisation
l  assurer l ’intégrité des données (de la mémoire)
60
RTAI : sémaphores binaires - mutex
l  Rendez-vous, exclusion mutuelle
l  Création
SEM mon_sem;
rt_typed_sem_init(&mon_sem, // pointeur sémaphore
1, // valeur initiale
BIN_SEM // type de sémaphore
);
l  Prendre le sémaphore
Si le sémaphore est présent : on prend le sémaphore et on continu
Si le sémaphore est absent : on est bloqué jusqu’à ce que le sémaphore
soit restitué
ierr = rt_sem_wait(&mon_sem);

l  Restituer le sémaphore
ierr = rt_sem_signal(&mon_sem);
61
Sémaphores (2)
l  Problèmes : inversion de priorité, interblocage
l  Autres types
rt_typed_sem_init(&mon_sem,1,BIN_SEM);
l  A compte : CNT_SEM
l  Ressource : RES_SEM

-  met en place le protocole de priorité plafond

l  Destruction
-  ierr = rt_sem_delete(&mon_sem);

l  Variantes asynchrones
-  rt_sem_wait_if : pas de blocage si sémaphore absent
-  rt_sem_wait_until(&sem,date): blocage au maximum
jusqu’à date
-  rt_sem_wait_timed(&sem,durée) : blocage au maximum
pendant durée
62
RTAI : Fifos

X Windows Process utilisateur

RT RT
Fifo Fifo

Tâche Tâche
Noyau Linux RT RT

RTAI

Ecran Disques Réseau Périphériques

63
RTAI : RTFifos coté process utilisateur

l  côté process utilisateur

-  périphérique spéciaux de type caractère :
l  /dev/rtf0, /dev/rtf1 v…
l  accessibles à travers les appels : open, ioctl, read, write

-  communication sans structure

l  file FIFO tampon d ’un nombre d ’octets fixé

-  n ’existe (ne peut être ouvert) que si déjà créé par

tâche RT ou par appel spécifique

64
RTAI : RTFifos coté RT
l  2 modes d ’utilisation
l  comme périphérique
l  API spécifique RT
rtf_create(unsigned int fifo, int taille);
création,
périphérique /dev/rtffifo existe,
rtf_destroy(unsigned int fifo);
destruction,
mémoire réallouée
rtf_put(fifo, char *tampon, int compte);
rtf_get(fifo, char *tampon, int compte);
retour -1, si insuffisamment de données ou
de place
non bloquant

65
RTAI : RTFifos
l  côté tâche RT (2)
l  API spécifique RT
int my_handler(unsigned int fifo);

rtf_create_handler(3,&my_handler);
routine my_handler exécutée en mode noyau quand des données
sont lues ou écrites
l  permet de réveiller une tâche RT, via p.ex. un task_resume
l  permet d ’éviter la scrutation régulière de la FIFO
l  permet de mettre en place un schéma ASYN/SYN quelconque avec
sémaphores

rtf_resize => redimensionner la fifo

l  plus d ’autres fonctions
66
Messages
l  Caractéristiques
-  Communication point à point (tâche à tâche)
-  message : valeure entière
-  SYN/SYN
-  ierr = rt_send(&tache_but,valeur); //SYN

-  ierr = rt_receive
(&tache_orig,&entier); //SYN

l  Variantes

-  If : send ASYN, pas d’envoi si recepteur non prêt, pas de blocage de l’emetteur

-  timed et until : blocage limité dans le temps

-  rt_receive(0 … : n ’importe quel émetteur

l  Pas d ’initialisation spécifique

67
Boîtes aux lettres (Bal)

l  Caractéristiques
-  Communication multi/multi point
-  message : taille variable
-  ASYN/SYN
-  ierr = rt_mbx_send(&Bal,&msg,taille_msg); ASYN, mais
blocage tant que le message entier n’a pas été copié dans la Bal
-  ierr = rt_mbx_receive(&Bal,&msg,taille_msg); Blocage tant
que le message n’a pas été reçu

l  Variantes send
-  if : envoi ssi le message entier peut être copié dans la bal
-  Wp : envoi autant d’octets que possible sans blocage
-  timed et until : blocage limité dans le temps
l  initialisation spécifique
-  ierr = rt_mbx_init(&Bal,taille)
-  ierr = rt_mbx_delete(&Bal);
68
Le problème de l ’allocation mémoire

l  Segmentation,
l  Mémoire paginée
l  pas new/delete ou malloc/free
-  kmalloc / kfree

l  non temps réel

l  solutions RT :
-  s ’allouer la mémoire de manière statique
-  allocation dans une table de blocs limitée

l  utilisation de kmalloc au niveau noyau

69
RTAI : Interruptions
l  permet réactions rapides
l  inhibe le noyau temps réel
l  niveau matériel et niveau logiciel
l  gestionnaire d ’IT simples avec temps de réponse fixe (ou
borné)
-  prise en compte d ’un événement
-  phase urgente, laisser une tâche dans l ’espace utilisateur faire le
travail de fond
l  ITs/événements peuvent être émis par :
-  équipement informatique (clavier, écran, disque …)
-  équipement industriel (capteur, actionneur, alarme …)
-  horloge : donne le rythme (tick = période d échantillonnage du
système)

70
Interaction par Interruption

requêt encodeur
e priorité

set
masquage priorité IA reset
Acq
Bus données

-  rt_global_cli() rt_global_sti()
-  rt_disable_irq(), rt_enable_irq()
71
RTAI : Interruptions (2)

l  Installation
#define IT_CLAVIER 1
rt_request_global_irq(IT_CLAVIER,
mon_gestionnaire);

rt_free_global_irq(IT_CLAVIER);

void mon_gestionnaire(void) {
rt_pend_linux_irq(IT_CLAVIER);

l  Utilisation
-  traitement urgent
-  réveiller tâche endormie

72
RTAI : communication avec le matériel

l  par pilote de périphérique (posixio)

-  « fichiers » /dev/nom
l  open/ close/ read/ write
l  accès direct aux ports E/S
#include <asm/io.h>

outb(valeur, adresse)
valeur = inb(adresse)
l  taille du mot : b, w, l
l  pause : _p : outl_p

73
Schémas classiques

l  Chien de garde (Watchdog)

l  Comment gérer un automate d ’état (machine à

café, menu téléphone …)

l  BD : lecteur rédacteur

l  Client Serveur

l  tableau noir
l  …

74
Exemple : machine à café

AN NU L/
rendre_m onnaie();

FRANC
INIT ENCORE

RETOUR FRANC
AN NU L/
rendre_m onnaie();

ACTIF
SERVI PREPARATION
PU SH/
SER VIR / preparer_cafe();
deplacer_tasse();

75
Machine à café : spcéfication fonctionelle
IHM
Process Linux
RTAI
Rt_fifo

Appel
Acqui Genere_transition
Signal transition

Calcul Automate

Rendre monnaie
Déplacer tasse
Préparer café
Afficher message

76
CONCLUSION

77
RTAI : quelques remarques
l  évolution permanente
l  possibilités en phase de mise au point non
détaillées ici
-  outils de trace : LTT
-  exécution en mode user : LXRT

l  Xenomaï
-  POSIX, VxWorks,VRTX,pSOS+,µITRON,RTAI

78
RTAI : quelques remarques
l  évolution permanente

l  possibilités en phase de mise au point non

détaillées ici
-  debug
-  outils de trace : LTT
-  exécution en mode user : LXRT
l  Xenomai

79
 RTAI-LAB
Spécification schémas-blocs
SCILAB/SCICOS
MATLAB/SIMULINK
Génération code
+
Librairie RTAI-LAB

RTAI
Exécution

http://www.rtai.org
http://www.scicos.org/
http://www.mathworks.com/products/simulink/
80
ET LES AUTRES RTOS …

81
Quelques OS … (source http://www.dspconsulting.com/rtos.html

RTOS URL Processeurs Licence

x86, 68k, PPC, CPU 32, i960, SPARC,
SPARCLite, SH, ColdFire, R3000, R4000,
Tornado, VxWorks http://www.wrs.com C16X, ARM, MIPS $16,500 par poste + cible

Hard Hat Linux http://www.mvista.com x86, PPC, MIPS and ARM Non

VRTX http://www.mentor.com x86, 68k, PPC, i960, ARM $2,000 par poste + cible

OS-9 V3.0 http://www.microware.com x86, 68k, PPC, SH3, StrongARM ? + cible

AMD ÉlanSC300/ 310/ 400/ 410, AM386

DE/SE Intel386 EX, Intel486, ULP Intel486, Prix calculé sur les modules
Pentium, Pentium Pro, and NatSemi utilisés sur la cible et par unité
QNX http://www.qnx.com NS486SXF. vendues

86, 68k, PPC, 683xx, CPU32(+), MIPS

R3000/4000/5000, Coldfire 510x/520x,
pSOS http://www.isi.com i960, ARM 7 (TDMI), SH1/2/3, M32R $17,000 par poste + cible

RTX http://www.vci.com x86, P5, P6 $150/RTX licence +cible

US$10,000 par poste

x86, 68k, PPC, microSPARC, microSPARC
LynxOS http://www.lynx.com II, PA-RISC Licence: US$7000 + cible

…. + beaucoup d’autres
82
Choix d’un RTOS

l  Performances = temps pour rendre les services à

l’application, depend de:
-  la plateforme matérielle (processeur, carte, horloge,..), du compilateur et
de sa conception
-  Quelles mesures ? Protocoles de mesures ? => benchmarks
-  Temps de préemption, Temps activation Task, sémaphore, allocation
mémoire, services …

l  Prix : licence + royalties sur chaque cible

l  Accès au Code Source
l  Environnement de développement
l  Panel de cibles
83