CHAPITRE 9 

: LE SOUS SYSTEME D’ENTREE /SORTIES.

1. Introduction.
Tous les systèmes embarqués possèdent des opérations sur des entrées et des sorties (E/S ou
I/O pour intputs/Outputs). Ces opérations d’E/S sont réalisées sur différents types d’E/S (par
ex : tableau de bord d’une voiture,  clavier d’un PDA, disque dur sur un serveur de fichiers,
etc…). Souvent, le système embarqué est conçu spécifiquement pour gérer les besoins
associés au dispositif.
Les opérations d’E/S sont interprétées différemment en fonction du point de vu choisi et
imposent différents besoins sur le niveau de compréhension du hardware.
Du point de vue du développeur software du système, les opérations d’E/S implique la
communication avec le dispositif, la programmation du dispositif pour initier une requête
d’E/S, la réalisation de transfert entre le dispositif et le système, et la notification au
demandeur lorsque l’opération est terminée. Le développeur software du système doit
comprendre les propriétés physiques, comme la définition des registres, et les méthodes
d’accès aux dispositifs. Le développeur software du système est également concerné par la
manière dont le dispositif est intégré au système. Il doit également être en mesure de réaliser
des drivers du dispositif car il doit être capable de gérer les erreurs lors d’opérations d’E/S.
Vu du RTOS, les opérations d’E/S implique de situer le « bon » dispositif à partir de la requête
d’E/S, situer le « bon » driver du dispositif, et de réaliser la requête vers le driver du dispositif.
Parfois, le RTOS est nécessaire pour assurer la synchronisation des accès au dispositif. Le
RTOS doit faciliter l’abstraction pour le développeur, qui masque à la fois les caractéristiques
du dispositif mais aussi ses spécificités.
Pour le développeur d’application, le but est de trouver une manière simple, uniforme et
élégante pour communiquer avec tous les types de dispositifs présents dans le système. Le
développeur d’application est principalement concerné par la présentation efficace des
données vers l’utilisateur.

2. Concepts d’E/S de base.

La combinaison des dispositifs d’E/S, des drivers des dispositifs d’E/S, et le sous-système
d’E/S représente le système complet d’E/S dans un environnement embarqué. Le but du sous-
système d’E/S est de masquer les informations spécifique au dispositif au noyau, mais aussi au
développeur de l’application et de fournir une méthode d’accès uniforme aux périphériques
(ou dispositifs) d’E/S du système. Cette section présente certains concepts fondamentaux du
point de vue du développeur de driver du dispositif.
La figure suivante illustre un sous-système d’E/S en relation avec le reste du système sous la
forme d’un modèle en couches logicielles. Comme indiqué, chaque couche descendante ajoute
des informations détaillées supplémentaires sur l’architecture, informations utiles pour gérer le
dispositif donné.

1
2.1 Port-Mapped I/O, Memory Mapped I/O et DMA.
La couche basse contient les drivers d’E/S de dispositif hardware. Le dispositif hardware
d’E/S peut être par exemple un simple débit sur une ligne série ou une interface complexe
réseau qui peut aller jusqu’au gigabits/s. Toutes les dispositifs d’E/S doivent être
initialisés à partir de registres de contrôle, qui sous souvent externes à la CPU. Ils sont
situés sur la carte CPU ou dans les dispositifs eux-mêmes. Durant l’opération, les registres
du dispositif sont accédés encore et programmés pour traiter les requêtes de transfert de
données, qui sont appelés contrôle de dispositif (device control). Pour accéder à ces
dispositifs, il est nécessaire que le développeur détermine si le dispositif est port-mapped
ou memory- mapped. Cette information détermine laquelle des deux méthodes, port-
mapped ou memory-mapped est employée pour accéder au dispositif.
Lorsque l’espace d’adressage d’un dispositif d’E/S est séparé de l’espace d’adressage du
système, des instructions spéciales du processeur, telles que les instructions IN et OUT
dans le cas des processeurs INTEL, sont utilisées pour transferer des données entre le
dispositif d’E/S et les registres du microprocesseur ou la mémoire.
Les adresses du dispositif d’E/S sont qualifiées de port number lorsqu’elles sont
spécifiées pour les instructions spéciales. Cette forme d’E/S est appelée port-mapped I/O
et présentée à la figure ci-dessous.

