Cours 1 - Master 2 LSE Jalil Boukhobza Université de …stiff.univ-brest.fr/boukhobza/images/stories/Documents/... · 2015-12-06 · J.Boukhobza - Systèmes d'exploitation embarqués

Cours 1 - Master 2 LSE

Jalil Boukhobza

Université de Bretagne Occidentale – Lab-STICC

J.Boukhobza - Systèmes d'exploitation embarqués 1

Ce cours … Contient 24 séances de 2h:

Des cours (au moins 8)

Des TPs (plus de 10)

Pas de TDs …

Evaluation:

Contrôle continu (1/2)

Exposé

Projet TP

Examen final (1/2)


Contenu du cours Cours:

Revoir toutes (la plupart) les fonctionnalités des OS:

Plus en détails

En se focalisant sur ce qui est spécifique à l’embarqué

Etude de cas: Linux embarqué (+1 autre OS)

TP

Etude approfondie du système Linux (une partie)

Compilation de noyau Linux pour l’embarqué

Manipulation des outils permettant de s’y faire

Projet autour de Linux embarqué


Qu’est ce qu’un système embarqué Ébauche d’une définition: c’est un système électronique et

informatique autonome qui est dédié à une tâche particulière et contenue dans un système englobant. Il n’est « généralement » pas programmable. Pas d’E/S standards Matériel et application intimement liés Logiciel enfoui … noyé dans le matériel … pas facilement discernable

comme dans un PC.

Il sont partout !!!

Radio/réveil Machine à café Télévision / télécommande Moyen de transport (voiture : à foison !) Téléphone portable ….


Caractéristiques principales d’un système embarqué Système principalement numérique

Met généralement en œuvre un processeur

Exécute une application logicielle dédiée précise (non pas une application scientifique ou grand public tend à être moins vrai)

Il n’a pas réellement de clavier standard et l’affichage est limité

Ce ne sont pas des PC, mais des architectures similaires (x86) basse consommation (l’une des contraintes …).


L’embarqué en quelques chiffres En 1999, il a été vendu (dans le

domaine de l’embarqué):

1,3 milliards de processeurs 4 bits

1,4 milliards de processeurs 8 bits

375 millions de processeurs 16 bits

127 millions de processeurs 32 bits

3,2 millions de processeurs 64 bits.

Il a été vendu 108 millions de processeurs pour le marché du PC

En 2004:

14 milliards de processeurs pour l’embarqué (microprocesseur, microcontrôleur, DSP, etc.)

260 millions de processeurs PC.

Moins de 2% (5%) des processeurs vendu sont pour les PC, 98% (95%) pour l’embarqué

Prix moyen d’un processeur 6$ (2004) alors qu’un processeur PC coute 300$.

Le marché du processeur PC est de très faible volume … mais très lucratif


Sondage VDC research 2009 Architectures utilisées dans les projets (sondage)

37,4% : processeurs 8 bits

28,8%: processeurs 16 bits

64,4%: processeurs 32 bits

5,4%: processeurs 64 bits.

3,2% autres.


Source: http://embedded.com/electronics-blogs/programming-pointers/4374702/It-s-not-the-processor

Champs d’application: 4 grandes classes

1. Calcul généraliste Similaire aux applications bureau mais embarqué (assistant

personnel, téléphone portable, tablettes, etc.)

Consoles de jeux vidéo, set-top box

2. Contrôle de systèmes Moteur, voiture, avion, processus chimique, nucléaire,

navigation, etc.

3. Traitement du signal Compression vidéo, radar, flux de données, etc.

4. Réseaux et communications Transmission de données, commutation, routage, téléphone,

Internet, etc.


Exemples de systèmes embarqués Grand public :

Appareils photographiques et caméras, lecteurs DVD, chauffage et climatisation, éclairage, électroménager, domotique, sécurité (incendie, intrusion, surveillance, piscine), ascenseurs, HiFi, audio et vidéo, consoles de jeux, décodeurs, etc.

Transports : Automobile, aéronautique, spatial, marine, assistance à la

