Les OS embarqués

Les OS embarqués
B. Miramond
UCP
Les OS embarqués
•
•
•
•
•
•
•
•
VxWorks : noyau RT le plus utilisé dans l'industrie. Supporte TCP/IP et une API
socket. Coût des licences important.
QNX : noyau RT de type UNIX. Intègre une interface graphique proche de X Window
(Photon). QNX peut être utilisé gratuitement pour des applications non commerciales.
Très faible empreinte mémoire.
uC/OS : destiné à des micro-contrôleurs type Motorola 68HC11. Support de TCP/IP.
Gratuit pour l'enseignement.
RTEMS : Real-Time Operating System for Multiprocessor Systems. Gratuit porté pour
de nombreuses architectures
Windows CE : Victime d'une réputation de fiabilité approximative...
Lynx OS : Système RT conforme à la norme POSIX.
Nucleus : Noyau RT avec support de TCP/IP, une interface graphique, un navigateur
web et serveur HTTP. Livré avec les sources, pas de royalties à payer pour la
redistribution.
eCos : Noyau RT (Embeddable Configurable OS), faible empreinte mémoire, basé
sur Linux et la chaîne de cross-compilation GNU (POSIX). Support de TCP/IP.
Licence proche GPL. Largement utilisé (automobile, imprimante, lecteur MP3).
Support des processeurs x86, PowerPC, SH3 Hitachi ou StrongARM.
Les OS embarqués
Quelle différence entre OS et
RTOS ?
• Le système d’exploitation temps-réel
(RTOS) est :
– Déterministe : la durée de chaque service est
déterminée et ne change pas avec les
données.
– Prévisible : la durée de chaque service est
connue.
– Léger
: le code de l’OS prend peu de
mémoire (empreinte mémoire)
– Dédiée, modulable : il fournit des services
dédiées selon les besoins de l’application
Miramond Benoît - UCP
4
Le succès de Linux en embarqué
•
•
•
•
•
•
Libre (gratuit)
Open-source
Différentes distributions
Stable
Communauté importante (aide web)
Compilateur C associé gratuit (gcc)
Miramond Benoît - UCP
5
Structure d’un système linux
A p p e ls d ir e c ts
M a t é r ie l
Noyau
B ib lio th è q u e C (G lib C )
A p p lic a tio n s
N o y a u (k e r n e l) : r é a lis e le s
f o n c tio n s e s s e n t ie lle s ( g e s t io n
d e s tâ c h e s e t m é m o ir e ) ,
in te r fa c e e n tr e le m a té r ie l e t le s
a p p lic a tio n s (p ilo t e s ).
lib c : b ib lio t h è q u e p r in c ip a le
c o n te n a n t le s f o n c tio n s d e b a s e
u tilis é e s p a r le s a p p lic a t if s .
A p p lic a t io n s ( o u c o m m a n d e s ) :
liv r é e s a v e c le s y s tè m e o u
d é v e lo p p é e s p o u r d e s b e s o in s
s p é c if iq u e s .
Les Distribution Linux embarquées
•
•
•
•
•
•
•
•
Montavista Linux
BlueCat Linux
uCLinux
RTLinux
RTAI (
ELDK
PeeWee Linux
...
Comment rendre linux
temps réel ?
• Distributions TR
– Montavista
– LynuxWorks
– Redhat
– Ubuntu
• Patch RT (CONFIG_PREEMPT_RT) de Linux :
– Scheduler
– Interruption préemptibles (thread-IRQ)
– Horloge système plus précise (nanosec)...
– sur une certaine plate-forme, le temps de latence de réponse à une
interruption ne sera jamais supérieur à 20µs, par exemple
– http://rt.wiki.kernel.org/index.php/Main_Page
• Micro-noyau
– Xenomai
– Windriver RT Linux (RTAI)Miramond Benoît - UCP
8
Fonctionnalités TR du patch
config_preempt_rt
Miramond Benoît - UCP
9
Exemple du micro-noyau
Xenomai
Miramond Benoît - UCP
10
Ordonnanceur 2.6
Grande nouveauté : Ordonnanceur en O(1)
2 types de process
Process non-Temps Réel : chaque process se voit attribuer une valeur, appelée nice value, qui détermine la priorité
et le temps d’exécution – ce temps d’exécution est appelé timeslice et correspond au temps maximum qu’un
process peut rester en exécution avant de « laisser la place » à un autre. La valeur de nice est comprise entre –20
et 19 inclus, 0 étant la valeur par défaut et –20 correspond à la priorité la plus haute et au timeslice le plus élevé
Process Temps Réel : chaque process se voit attribuer une priorité comprise entre 1 et 99 inclus – les process nonTemps Réel se voient attribuer également cette priorité mais avec la valeur 0. 99 étant la priorité la plus élevée,
on comprend alors pourquoi un process Temps Réel sera toujours prioritaire devant un autre non-Temps Réel.
Pour les process Temps Réel, il existe deux politiques d’ordonnancement :
SCHED_FIFO : le process Temps Réel restera en exécution tant qu’aucun autre process Temps Réel de priorité
supérieure strictement ne sera prêt ou tant qu’il ne passera pas à l’état bloqué. S’il est préempté, il reste tout de
même en tête de la liste d’exécution des process de même priorité que lui. C’est donc lui qui sera de nouveau
exécuté quand le process de priorité supérieure aura terminé son exécution. Idem s’il change de priorité, il sera
placé en tête de la liste des process exécutables ayant cette priorité. Il ne passe en fin de cette liste que par appel
explicite de sa part à une certaine fonction.
SCHED_RR : la politique est identique en tout point à la précédente, exception faite à la présence d’un timeslice
pour les process de même priorité. Ainsi, s’il n’y a pas de process de plus forte priorité pour préempter celui en
cours d’exécution, au bout d’un certain temps ce dernier sera placé en queue de la liste des process de même
priorité.
Miramond Benoît - UCP
11
Trois tests pour les linux RT
• Latence d'une tâche de forte priorité
– Cyclic_test
• Inversion de priorité (cf. cours suivant)
– classic_pi
• Préemption et latence de l'ordonnanceur
– preempt_test
• Temps d'accès noyau
• ...
http://www.kernel.org/pub/linux/kernel/people/tglx/rt-tests/rt-tests-0.49.ta
Miramond Benoît - UCP
12
Le bench cyclic_test
• sur un système non Temps Réel :
• $> ./cyclictest –a –t –n –p99
•
•
T:0( 3431)
39242
T: 1 ( 3432) P:98
P:99 I:1000 C: 100000 Min: 5 Act: 10 Avg:
I:1500
C: 66934
Min: 4
Act: 10
Avg: 17
14 Max:
Max: 39661
• Ici, le résultat du même test sur un
système Temps Réel :
• $> ./cyclictest –a –t –n –p99
•
•
T: 0 ( 3407) P:99 I:1000 C: 100000 Min: 7 Act:10 Avg: 10 Max: 18
T: 1 ( 3408) P:98 I:1500 C: 67043
Min: 7 Act: 8 Avg: 10 Max:
22
Miramond Benoît - UCP
13
Latence d'ordonnancement
Histogrammme de
répartition des apparitions
en fonction de leur latence
Miramond Benoît - UCP
14
Structuration d’un OS embarqué
HW/SW Multitasking


MailBoxes
Allocation statique,

HW/SW scheduling


Fifos Application
Allocation dynamique,

Changement dynamique de


Mutex
Pas de MMU
API
politique d’ordo?

Semaphore

Migration de tâche

Message
passing
Intergiciel

Hw->Hw, Sw->Hw, Hw->Sw
(Flexibilité, Distribution, virtualisation)

Gestion de tâches
Changement
de contexte
Synchronisation
Communication
Event
Gestion des
IR
Gestion mémoire
Monitoring

Instrumenter
l’application

mesures en temps
API HAL
réel à destination des
scheduler Hw/Sw
Timer
(Utilisation
…
temporel
… et
spatial…)
Autre exemple : uC/OS-II
• uC/OS-II (Micro Controller Operating
System)
– 1992 (J. Labrosse)
– 40 processeurs différents (8-64 bits)
– Portable
– ROMable
– Scalable (modulaire)
– Préemptif
– Déterministe
– Pas de MMU
Miramond Benoît - UCP
16
Etude de cas : fonctionnement
de uC/OS-II
Cas d’un noyau temps réel
Etude de cas : fonctionnement
de RTEMS
Cas d’un RTOS multiprocesseur