Les dispositifs sont programmés pour occuper une plage dans l’espace d’adressage des
E/S. Chaque dispositif est sur un port d’E/S différent. Les ports d’E/S sont accessibles
grâce à des instructions spéciales du processeur, et les vraies adresses physiques le sont
grâce à des circuits hardware. Cette méthode d’E/S est aussi appelée E/S isolées (isolated

2
IO) car l’espace mémoire est isolé de l’espace d’E/S, donc l’ensemble de l’espace
mémoire est adressable et disponible pour les applications.

Un autre type d’accès au dispositif est le memory-mapped I/O comme indiqué à la figure
suivante :

Dans ce cas, l’adresse du dispositif est une partie de l’espace d’adressage du système.
N’importe quelle instruction machine qui est encodée pour transférer des données entre
une adresse mémoire et le processeur ou entre deux adresses mémoire peut
potentiellement être utilisée pour accéder au dispositif d’E/S. Le dispositif d’E/S est traité
comme une simple adresse mémoire. Comme la plage d’adresse destinée aux E/S est
située dans l’espace d’adressage du système, cet espace mémoire n’est plus disponible
pour les applications.
L’espace d’adresse de type le memory-mapped I/O ne commence pas nécessairement à
l’offset 0 comme indiqué à la figure précédente. Il peut être placé n’importe où dans
l’espace des adresses. Cela dépend de l’implémentation du système.
Souvent, des tables décrivant les emplacements (adresses) des registres internes des
dispositifs sont disponibles dans les notices hardware. Ces registres apparaissent avec
différents offset. Parfois, l’information est présentée sous le format adresse de base +
offset. Ce format indique que l’adresse du dispositif dans la table est relative, c’est-à-dire
que l’offset doit être additionné à l’adresse de départ de l’espace E/S dans le cas port-
mapped I/O ou que l’offset doit être additionné à l’adresse de départ de l’espace mémoire
du système dans le cas port-mapped I/O.
Le processeur doit réaliser des actions dans l’une ou l’autre méthode. Le transfert de
données entre le dispositif et le système nécessite le transfert de données entre le dispositif
et les registres du processeur, puis des registres du processeur vers la mémoire. La vitesse
de transfert peut être inadaptée pour les besoins des dispositifs d’E/S fonctionnant à
grande vitesse car des copies de données additionnelles sont impliquées. Les composants
(ou dispositifs) DMA (Direct Memory Acces) ou des contrôleurs permettent de résoudre
ces problèmes en donnant la possibilité au dispositif d’accéder directement à la mémoire
sans passer par le processeur, comme indiqué figure suivante.

3
 Le processeur est utilisé pour configurer le contrôleur DMA avant le début du transfert de
données, puis le processeur n’est plus employé (bypassed) durant le transfert de données,
indépendamment du type d’opérations sur les données (lecture ou écriture). La vitesse de
transfert dépend de la vitesse de transfert du dispositif d’E/S, ainsi que de la vitesse du
contrôleur DMA.
Finalement, le DMA fournit un chemin alternatif entre le dispositif d’E/S et la mémoire
principale. Le processeur configure le transfert de données en spécifiant au contrôleur
DMA l’adresse source, l’adresse de destination, et le nombre de données à transférer.

2.2 Dispositifs à mode caractères et à mode Bloc

Les dispositifs d’E/S sont classés en deux catégories : le mode caractère et le mode block.
Cette classification se réfère à la manière dont le dispositif va gérer le transfert de donnée
vers le système.
Le mode caractères permet le transfert de données non structurées. Le transfert de
donnée est typiquement réalisé en série, un octet par octet. Ce mode est utilisé dans des
dispositifs simples, comme des interfaces série ou des claviers. Le driver stocke les
données dans les cas où la vitesse de transfert du système vers le dispositif est plus rapide
que ce que peut accepter le dispositif.
Le mode Bloc transfert un bloc à un instant, par exemple, 1024 octet par transfert. Le
hardware sous-jacent impose la taille des blocs. Certaines structures de données peuvent
être imposées ainsi que des protocoles de transfert. Autrement, des erreurs peuvent
apparaitre. En conséquence, il est parfois nécessaire que le driver du dispositif réalise un
travail supplémentaire à chaque opération de lecture ou d’écriture, comme indiqué figure
suivante.
Comme illustré à la figure suivante, lorsqu’il doit réagir à une opération d’écriture avec
une grande quantité de données, le driver du dispositif doit d’abord diviser les données
d’entrée en de multiples blocs, chacun avec une taille spécifique au dispositif. Dans cet
exemple, les données d’entrée sont divisés en quatre blocs, tous de même taille sauf le
dernier. En pratique, la dernière partie est souvent plus petite que la taille des blocs du
dispositif.