conduite ou au pilotage, maintenance, signalisation, contrôle du trafic aérien, maritime (aujourd’hui aide, demain automatique, objectif trafic autoroutier), distributeur de billets, radar, etc.

Défense : Contrôle de trajectoire, lanceur, etc.


Exemples de systèmes embarqués (2) Secteur manufacturier et industrie :

Chaînes de production, automates, production et distribution d’électricité, réacteurs chimiques, réacteurs nucléaires, raffineries, dispositifs de sécurité, aide à la maintenance, etc.

Information et communication : Imprimante, périphérique, téléphone, répondeur, fax,

routeurs, téléphonie mobile, satellites, GPS, etc.

Santé : Imagerie médicale, diagnostique, soins, implants,

handicapés, etc.

Autres : Carte à puce, distributeurs, etc.


Système embarqué typique


CPU Conversion A/N

Conversion N/A

Interface humaine Port de

diagnostic

Système auxiliaire

FPGA/ ASIC/DSP

Couche logicielle

Mémoire(s)

détecteur Actionneur

Environnement extérieur

Système embarqué typique (2) Capteurs (interrupteurs, etc.) couplés à des convertisseurs

analogique/numérique. Actionneurs (LED, etc.) couplés à des convertisseurs numérique/analogique. Calculateur (processeur embarqué et ses E/S). Possibilité d’avoir un/des FPGAs et/ou ASICs et/ou DSP pour jouer le rôle de

coprocesseurs (accélération matérielle)

Les systèmes embarqués doivent prendre en compte: Variation des températures Vibrations et chocs Variations des alimentations Interférences RF Corrosion Eau, feu, radiation …


Quelques propriétés des systèmes embarqués Ciblé: domaine d’action limité aux fonctions pour lesquelles il a

été crée. Simple: gage de robustesse Fiable: fonctionnement complètement autonome. Sécurisé Maintenable dans le temps: certains produits sont censés durer

jusqu’à 20 ans et plus (surtout dans le domaine militaire) Interface spécifique: approche matérielle à cause de

contraintes d’optimisation Optimisé: généralement logicielles de petite taille car plus c’est

grand, plus il y a de chance d’avoir des bugs. Ce sont des logiciels produits à grande échelle, le moindre centime compte.

Tolérant aux fautes

13 J.Boukhobza - Systèmes d'exploitation embarqués

Métriques des systèmes embarqués Puissance de calcul: sélection du processeur d’après la charge de

travail à effectuer et d’après la largeur des registres. Débit: le système peut avoir besoin de prendre en charge plusieurs

données en même temps. Temps de réponse: le système doit réagir vite Mémoire: l’estimation la plus précise possible de l’utilisation mémoire Consommation d’énergie: la conception hw ET sw doit prendre en

compte la conso Nombre d’unités produites dicte le compromis entre prix de

production et prix de développement Durée de vie est un paramètre important lors de la décision des

composants à inclure Installation du programme requiert des outils spécifiques Testabilité et débogage plus dur sans E/S de type clavier, etc. Fiabilité est un paramètre critique ex: système ABS


Logiciel/matériel embarqué Logiciel embarqué: programme/application utilisé dans un équipement et

complètement intégré dans ce dernier.

Système embarqué: Matériel(s) + logiciel(s) (+ OS)

2 types de systèmes embarqués (UNE classification):

1. Systèmes embarqués destinés à l’utilisateur (high-end): généralement une version dégradée d’un OS existant (ex: Linux). Ex: routeurs, PDA, smartphone, etc.

2. Systèmes embarqués profondément enfouis: peu de fonctions, très petite empreinte mémoire, généralement construit from scratch. Appareil photo numérique, téléphones portables, etc.

Différences avec les « machines normales »:

Prix (production de masse)

Performance

Consommation (contrainte de consommationbatterie)

Simplifier l’architecture

Réduire la vitesse d’horloge

Réduire l’utilisation mémoire


Système d’exploitation pour l’embarqué ? Les systèmes d’exploitation permettent:

De gérer les ressources matérielles en assurant leurs partages entre les différents utilisateurs.

De présenter une interface homogène et générique (en abstrayant la complexité matérielle) mieux adaptée aux utilisateurs.

Pourquoi un système d’exploitation pour l’embarqué ? Affranchir le développeur de logiciel embarqué de bien connaître le

matériel gain en temps de développement Les applications doivent avoir un accès aux services de l’OS via des APIs

(réutilisabilité du code, interopérabilité, portabilité, maintenance aisée)

Possibilité de bénéficier des mêmes avancées technologiques que les applications classiques (TCP/IP, HTTP, etc.)

Environnement de développement plus performant Time-to-market


Système d’exploitation pour l’embarqué (2) 1. Contrôle de processus sans (ou à faible) contrainte

temporelle systèmes à temps partagé Garantir le partage équitable du temps et des ressources

2. Contrôle de processus avec contrainte temps réel systèmes temps réel Garantir les temps de réponse

Systèmes à contraintes souples/molles: systèmes acceptant des variations minimes de temps de réponse (systèmes multimédias)

Systèmes à contraintes dures: gestion stricte du temps pour conserver l’intégrité du système (déterminisme logique et temporel et fiabilité)


Les latences Définition: différence entre le moment où une tâche

doit débuter (ou finir) et le moment ou elle débute réellement.

Elles sont dues:

Aux propriétés temporelles des processeurs, des bus mémoire et d’autres périphériques

Aux propriétés des politiques d’ordonnancement

À la préemptivité du noyau

À la charge du système

Au changement de contexte


Les latences (2) Tâches introduisant de « l’indeterminisme » temporel :

Accès disque: technologie mécanique, géométrie différente d’un disque à l’autre.

Accès au réseau: retransmissions en cas d’erreur

Résolution basse du timer

Pilotes de périphérique non temps réel: utilisation d’attente active et de période de sommeil peu précise.

Allocation et gestion de la mémoire: mémoire virtuelle /swap non prédictible.

Système de fichiers virtuel /proc: tout ce qui se passe dans le système création à la volée.

…


Récapitulatif Critères Temps partagé Temps réel

But Maximiser la capacité de traitement (débit) & utilisation des ressources

Etre prévisible (garantir les temps de réponse)

Temps de réponse Bon en moyenne Bon dans le pire des cas / moyenne non importante

Comportement à la charge

Confortable à l’utilisateur Stabilité et respect des contraintes de temps


Logiciel libre et systèmes embarqués Contrairement aux logiciels classiques, les (plusieurs) logiciels embarqués ont

(généralement) une durée de vie particulièrement longue important de faire évoluer le logiciel indépendamment des aléas économiques.

Contraintes des systèmes propriétaires:

Sociétés de taille moyenne ont du mal à suivre l’évolution technologique.

Outils de développement sont moins accessibles, la compétence est donc plus chère à obtenir.

Logiciels libres: plusieurs critères (disponibles sur www.opensource.org), les principaux sont:

La disponibilité du code source

La possibilité de réaliser des travaux dérivés

La redistribution sans royalties

Contrainte majeure: SAV sur le long terme + obligation de redistribuer le code


http://www.opensource.org/

Mais qu’est ce que l’Open source? 1. Libre redistribution: en tant que composant d’une distribution

pas de « droit d’auteur ». 2. Inclusion du code source: code source doit être accessible sans

frais supplémentaires. 3. Autorisation de travaux dérivés: modification et travaux

dérivés et leur redistribution 4. Intégrité du code source de l’utilisateur 5. Pas de discrimination entre les personnes ou les groupes 6. Pas de discrimination entre les domaines d’applications. 7. Distribution systématique de la licence 8. La licence ne doit pas être spécifique à un produit 9. La licence ne doit pas contaminer d’autres logiciels 10. La licence doit être technologiquement neutre


Logiciels libres Initié par Richard M. Stallman (M.I.T) entre 1970-1980 Naissance de GNU (Gnu is Not Unix!) dont le but était de créer