4
 Chaque bloc est transféré au dispositif lors de requête d’écritures séparées. Les trois
premiers sont des écritures d’opérations directes. Le driver du dispositif doit gérer le
dernier bloc différemment des trois premiers en raison de sa taille. La méthode employée
pour traiter le dernier bloc est spécifique au dispositif. Dans certains cas, le driver rempli
le dernier bloc pour atteindre la taille requise. Notre exemple ci-dessus est basé sur le
driver du disque dur. Dans ce cas, le driver du dispositif réalise d’abord une opération de
lecture des blocs affectés et remplace les régions affectés de blocs par de nouvelles
données. Les blocs modifiés sont réécrit.
Une autre stratégie utilisée par les drivers en mode bloc pour des petites opérations
d’écriture est d’accumuler les données dans le cache du driver et de réaliser une écriture
réelle après que suffisamment de données soient accumulées pour remplir la taille d’un
bloc. Cette technique minimise le nombre d’accès au dispositif mais présente des
inconvénients. D’abord, le driver du dispositif est plus complexe. Par exemple, le driver
du dispositif en mode bloc pour un disque dur doit savoir sui les données dans le cache
peuvent satisfaire une opération de lecture. Une écriture retardée associée à une opération
de cache peut provoquer la perte de donnée si une erreur arrive et le driver est éteint et
incorrectement chargé. La mise en cache des données implique la copie des données qui
peut résulter en de plus faibles performances.

3. Le sous-système d’entrée sortie.

Chaque driver de dispositif d’E/S peut fournir un ensemble d’API spécifiques à l’application.
Cette organisation nécessite que chaque application soit capable d’identifier la nature du
dispositif d’E/S sous-jacent, ainsi que les restrictions imposées par le dispositif. L’ensemble
des API est spécifique au driver, mais aussi spécifique à l’implémentation, ce qui rend la
portabilité des applications utilisant ces API difficile. Pour réduire la dépendance à
l’implémentation, les systemes embarquées incluent souvent un sous-système d’E/S (I/O
subsystem).
Un sous-système d’E/S (I/O subsystem) définit un ensemble standard de fonctions pour des
opérations d’E/S dans le but de masquer les particularités du dispositif vis-à-vis de
l’application. Tous les drivers de dispositifs d’E/S se conforme et supporte cet ensemble de

5
fonction car le but est de produire des E/S uniformes vis-à-vis de l’application malgré une tres
large variété de types de dispositifs d’E/S.
Les étapes suivantes doivent être mises en place pour accomplir des opérations uniformes
d’E/S au niveau de l’application :

 Le sous-système d’E/S définit un ensemble d’API.

 Le driver du dispositif implémente chaque fonction dans l’ensemble.
 Le driver de dispositif exporte l’ensemble des fonctions dans le sous-système d’E/S.
 Le driver de dispositif réalise le travail nécessaire pour préparer le dispositif à être
utilisé. De plus, le driver réalise une association entre l’ensemble des API du sous-
système d’E/S et les appels d’E/S spécifique au dispositif.
 Le driver de dispositif charge le dispositif et informe le sous-système d’E/S de la
présence du driver et de son association avec le dispositif. Cette action permet au
sous-système d’E/S de donner l’illusion d’une abstraction du dispositif vis-à-vis de
l’application.

Cette section présente une approche des E/S uniformes. Cette approche est générale, et le
but est d’offrir une perspective de la couche subsystem IO et de son interaction avec la
couche application située au-dessus et avec la couche device driver située en dessous. Un
autre but des de fournir au lecteur l’opportunité de d’observer la manière dont les
éléments sont assemblés pour fournir des possibilités d’E/S uniformes dans les systèmes
embarqués.

3.1. Les fonctions d’E/S standards.

Le subsystem IO présentés dans l’exemple de cette section définit un ensemble de
fonction comme un ensemble de fonctions d’E/S standard. Le tableau suivant présente
ces fonctions qui sont considérées comme faisant partie d’un ensemble dans une approche
générale des E/S uniformes. Notez bien que l’approche utilisée dans cet exemple est dans
un but l’illustration afin de décrire le subsystem IO de manière générale. Le nombre de
fonctions dans l’ensemble des API d’E/S générales, leurs noms, et leurs fonctionnalités
dépendent du système embarqué et de son implémentation.

Fonction Description
Create Crée une instance virtuelle d’un dispositif d’E/S
Destroy Supprime une instance virtuelle d’un dispositif d’E/S
Open Prépare un dispositif d’E/S à être utilisé.
Close Communique au dispositif que son service n’est plus requis, ce
qui réalise des opérations de « nettoyage » sur le dispositif.
Read Lit des données depuis le dispositif d’E/S
Write Ecrit des données dans le dispositif d’E/S
loctl Emet des commandes de contrôle vers le dispositif d’E/S

Notez que toutes les fonctions opèrent sur une « instance virtuelle » du dispositif d’E/S.
En d’autres mots, ces fonctions n’agissent pas directement sur le dispositif d’E/S, mais plutôt
sur le driver, qui transmet l’opération au dispositif d’E/S. Lorsque les opérations open, read,
write et close sont décrites, elles doivent être comprises comme agissant indirectement sur un
dispositif d’E/S au travers d’une organisation d’instance virtuelle.

6
 La fonction create crée une instance virtuelle d’un dispositif d’E/S dans le IO subsystem,
rendant le dispositif disponible pour des opérations telles que open, read, write et loctl. La
fonction donne au driver une opportunité le préparer le dispositif à etre utilisé. Les
préparations peuvent inclure le mapping du dispositif dans l’espace mémoire du système,
l’allocation d’une ligne disponible d’IRQ pour le dispositif, l’installation de l’ISR associée à
l’IRQ, et l’initialisation du dispositif dans un état connu. Le driver alloue de la mémoire pour
enregistrer les informations spécifiques à l’instance, elles seront nécessaires lors des
opérations suivantes.
La fonction destroy supprime une instance virtuelle d’un dispositif d’E/S dans le IO
subsystem, rendant impossible toute nouvelle opérations sur le dispositif après que l’opération
destroy a pris fin. Cette fonction donne au driver l’opportunité de réaliser des opérations de
nettoyage, telle que le un-mapping du dispositif dans l’espace mémoire du système, la
suppression de l’allocation d’une ligne d’IRQ pour le dispositif, la désinstallation de l’ISR
associée à l’IRQ. Le driver libère la mémoire utilisée pour enregistrer les informations
spécifiques à l’instance.
L’opération open prépare un dispositif d’E/S à être utilisé par des opérations à venir, telles
que read, write. Le dispositif peut avoir été dans un état invalidé lorsque la fonction create a
été appelée. En conséquence, une des opérations que la fonction open peut réaliser est de
valider le dispositif. Typiquement, l’opération open peut aussi spécifier des modes
d’utilisations, par exemple, un dispositif peut être ouvert pour des opérations d’écriture
seulement, ou des opérations de lecture seulement, ou encore des opérations de réception de
commandes. La référence du nouveau dispositif d’E/S ouvert est retournée à l’appelant. Dans
certaines implémentations, le IO subsystem peut fournir seulement une des deux fonctions,
create et open, qui implémentent la plupart des fonctionnalités à la fois de create et open en
raison du chevauchement fonctionnel de ces deux opérations.
L’opération read récupère les données d’un dispositif d’E/S ouvert. L’appelant précise la
quantité de données à recevoir depuis le dispositif et la position mémoire où les données
doivent être stockées. L’appelant est complétement isolé des détails du dispositif et n’est pas
concerné par les restrictions d’E/S imposées au dispositif.
L’opération write transfère des données depuis l’application vers un dispositif d’E/S
précédemment ouvert. L’appelant précise la quantité de données à écrire vers le dispositif et la
position mémoire où les données à envoyer sont stockées. L’appelant est complétement isolé
des détails du dispositif et n’est pas concerné par les restrictions d’E/S imposées au dispositif.
L’opération loctl est utilisée pour manipuler les paramètres des drivers et du dispositif lors
de l’exécution.
Une application est concernée par seulement deux choses dans le contexte d’E/S uniforme :
le dispositif sur lequel on souhaite réaliser les opérations d’E/S et les fonctions (ou opérations)
présentées dans cette section. Le IO subsystem exporte cette ensemble d’API pour les
application.