un OS. Mise en place d’un nouveau type de licence: GPL (General Public

Licence) principe de copyleft par opposition au copyright LGPL (Lesser GPL): originellement Library GPL similaire au GPL

sur les points suivants: Le copyleft: interdit de s’approprier le code distribué sous GPL ou

LGPL Disponibilité des corrections

Différences avec le GPL: permet d’effectuer une édition des liens de code propriétaire avec les bibliothèques permet la disponibilité sous Linux d’applications propriétaires qui utilisent des bibliothèques LGPL indispensables comme glibc


Tour d’horizon des OS embarqués VxWorks et pSOS: (WindRiver)

Noyau temps réel le plus utilisé dans l’industrie Inclut en natif un support TCP/IP Coût important de la licence Utilisation d’un environnement de compilation croisée

QNX: (QNX) Noyau temps réel de type UNIX (conforme à POSIX) Gratuit pour des applications non commerciales Développement direct sur la plateforme cible Très faible empreinte mémoire

µC/OS (Micrium): (uCosII ou III) Environnement de très petite taille (microcontrolleur 68HC11) Utilisable gratuitement pour l’enseignement/recherche. Peut intégrer des protocoles standards


Mars Reconnaissance Orbiter

Tablet BlackBerry

Tour d’horizon des OS embarqués (2) Windows CE : (Microsoft)

Cantonné à l’équipement de nombreux assistants personnels et téléphone (actuellement Nokia en remplacement de Symbian OS)

Nucleus (Mentor Graphics) Noyau temps réel; couche TCP/IP; interface graphique,

serveur http, etc. (open source)

eCos: embeddable Configurable OS (Cygnus puis RedHat) Temps réel, bien adapté aux très faibles empreintes mémoire.

Disponibilité des protocoles standards (TCP/IP, etc.)

Basé sur Linux et la chaîne de compilation GNU

Conforme à la norme POSIX


Y a un « OS » ?


Jim Turley (2006)

Source: http://www.eetimes.com/discussion/other/4025674/Operating-systems-on-the-rise

Source:Richard Nass (2008) http://embedded.com/design/embedded/4007664/An-insider-s-

view-of-the-2008-Embedded-Market-Study

Des chiffres, des chiffres …


Source:Richard Nass (2008) http://embedded.com/design/embedded/4007664/An-insider-s-

view-of-the-2008-Embedded-Market-Study

Tendance des (RT)OS … encore des chiffres !!


Source: Operating systems on the rise, Jim Turley

Embedded Systems Design

(06/21/06, 09:00:00 AM EDT) www.eetimes.com/discussion/other/4025674/Operating-systems-on-the-rise

Rapport VDC Research 2009


Les architectures des systèmes d’exploitation Plusieurs structures différentes: 1. OS Monolithique (plus ancien):

Simple/ne consomme pas beaucoup de ressources Convient aux « petits systèmes » ou quelques portions de

systèmes temps réel complexe OS entièrement en mode privilégié L’application utilise un appel système pour accéder aux

services de l’OS procédure exécutée Gestion de l’interruption : optimisée car pas de changement

de contexte entier (prioritaire car l’ordonnanceur est désactivé)

Impossible de mettre à jour l’application « à chaud » (remplacement + reboot)


OS Monolithiques Structure de base:

Un programme principal qui invoque la procédure du service

Un ensemble de procédures de services qui gèrent les appels système

Un ensemble de procédures utilitaires auxiliaires des précédentes

Vielles version d’UNIX (FreeBSD, SOLARIS), DOS.


Procédure

principale

Procédures de

service

Procédures

auxiliaires

Application

Hardware

OS Monolithique (exemple: UNIX)


Matériel

Gestionnaire d’interruptions Protection

Pilotes de périphériques

Gestion de processus

Gestion de mémoire

Système de fichiers

Support réseau

Démarrage et initialisation

Application Application Application Application

Couche d’abstraction matérielle (HAL)

API

noyau

OS Monolithiques: avantages/inconvénients De meilleures performances Vite développé … Évolution: chargement dynamique (et donc sélectif) des modules Extension difficile

Code non modulaire

Très complexe Code massif Plus c’est gros, moins c’est performant ! Nid de bugs Peu fiable (un bug redémarrage) Premières versions à chargement statique 400 périphériques

supportés 400 périphériques chargés au démarrage !!!!!!!!


Les architectures des systèmes d’exploitation (2) 2. OS Multicouches

OS organisé en hiérarchie de couches. Chacune construite sur la base des services offerts par la couche inférieure.

Interface et gestion des interruptions similaire à celle des systèmes monolithiques.

Meilleure structure et modularité maintenance plus aisée.

Configuration plus fine (modularité) meilleure utilisation de la mémoire + performance.


OS multicouches (exemple) Couche 5: le processus opérateur ou

utilisateur .

Couche 4: contient les programmes utilisateur, les notions de processus, mémoire, console leurs sont abstraites.

Couche 3: périph d’E/S et mise en mémoire tampon des flots d’E/S. Au dessus, les processus travaillaient sur une couche abstraite.

Couche 2: gestion de la communication entre processus et la console opérateur. Dans la couche précédente, chaque processus avait sa propre console opérateur/utilisateur

Couche 1: Allocation de mémoire dans la mémoire principale. Au dessus, les processus ignoraient les emplacements mémoire.

Couche 0: fournit le service de multiprogrammation. Dans la première couche, c’était un ensemble de processus séquentiels indépendants.

Couche Fonction

5 Opérateur/Utilisateur

4 Programmes utilisateur

3 Gestion des E/S

2 Communication opérateur-processus (OS/console)

1 Gestion de la mémoire et du tampon

0 Allocation du processeur-multiprogammation


Structure de l’OS THE (Technische

Hogescool Eindhoven), Dijkstra 1968

Ab

stra

ctio

n

OS Multicouches: avantages/inconvénients Facile à étendre (plus structuré)

Modèle simple

Traverser les différentes couches peut être couteux

La multiplication des couches peut ne pas être nécessaire.

Performances moins bonnes (vs monolithique)


Les architectures des systèmes d’exploitation (3) 3. OS Micronoyau

Déplace plusieurs fonctions de l’OS vers des « processus serveurs » s’exécutant en mode utilisateur réduction au maximum de la taille du code privilégié.

Gérer les communications entre applications et serveurs pour: Renforcer la politique de sécurité

Permettre l’exécution de fonctions système (accès aux registres d’E/S, etc.).

Fiabilité augmentée: si un processus serveur « crash », le système continue à fonctionner et il est possible de relancer ce service sans redémarrer.

Modèle facilement étendu à des systèmes distribués (efficacité?).

Gestion de l’interruption: commutation de tâche moins efficace que le modèle monolithique.


OS Micronoyau

Le noyau gèrent les communications entre clients et serveurs.

Certains services sont impossibles à exécuter en mode utilisateur (pilotes de périphériques d’E/S): Garder certains processus serveur critiques en mode noyau Garder une partie du mécanisme en mode noyau en laissant

le choix des politiques aux serveurs en mode utilisateur.


Micronoyau

Processus client

Processus client

Processus serveur

Serveur de terminaux

Serveur de fichiers

Serveur de mémoire

Mode utilisateur

Mode noyau

Source: « Systèmes d’exploitation »,

Andrew Tanenbaum, 2ème édition,

Pearson Education 2001

OS micronoyau

Si le client communique avec le serveur par envoi de messages, il lui importe peu que le serveur soit local ou distant, le résultat (logique) est le même d’où l’adaptabilité aux systèmes distribués

Exemples: Windows NT, Mach, Chorus, QNX.


Processus client

Processus client

Processus serveur

Serveur de terminaux

Serveur de fichiers

noyau noyau noyau noyau noyau

Machine 1 Machine 2 Machine 3 Machine 4 Machine n

Source: « Systèmes d’exploitation »,