3.2. La mise en relation des fonctions génériques vers les fonctions drivers.
Les drivers de composant individuel fournissent les vraies implémentations de chaque
fonction dans l’ensemble des API d’E/S uniforme. La figure suivante montre la relation
d’ensemble entre l’ensemble des API d’E/S et l’ensemble des fonctions internes.

7
Comme le montre cette figure, l’ensemble des API de IO subsystem a besoin d’être
mis en correspondance avec l’ensemble des fonctions qui est spécifique au driver de
dispositif pour n’importe quel driver qui supporte les E/S uniforme. Les fonctions qui
débutent par le préfixe driver_ à la figure précédente font référence à une
implémentation spécifique au driver de dispositif. L’ensemble des API d’E/S uniforme
peut être représenté dans une syntaxe de type langage C comme une structure de
pointeurs vers des fonctions comme indiqué ci-dessous.

Le processus de correspondance (mapping) implique l’initialisation de chaque

pointeur vers une fonction avec l’adresse de la fonction driver interne associée,
comme indiqué ci-dessous.

8
 Ces fonctions de driver interne peuvent avoir n’importe quel nom du moment que la
correspondance est correctement réalisée.
Un IO subsystem maintient habituellement une table des drivers d’E/S uniforme
(uniform I/O driver table). Chaque driver peut être installé ou retiré de cette table de
drivers en utilisant des fonctions spécifique que le IO subsystem fournit. La figure
suivante illustre ce concept.

Chaque ligne de cette table représente un unique driver d’E/S que supporte l’ensemble
des API définis. La première colonne de la table est un nom générique utilisé pour
associer le driver d’E/S uniforme avec un dispositif d’un type particulier. Dans la
figure précédente, un driver d’E/S uniforme est fourni pour un dispositif terminal ligne
série, tty. L’élément de la table à la seconde ligne et seconde colonne contient un
pointeur vers une fonction driver, tty_Create( ). Ce pointeur, en effet, constitue une
association entre la fonction générique create et une fonction create spécifique au
driver. Cette association sera utilisée plus tard lors de la création d’instance virtuelle
du dispositif.
Ces pointeurs sont écrits dans la table lorsqu’un driver est installé dans le sous-
système d’E/S, typiquement en appelant une fonction utilitaire pour l’installation du
driver. Lorsque cette fonction utilitaire est appelée, une référence vers cette nouvelle
entrée de la table des drivers est retournée à l’appelant.

3.3. L’Association des dispositifs avec les drivers de dispositifs.

La fonction Create(), déjà présentée dans les fonctions d’E/S standard, est utilisé pour
créer une instance virtuelle du dispositif. Le sous-système d’E/S conserve ces
instances virtuelles en utilisant la table des dispositifs (table device). La nouvelle
instance virtuelle crée recevra un nom unique et sera insérée dans la table des
dispositifs comme indiqué figure suivante. Cette figure illustre également la relation
entre la table des dispositifs et la table des driver.

9
Chaque entrée dans la table des dispositifs maintient une information générique, ainsi
qu’une information spécifique à l’instance. La partie générique peut inclure un nom
unique de l’instance du dispositif et une référence à la table des driver. Un nom
d’instance est construit en utilisant le nom générique du dispositif et un nombre
d’instance. Le dispositif nommé tty0 implique que ce dispositif d’E/S est un dispositif
terminal série et la première instance créée dans le système. La partie dépendante du
driver de l’entrée du dispositif est un bloc mémoire allouée par le driver pour chaque
instance afin de maintenir des données spécifiques à l’instance. Le driver l’initialise et
la maintient. Le contenu de cette information est dépendant de l’implémentation du
driver. Le driver est la seule entité qui peut accéder et interpréter cette donnée.

Une référence à la nouvelle entrée associée au dispositif nouvellement créé est

retourné à l’appelant de la fonction Create(). Les prochains appels de fonctions open
et destroy utiliseront cette référence.

10