Andrew Tanenbaum, 2ème édition,

Pearson Education 2001

OS Micronoyaux: avantages/inconvénients Extensibilité Minimise le code du noyau Sécurité:

Un serveur (mode utilisateur) crashe, il sera le seul à redémarrer

Fiabilité Micronoyau: code plus petit moins de bugs

Souvent tenté de rajouter des choses dans le noyau (vu qu’il

est petit…) Mauvaises performances Requière beaucoup de prudence lors de la conception


Les architectures des systèmes d’exploitation (4) 4. OS Machine virtuelle

L’OS doit remplir 2 fonctions: Multi programmation moniteur de machine virtuelle

Mode privilégié (exécution)

Plusieurs processeurs virtuels

Services système système invité

Un ou plusieurs OS « invités » qui s’exécutent sur les processeurs virtuels et fournissent les services système.

Le moniteur de machine virtuelle (hyperviseur) intercepte les instructions privilégiées envoyées par l’OS invité, les vérifie (politique de sécurité) et les exécute sur l’OS invité.

Les interruptions sont aussi interceptées par le moniteur de la MV


OS machine virtuelle 2 types:

MV native MV invité

Exemple de ce type d’OS: XEN, VMWare, IBM’ VM/370, QEMU, VirtualBox, etc.


Couche matériel Couche matériel

Moniteur de machine virtuelle

Application Application

Système d’exploitation

invité



invité

Système d’exploitation hôte

Moniteur de machine virtuelle



invité



invité

VM native VM invité

OS machine virtuelle: avantages/inconvénients Permet l’exécution de plusieurs OS sur une seule

machine

Permet une bonne portabilité des applications

Une protection complète (code exécute en mode privilégié complètement géré)

Bon environnement de développement (dev système en mode utilisateur…)

Gros problème de performances (plusieurs couches)

Manque de flexibilité


Les normes des systèmes d’exploitation POSIX (Portable Operating System Interface): standard pour les appels de

fonction (API) pour les OS UNIX-like. Il existe quelques spécifications pour des primitives temps réels.

Plusieurs profils pour le temps réel:

1. PSE51: profile de système temps réel minimaliste : 1 seul processus POSIX pouvant exécuter plusieurs threads POSIX pouvant utiliser le passage de messages POSIX pour communiquer avec d’autres systèmes PS5x

Hw: 1 seul processeur avec sa mémoire, pas de MMU et d’E/S standard.

2. PSE52: profile de système de contrôleur temps réel: PSE51+support pour un système de fichiers + E/S asynchrones

3. PSE53: profile de système temps réel dédié: PSE51+support multiprocessus(+MMU)

4. PSE54: profile de système temps réel polyvalent: englobe les autres profils. Il consiste de POSIX.1, POSIX.1b, POSIX.1c, et/ou POSIX.5b

Exemple: RTLinux se réclame du profil PSE51 alors qu’RTAI ne réclame rien du tout.


Les profils POSIX


Source http://blogs.windriver.com/wilson/2006/10/posix_profiles.html

http://blogs.windriver.com/wilson/2006/10/posix_profiles.html

http://blogs.windriver.com/wilson/2006/10/posix_profiles.html

Autres standards UNIX98: normalisation de l’OS UNIX. Cette norme

incorpore plusieurs des normes de POSIX EL/IX: API pour les systèmes embarqués. Se veut un sous

ensemble des normes POSIX et ANSI. ITRON: norme japonaise pour les systèmes embarqués OSEK: norme allemande pour une architecture ouverte

reliant les divers contrôleurs électroniques d’un véhicule. RT Spec pour Java: spécification pour un runtime qui

édicte des prescriptions (ramasse miettes, certaines politiques d’ordonnancement, etc.)

Ada95: ex: MarteOS, OpenRavenscar. RT Corba: un ensemble de spécification temps réel


Services des systèmes d’exploitation Gestion des tâches

Ordonnancement

Gestion des interruptions

Communication inter-processus et synchronisation

Gestion de la mémoire

Entrées/Sorties et pilotes de périphériques

Systèmes de fichiers

Protocoles de communication ….


Principes de base des tâches Processus et Threads Processus: l’activité qui exécute un programme incluant:

Le code source Les données L’état du processeur Chaque processus a son propre espace d’adressage

Gestion de la création, suppression, changement de priorité, contraintes temporelles, besoins mémoire, etc.

Concept de thread utilisateur, noyau, etc. Les « petits » OS pour l’embarqué utilisent seulement les threads

(executifs) alors que les « gros » OS peuvent utiliser plusieurs modèles processus/threads.


Processus et Thread (2) Création de processus et de threads:

Statique: toutes les tâches sont connues à l’avance il n’est pas possible d’en créer pendant que le système tourne.

Dynamique: appels système permettant de créer et détruire des tâches à la volée:

Système plus flexible

Plus de complexité (allocation dynamique, gestion d’erreurs)


Ordonnancement Entité qui décide quelle tâche doit exécuter le processeur.

Compromis entre la prédictibilité temps réel, complexité d’implémentation, et délai d’exécution.

RTOS (Real Time OS) supportent plusieurs politiques d’ordonnancement, le choix incombe (parfois) au programmeur: FIFO avec priorité (statique)

Date limite la plus proche (priorité dynamique) performant (uniprocesseur), couteux en temps de calcul

Serveur sporadique (perte de priorité en fonction du temps processeur consommé).

…


Gestion d’interruption Gestion de plusieurs périphériques: minuterie (timer),

moteurs, capteurs, disques, etc.

Requêtes asynchrones signalées par des interruptions

2 types d’interruptions: Interruptions matérielles Interruptions logicielles

Le code exécuté lors d’une interruption est dicté par le CPU à l’aide du vecteur d’interruption. Mais l’OS intervient pour: Connecter une adresse mémoire à chaque ligne d’interruption

Que faut-il faire après avoir servi une interruption

Gestion de l’aspect temps réel.


Communication & Synchronisation Inter Processus Sémaphores: (Dijkstra 1965)

Synchro à travers 2 opérations atomiques P et V.

Bas niveau

Exclusion mutuelle assurée par le programmeur

Moniteurs (Hoare & Hansen 1974) Mécanisme de haut niveau

Exclusion mutuelle assurée par le compilateur

Passage de messages Transfert de données entre processus

Mise en tampon des messages

Rendez-vous


Gestion de la mémoire Allocation: Allouer à chaque tâche la mémoire dont

elle a besoin

Mapping: Faire la correspondance entre la mémoire physique et l’adressage utilisé par les tâches.

Protection: Etablir un ensemble de comportements à adopter lorsqu’une tâche utilise de la mémoire non allouée.

Implémentation des mécanismes permettant cette gestion.


Support Réseau Le standard POSIX socket:

Accès uniforme à n’importe quel mode/protocole de communication en réseau (domaine de communication + type de socket)

Support réseau spécifique à un OS particulier:

Plus de fonctionnalités (création de filtre de msg / spécification de l’ordre de lecture des msg)

Moins de réutilisabilité


Autres fonctions Signaux temps réel et asynchrones: gestion des

événements imprévus (pannes sw ou hw) et dégradation des performances en cas de surcharge du processeur.

Horloge et minuterie (timer) haute résolution: donner au processus temps réel une mesure juste du temps écoulé

E/S asynchrones: découpler les processus temps réel de l’imprévisibilité des périphériques d’E/S


Compromis lors de la conception Espace noyau/espace utilisateur/espace temps réel.

OS monolithique/multicouche ou micro-noyau

Noyau préemptible ou non

Scalabilité

Gestion de mémoire / mémoire partagée

Dédié / générique


Exposé à faire Etude d’un système d’exploitation pour l’embarqué

(temps réel … ou pas)

RTEMS(interdit aux étudiants ayant fait leur master1 à l’UBO)

… un OS embarqué OpenSource (plus pratique pour savoir ce qu’il y a dedans!)
