Systèmes Embarqués Temps Réel - David Delfieu August 24, 2018 - Plate-forme d ...
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Systèmes Embarqués Temps Réel
David Delfieu
August 24, 2018
2
Contents
1 Définitions générales 5
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.1 Les aspects matériels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.2 Les différents choix de puces dans l’embarqué . . . . . . . . . . . . . . . . . . . 8
1.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1 Architecture Materielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.2 Architecture Logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Programmation Synchrone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.1 Code C, programmation Synchrone sur un micro-contrôleur . . . . . . . . . . . . 14
1.3.2 Aspect recherche et developpement autour du “synchrone” . . . . . . . . . . . . 15
1.4 Programmation Asynchrone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.1 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4.2 Les différent états d’une tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5 LINUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Programmation multi-tâche 19
2.1 Les Processus Unix System V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1 Création d’un processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.2 Création de plusieurs processus . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.3 Boucle de création de processus . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 La communication entre processus Unix . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1 Les pipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.2 Les pipes “non nommés” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.3 Les sémaphores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3 Les Threads Posix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.1 Création de thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.2 Protéger une variable globale accédèe par plusieurs thread, à l’aide d’un sémaphore 31
2.3.3 Tableau de threads et passage de paramètre . . . . . . . . . . . . . . . . . . . . 33
3 Système embarqué temps réel 35
3.1 La cible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.1 Boot de la cible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3
3.1.2 Configurer le boot : U-Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 La carte d’entrée-sortie : VMOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 VMOD_IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Les ports d’Entrées-sorties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.1 Driver caractère . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.2 Installation de Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.3 Drivers de nos cartes d’ES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.4 Installation du driver de la MTTL . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 ANNEXES 43
4.1 Connectivité IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.1 Le protocole IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.2 Les 7 couches du modèle OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.3 Le réseau Internet : 4 couches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.4 Applications NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.5 Applications ftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.6 Applications http . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4
Chapter 1
Définitions générales
1.1 Introduction
Les Systèmes Temps Réel (ST R) on été introduits avec le système de guidage de l’alunisseur des
missions Apollo. Aujourd’hui on trouve ces systèmes dans les objets les plus courant : régulateur
de vitesse, voitures autonômes smartphones, consoles de jeux, électroménager, GP S. Mais ces sys-
tèmes sont évidement présent dans l’avionique avec les systèmes de contrôle de vol et de guidage ou
dans le médical et surtout dans l’automobile dans lesquelles on peut trouver plusieurs centaines de
microcontrôleur ! Dans ces derniers domaines, la sureté de fonctionnement, la robustesse et la qualité
des informations produites sont des critères déterminants de conception qui priment par rapport à la
performance pure.
D’un point de vue matériel un ST R est composé de micro1 de mémoires de périphériques de sa
propre alimentation.
Definition 1.1.1 Les caractéristiques d’un Système Embarqué Temps réel sont en priorité la sureté
de fonctionnement (CEM, robustesse, redondance), des temps d’exécution de tâche qui doivent êtres
déterministes (où au pire, bornés), une consommation énergétique qui doit être est la plus faible possible
par rapport au service rendu et un encombrement du programme limité.
1.1.1 Les aspects matériels
Il y a deux grandes catégories matérielles de ST R : les cartes électroniques et les racks. Les cartes
électroniques sont généralement des petits systèmes qui embarquent des microcontroleurs voir des
microprocesseurs. Les racks portent eux, des cartes à microprocesseurs ou des System-on-Chip (SoC).
Les Principaux microprocesseurs de l’embarqué
Smartphones
1
On désigne par micro, tout composant comportant une unité de calcul : Microprocesseur, Microcontrôleur, DSP,
FPGA, SoC
5• L’Apple A6 est un système mono-coeur conçu conjointement par P.A. Semi et Intrinsity et
fabriqué par Samsung. L’entreprise affirme qu’il est jusqu’à deux fois plus rapide et jusqu’à deux
fois plus performant au niveau graphique que l’Apple A5. Il est intégré pour la première fois
dans l’iPhone 5, dévoilé le 12 septembre 2012.
• La puce A7 utilise l’architecture 64 bits ARMv8 basée sur un processeur bi-cœur et une unité
graphique intégrée (GPU). La micro-architecture ARMv8 double le nombre de registres du A7
comparé au A6. Le SoC A7 inclut plus de 1 milliard de transistors sur une puce de 102 mm2.
• Galaxy S6. Il dispose d’un processeur Exynos 7420. Samsung conçoit et fabrique ce circuit
intégré. Cette puce est gravée en 14 nm2 et gère les instructions 64 bits6. La puce contient 8
cœurs : elle est constituée d’une partie comprenant 4 cœurs ARM à 2,1 GHz et 4 cœurs ARM à
1,5 GHz2.
• Galaxy S7 : Pour les États-Unis, Le S7 et S7 Edge se doteront du Snapdragon 820 de Qualcomm.
Pour l’Asie de l’Ouest, ce sera le Exynos G930FD et dans le reste du monde, le Exynos 8890
(tous deux produits par Samsung).
Autres Systèmes Embarqués GPS, radars mobiles, robots, ... Autant de ST R sont des systèmes
embarqués qui contiennent soit des microprocesseurs spécifiques, soit des “System on Chip”.
Microprocesseurs :
• Intel Medfield, intel ATOM, intel Core2Duo, Intel i3, i5, i7.
• PowerPC (anciennement Apple, IBM, Freescale).
• AMD Geode, AMD Fusion G-series.
System on Chip (SoC) : Les SoC sont des composants dont le design de base est souvent
achété (cas des coeurs ARM) puis personalisés. C’est le cas d’Apple et Samsung qui achètent des
coeurs à ARM puis les particularisent. Pour apple, c’est ensuite Samsung qui les réalise !! Pour les
Soc plus petits : FPGA et CPLD, il existe des logiciels qui permettent d’implanter ou de définir des
architectures processeurs.
Les Principaux microcontrôleurs de l’embarqué
Microcontroleurs La dernière catégorie à puce relève des systèmes basés à partir de micro-contrôleurs
: Les automobiles embarquent aujourd’hui entre 30 (entrée de gamme) et 250 micro-contrôleur(modèles
de luxe) : une par fonction, comme le lève-vitre ou l’essuie-glace mais aussi pour les fonctions de sécu-
rité comme l’ABS ou l’airbag.
• ATmega*** (ATMEL),
• PIC (Microchip),
6• M68HC*** (Motorola),
• ST10F*** (ST-Microelectronics)
Microcontroleurs dédiés au Traitement du signal
• Texas Instrument : C5000,C6000
• freescale ;
• Microchip : dsPIC30F et dsPIC33F
• Qualcomm
Figure 1.1: carte micro : microP, microC, DSP, FPGA
Les systèmes sur étagères : "Rack"
Quand il n’y a pas de problème de consommation et ni d’espace que l’on exige une grande puissance de
calcul ainsi qu’une très grande tolérance aux pannes, une forte sureté de fonctionnement et que de plus,
ni le poids ni les dimensions on peut trouver des systèmes sur étagère. On trouves ces équipements
dans le transport : les avions, trains, bateaux, centreaux de communication.
Figure 1.2: système de Rack
Les systèmes "rackables" diffèrent par leur format :
• Carte PC/104, taille standard : 90,17 x 95,89 mm ;
• Carte compact PCI ;
7Figure 1.3: Un rack 5U
Figure 1.4: Un Rack 3U
• Carte Europe ;
• Carte bus VME.
Les caractéristiques du système vu en TP sont :
• Rack 3U et 5U ;
• Alimentation propre ;
• Carte bab740 : Microprocesseur de type PPC ;
• 1 carte d’E/S ;
• format VME ;
1.1.2 Les différents choix de puces dans l’embarqué
Le marché des semi-conducteurs pesait 341 milliards en 2015 dont 90 milliards pour les micro. Et
l’electonique représente 25 % du cout d’une automobile ! 10% d’un avion. Dans ce marché, les “PC”
représente à peine 3,5 milliards de dollars (80% intel, 10% AMD, 10 % autres), tandis que les cartes
vidéos, consoles, téléphones représente environ 4 milliards de micro : ARM = 80%: (Apple et Samsung)
90 % des micro pour l’embarqué utilisent autre chose que Windows.
1.2 Architecture
1.2.1 Architecture Materielle
1.2.2 Architecture Logicielle
Un SETR est un système bouclé multi-tâches dont le temps de réponse est adéquat avec la dynamique
de son environnement. Un exécutif temps réel est un système d’exploitation minimal ajusté au hard-
ware auquel il est destiné. Seuls les drivers justes nécessaires sont inclus dans l’exécutif. De même,
8Entités Caractéristiques Avantages
PORT d’E/S Configuration d’E/S Accés direct
aux actionneurs
et aux switch
CAN Conversion AN signaux numériques
Communications Port SPI, UART pas de périphériques externes
I2C, bus CAN
Timers et PWM Tempo signaux périodiques mise en oeuvre facile
Codage boucle, tableaux, Efficace
Interruptions
Table 1.1: Les micro-contrôleurs
Table 1.2: Data Signal Processor
Entités Caractéristiques Avantages
Filtres logiciels MAC gain Hard
Interfaces Codecs Ports Séries rapides gain Hard
Gros débits DMA Moins d’attente
Accés données programme Architecture Harvard Exécution rapide
Table 1.3: Les micro-contrôleurs de traitement du signal
Table 1.4: Microprocesseur
Besoin micro et petit Moyen/Gros Embarqué critique
RAM 100ko < x < 4M o 4M o < x < 64mo Go - To
FLASH 100ko < x < 4M o 8M o < 16M o Go - To
Proc. Dragon Ball : 68K MIPS Pentium
Mcore Hitashi SH PowerPC
Coldfire X86 Crusoe
ARM
Carac. MMU optionnelle Carte mère PCI,VME, ...
Appli. PDA, Portable Routeur Commutateur tél.
Caméra numérique Stockage réseaux Serveur central
Imprimante réseaux Gros routeur
Table 1.5: Les microprocesseurs
9Mémoire Timer
FPGA UART
PWM
Capteurs CAN CPU CNA Actionneurs
In
Interface utilisateur
PC Hôte
Environnement
Exterieur
seuls les services systèmes nécessaires sont dans l’exécutif. Ce système multi-tâches est ordonnancé
par un exécutif temps réel. Les tâches et l’exécutif sont compilées dans le même exécutable appellée :
image. Un SETR aura un temps de réponse adéquat si la somme du temps d’acquisition, de traitement
et d’application de la commande est inférieure à la période d’échantillonage de l’information. Pour
cela il faut que l’exécutif soit déterministe et préemptif. Une application de contrôle commande est
généralement décomposée en tâches.
Definition 1.2.1 Une tâche correspond à une fonctionnalité logicielle et matérielle comportant peu
d’interactions avec les autres tâches et dont la granularité définie une complexité permettant une im-
plémentation rapide.
Exemple
Par exemple prenons le cas d’une régulation en courant d’une Machine à Courant Continu (MCC). On
désire pouvoir par une saisie de consigne en courant, maintenir constant un certain courant quelque
soit la charge appliquée sur l’axe de la MCC., On peut décomposer cette application en trois tâches :
• Une tâche d’acquisition de la consigne ;
• Une tâche d’échantillonnage lecture du courant ;
• Une tâche de calcul et d’application du correcteur ;
Nous allons maintenant traiter cet exemple au travers de deux axes méthodologiques différents :
Synchrone et Asynchrone.
101.3 Programmation Synchrone
Une programmation “synchrone” partage une application en tâches qui sont lancées de façon synchrones
par rapport à des évènements correspondant généralement à des interruptions.
Programmation SYNCHRONE
Programme Principal
IT Timer SPIT Timer
...
IT Externe ...
IT CAN
SPIT IT Externe
...
...
SPIT CAN
...
...
Exemple
Pour implémenter l’exemple, on découpe l’appllication en plusieurs tâches :
• Programme principal qui initialise les différents périphériques et le timer, puis il ne fait rien (ou
pas grand chose) ;
• La tâche d’acquisition de consigne : durée 30 µs, appelée toutes les secondes ;
• La tâche d’acquisition du courant : durée : 30 µs, appelée toutes les 200 µs;
• La tâche de calcul et d’application du correcteur : durée : 100 µs, appelée toutes les 200 µs;
Chaque tâche est lancée de façon synchrone avec un évènement d’interruption dans un sous-
programme d’interruption. On peut aussi envisager d’effectuer plusieurs sous-taches dans un pro-
gramme d’interruption à condition que ces sous-tâches ne soient pas bloquantes.
Lecture Consigne 30 μs
TLc= 1 s 30 μs
30 μs 30 μs 30 μs 30 μs 30 μs 30 μs 30 μs 30 μs 30 μs 30 μs
Lecture Courant IM
TIM=200 μs
Calcul Correcteur 100 μs 100 μs 100 μs 100 μs 100 μs 100 μs 100 μs 100 μs 100 μs 100 μs
TCC=200 μs
Tâche en traitement
Tg=200 μs
Déroulement de tâches en Programmation Synchrone
Figure 1.5: Exemple d’ordonancement préemptif
11Le code suivant, est un exemple de programmation synchrone en assembleur pour un micropro-
cesseur 68000. On y remarque le programme principal et les sous-programmes d’interruption.
ORG $0FF0000
LEA PILE(PC),A7
INITPIA CLR.B CRB Le Port B commande les Timers
MOVE.B #$1F,DDRB
MOVE.B #4,CRB
CLR.B CRA
MOVE.B #7,DDRA
MOVE.B #4,CRA
PEA IT3(PC)
MOVE #27,-(A7)
MOVE #5,-(A7)
TRAP #13
ADDQ.L #8,A7
PEA IT2(PC)
MOVE #26,-(A7)
MOVE #5,-(A7)
TRAP #13
ADDQ.L #8,A7
************** LES initialisation des 3 TIMERS **********************
* CPT0 de U1 : periode de hachage PWM : 125 us f = 1 Mhz
MOVE.B #$14,CRW
MOVE.B #125,CPT0
MOVE.B #$16,CW
MOVE.B #125,CT0
MOVE.B #$96,CW 10 01 | 011 0 generation du signal convst
MOVE.B #125,CT2
CLR.B ORA * aiguillage du multiplexeur analogique
************** * Les activations des IT et Timers **********************
MOVE.B #5,CRA IT3
MOVE.B #5,CRAx IT2
MOVE.B #11,ORB * mise en route de G10,G20 et G22
LOOP BRA LOOP La Boucle Infinie
TRAP #0
**************** IT Num 2 : Le Calcul du correcteur ***********************
IT2 MOVE.L #IREF,D0 Temps Execution = 60 us
ASL #1,D0 D0 = 2 * IREF
SUB.L D2,D0 D0 = 2IREF - 5IMn = EPSn
MOVE.L D0,D3 D3 = EPSn
ADD.L D4,D3 D3 = In = In-1 + EPSn D4 = In-1
MOVE.L D3,D5 D5 = In
MOVE.L D3,D4 D4 = In-1MOVE.L #10500,D7 D1
1.3.1 Code C, programmation Synchrone sur un micro-contrôleur
Le code suivant, est un exemple de programmation synchrone en C pour un microcontroleur ATMega8.
On y remarque le programme principal (main) et les sous-programmes d’interruption (ISR).
#include
...
void sleep(int dzs){for(int i=0;iAu niveau des avantages, la programmation est très efficace car prôche du hard. Sa structure est
minimale donc très performante. Il n’y a pas d’exécutif donc pas d’ordonnancement et le comportement
est de ce fait déterministe.
Par contre, il est difficile de faire évoluer le système. Si l’on veut rajouter une tâche, on doit avoir
une source d’interruption supplémentaire. De plus, le temps d’exécution de la nouvelle tâche doit être
“compatible” avec les autres temps d’exécutions.
Dans l’exemple : On a une periode globale de 100µs. A ces instants on a au plus : 3 tâches avec
100 + 30 + 30 = 160µs. Le temps dexécution le plus grand est donc de 40µs.
Sur une architecture synchrone les coûts de développement sont très importants : La programma-
tion de ces systèmes nécessite une maîtrise complète de la partie hardware. En effet, Ces systèmes
intimement liés au hardware sont généralement développés au moins en partie en assembleur et en
C ce qui augmente encore les coûts de développements et de maintenance. La lisibilité du code est
souvent faible (assembleur, code très lié au hard) et le code n’est pas portable.
1.3.2 Aspect recherche et developpement autour du “synchrone”
Des langages spécifiques dit “synchrones” ont été développés dans des laboratoires de recherche. Ils
restent cantonnés à des programmes de recherche et développement des très grandes entreprises comme
Airbus ou Boing mais restent très peu utilisés dans le reste de l’industrie.
Definition 1.3.1 Langages Synchrones : Esterel, Lustre, Statecharts Ce sont des langages à haut
niveau d’abstraction dont les instructions de bases manipulent des évènements. Ils sont qualifiés de
"synchrones" car ces évènements jouent le rôle de marqueurs temporels. Ils sous-entendent la présence
d’une horloge d’échantillonnage temporel permettant de les synchroniser.
1.4 Programmation Asynchrone
La programmation asynchrone implique l’utilisation d’un système d’exploitation (SE ou OS en Anglais).
Un système d’exploitation permet, de gérer les tâches de l’application : Il décide de lancer les
tâches, il attend leur comptes rendus d’exécution, les interrompt pour ne lancer d’autres : On parle
d’ordonnancement. L’OS gère, de plus, tous les éléments physiques ou logiciels du système tel que
la mémoire, les entrées sorties du système et la communication avec l’exterieur. La gestion de pé-
riphérique est faite à l’aide de driver. Les tâches peuvent être implémentés (en C sous Unix/LINUX)
par des processus ou des threads.
Le style asynchrone de conception d’une application offre une structure souple : On peut ajouter
ou supprimer des tâches de façon simple. Le code est lisible (langage haut niveau tyoe C) et détaché
du hard, la maintenance est donc plus aisée et le code est portable sur d’autres système ou processeurs.
La communication avec le hard se fait via des drivers. Et suivant les drivers portés dans le noyau on
va pouvoir faire des tâches de très haut niveau : Protocole TCP/IP, telnet, serveur http, ...
Quant aux inconvénients : L’image intègre un mini système d’exploitation (qlqs Mo) en plus de
l’application et cet OS rend le système moins performant à cause des changements de contextes (cf
figure 1.5.1). De plus, le comportement temporel n’est pas forcement déterministe. Une tâche moins
urgente peut s’exécuter avant une autre qui est plus urgente ! Du déterminisme temporel peut être
15réablit ou forcé pour un nombre restreint de tâches de haute priorité. Pour atteindre un même niveau
de déterminisme en asynchrone qu’en synchrone : il faut un processeur beaucoup plus puissant donc
plus consommateur d’énergie électrique et plus de mémoire.
1.4.1 Ordonnancement
Le rôle principal d’un OS est d’ordonnancer les tâches. Généralement les OS ont une politique qui essaie
de servir de façon plus ou moins équitable l’ensemble des tâches. Pour cela est définit un intervalle de
temps très court : ordre de la milliseconde, appelé quantum. Chaque expiration de quantum, provoque
l’interruption de la tâche en cours et l’election par l’OS d’une nouvelle tâche ce qui donnera, comme
le quatum est petit, l’impression que toutes les tâches s’exécutent en même temps. Cette impression
sera d’autant plus importante que le nombre de coeur est important. En effet, sur une architecture
muti-coeur, les tâches seront en plus distribuées sur les différents coeurs.
Une tâche dispose d’un quantum de temps. Au bout de ce quatum elle est preemptée par l’OS.
Elle peut se terminer avant l’expiration du quantum, par une fin naturelle ou être bloquée par une
demande d’une entrée-sortie bloquante. Le quantum permet d’assurer une redistribution régulière des
ressources CP U . Dans la figure suivante, toutes les tâches évoluent de concert.
Lecture Consigne
Lecture Courant
Calcul Correcteur
Tâche en traitement
Election d'une nouvelle tâche à éxecuter : Surcoût temporel
Figure 1.6: Exemple d’ordonancement préemptif
Exemple d’ordonnancement :
1.4.2 Les différent états d’une tâche
• Activer : La tâche entre dans un processus électif : File d’attente des tâches "Prêtes";
• Démarrer : Le tâche en tête de la FA "Prête" est élue, elle a 100% du CPU ;
• Arrêter : Le tâche est interrompue, elle a terminée son quantum de temps ;
16Non planifiée
Activer Terminer
Continuer
Terminer Tâche Prête Bloquée
Suspendre
Démarrer Arrêter
Tâche en traitement
Suspendre
Les Différents états d'une tâche
• Suspendre : Le tâche a demandé une ressource non encore disponible ou s’est endormi elle-même
(sleep) ;
• Continuer : La ressource demandée est maintenant disponible ou le sommeil est terminé, le tâche
rentre à nouveau dans la FA "Prête".
• Terminer : Le tâche s’arrête définitivement par l’appel à exit ou return. Elle peut aussi recevoir
un signal de fin émis par une tâche en traitement.
1.5 LINUX
1.5.1 Historique
Pourquoi LINUX ? Linus Thorvald introduit un OS multitâches comparable à UNIX sur des ordinateurs
PC vers mla fin des années 80.
• LINUX est dérive d’UNIX, un OS fiable du marché ;
• LINUX est libre : le source est disponible sans royalties à reverser ;
• LINUX est foisonnant : de nombreux contributeurs, développeurs le font évoleur et fournissent
une aide rapide ;
• Les versions stables de linux sont FIABLES ;
• LINUX offre une connectivité IP en standard.
LINUX : sur quel système ?
• Linux est décliné sur un grand nombre d’architecture :
Pentium x86, PowerPC, ARM, MIPS, 68000, Coldfire,...
17• Taille du noyau est modeste 500ko (au minimum) à plusieurs dizaine de mégaoctets;
• Différentes distributions sont proposées suivant le domaine :
routeur IP, PDA, portable, ...
• Chargement de modules dynamiques : optimisation taille noyau ;
• Migration aisée de linux à Linux Embarqués.
Historique
• 1991 : la première version de Linux est développé par Linus Torvalds;
• 1999 : Présentation à Linux World d’un système compact PCI sous linux ;
• 2000 : Embedded Linux Consortium : centralise des solutions Linux embarqués ;
• Aujourd’hui : des solutions libres ou commerciales sont concurrentes.
• Solutions libres :
– RTLinux,
– RTAI.
• Solutions propriétaires:
– VxWorks,
– pSOS,
– QNX.
18Chapter 2
Programmation multi-tâche
Deux mécanismes de programmation C sous Unix, permettent d’implémenter la notion de tâche, les
processus et les threads. Ces deux mécanismes apparaissent aussi dans d’autres langages et d’autres
systèmes d’exploitations. On trouve les notions de processus ou de thread en Java par exemple sous
windows. Si les processus/threads Linux correspondent à ceux d’UNIX, ceux de Windows ne corre-
spondent pas tout à fait. Un standard définit ce qu’est un processus ou un thread. Le standard des
processus Unix se nomme les processus Unix System V. Celui des threads se nomme les thread Posix.
2.1 Les Processus Unix System V
Un processus est une implémentation en langage C de la notion de tâche. Un processus est une entité
possédant :
Un contexte d’exécution :
• Un ensemble sauvegardé de valeurs des registres du processeur ;
• une zone mémoire associé au code exécutable ;
• une zone de mémoire dynamique privé ;
• une zone pour la pile.
Un environnement d’exécution :
• Les fichiers ouverts,
• sa priorité d’exécution,
• un processus est identifié par un numéro : PID.
• ...
19fork()
père fils
PID PID
PPID PPID
Desc. Fichiers Duplication Desc. Fichiers
Zone de pile Zone de pile
Zone de data Zone de data
Zone programme Zone programme
même programme
même valeurs des variables (valeurs d'avant le fork)
MAIS ces codes coexistent à une adresse différente
et les variables appartiennent à des espaces mémoires différents
Figure 2.1: fork
2.1.1 Création d’un processus
La primitive fork() (cf la figure 2.1) fait partie du paquettage standard "stdio.h"
• Duplication quasi-complète du patrimoine du père ;
• Le "fils" se distingue par :
– La valeur retournée par l’appel système fork() : 0 pour le fils et le pid du fils chez le pere
– son PID ;
– son PPID ;
– sa zone programme, data et pile ;
– ses propres descripteurs de fichiers ouverts.
2.1.2 Création de plusieurs processus
Un père, un fils
main() {
int i,PID,res;
PID=fork();
if (!PID) { /* Chez le fils */
for(i=0;i}
else { /* chez le pere */
for(i=0;i/*Le PERE travaille */
travaille(iteration);
printf("Je suis le pere j’ai fini, j’attends la terminaison de mes fils \n");
for (int j=0;jprintf("\n\n\nJe suis le pere et je m’appelle %d\n",getpid());
for(i=0;i• User time : temps CPU utilisé uniquement par le programme utilisateur
• Sys time : temps utilisé uniquement par le système pour gérer l’exécution de tous les jobs pendant
l’exécution du processus
Elapsed time = Temps du programme utilisateur + temps système + temps utilisé par les autres
tâches
La commande ps : Processus state donne les processus du système et différentes informations
(PID, temps d’écution, nom ou commande correspond au processus ...). Tandis que la commande kill
-9 associée à un PID permet de tuer un processus.
2.2 La communication entre processus Unix
Les processus peuvent communiquer à travers deux outils de communication : Les pipes et les Sockets.
Nous allons étudier les pipes.
Processus Processus
Producteur Consomateur
TUBE
Figure 2.2: Information circulant dans un pipe
Principe
2.2.1 Les pipes
Un pipe est un mécanisme qui transporte une information ou une donnée dans un seul sens à la fois
(cf fig. 2.2). Le producteur producteur envoie des données qui circulent dans un tuyau “virtuel” vers
le processus consomateur. On le nomme pipe ou tuyau en français, car les informations ne peuvent
pas se doubler. Une info A émise arrivera avant l’info B émise après A. C’est un mécanisme First In
First Out.
Les processus peuvent changer de rôle, celui qui était consomateur peut devenir producteur et
l’autre peux devenir consommateur, à condition aussi que les processus modifient leur usage du pipe.
Par contre on ne peux pas avoir les deux processus producteurs ou les deux processus consomateurs
en même temps. Dès lors qu’une communication est établie, un pipe fonctionne à sens unique.
Ce qui est singulier dans le pipe est que l’information disparaît après lecture. C’est pour cela que
l’on utilise le vocable de producteur/consomateur. Le producteur produit de l’information qui sera
retirée du pipe par le consommateur.
Il existe deux catégories de pipes :
24• Les pipes “non nommés” utilisables entre processus parents qui partagent le même environ-
nement. Comme ces processus partagent le même environnement ils peuvent se transmettre les
caractéristiques des pipes sans difficulté.
• Les pipes “nommés” employés pour les communications entre processus sans liens de parenté. Ils
s’apparentent à des fichiers en mémoire. Le fonctionnement est sensiblement le même. Ce sont
des fichiers d’un type spécial à usage interne pour la communication entre processus. Le processus
Consommateur, lorsqu’il se met en attente de lecture d’une information que le Producteur doit
lui transmettre à travers le pipe, se synchronise sur ce dernier. Il reçoit, de plus, un message qui
peut être utilisé pour diriger ses actions.
2.2.2 Les pipes “non nommés”
Si un pipe est nommé, il peut donc être partagé entre un père et sa toute descendance. Soit p le nom
du pipe :
• p[0] : sortie du pipe, c’est par la que l’on retire de l’information
• p[1] : entrée du pipe c’est par la que l’on dépose de l’information
Pour comprendre leur fonctionnement, en voici un exemple réduit à sa plus simple expression.
On crée un pipe par la fonction pipe() puis un processus fils par fork(). Ce fils hérite de tout
l’environnement du père donc du pipe et de ses caractéristiques. Dans un pipe, p[0] représente la
sortie du pipe et p[1] l’entrée du pipe. Dans les deux processsus, un doit être le producteur et l’autre
le consommateur. Le producteur ferme le pipe en lecture par close(p[0]), pour lui le pipe ne peut donc
plus servir qu’en écriture. Celle-ci se fait par la fonction write() qui comprend trois arguments :
• La structure d’écriture p[1] du pipe
• La chaîne à transmettre
• Le nombre de caractères de la chaine.
Si il a terminé sa production le producteur peut fermer p[1].
Le deuxième fils créé, le consommateur, est employé pour lire les informations envoyées par le
producteur. Ce consommateur ferme le pipe en ecriture par close(p[1]), pour lui le pipe ne peut donc
plus servir qu’en lecture. Celle-ci se fait par la fonction read() qui comprend trois arguments :
• La structure de lecture p[0] du pipe
• La chaîne qui receptionne l’information
• Le nombre de caractères que le consommateur désire recevoir.
Si il a terminé sa production le consommateur peut fermer p[0].
25#include
#include
main() {
int fils1, fils2, m, n, p[2], count; char buf[6];
pipe(p);
/* creation premier fils : Le producteur */
if ((fils1=fork())== 0){
char c;
close (p[0]);
fprintf(stdout,"(%d) est le Producteur: \n",getpid());
do {
scanf("%c",&c);
write(p[1],&c,1);
} while (c!=’T’);
close(p[1]);
fprintf(stdout,"fin production \n");
exit(2);
}
/* creation du deuxieme fils : Le consommateur */
else if ((fils2=fork())==0){
fprintf(stdout,"fils2 (%d) : lit ds pipe\n",getpid());
close (p[1]);
do{
count = read(p[0],lu,1);
printf("\t \t \t \t LU : %c\n",*lu);
}while (*lu != ’T’);
fprintf(stdout,"fin de consommation \n");
exit(3);
}
else{
fprintf(stdout,"processus pere %d\n",getpid());
close(p[0]);
close(p[1]);
fprintf(stdout, "wait fils : %d\n",wait(&m));
fprintf(stdout, "wait fils : %d\n",wait(&n));
fprintf(stdout, "fin du pere\n");
exit(0);
}
}
262.2.3 Les sémaphores Definition 2.2.1 (Semaphore) Un sémaphore est un object permettant à N processus ou thread (tâche) d’accéder à une même région de code ou a une ressource critique Pour cela un sémaphore est un objet qui permet les actions suivantes : • L’initialisation • Le processus de réservation : semP • Le processus de libération : semV Code de SemP: Masquer toutes les ITs; S--; if (S File_Attente(S); reordonnancement(); } Demasquer toutes les ITs; Code de SemV : Masquer toutes les ITs; S++; if (S
extern int getpid();
extern int fork();
extern void sleep();
extern int wait();
int ecran; /*semaphore */
void imprime() {
sem_P(ecran);
for (int i=0;ipeux utilser un logiciel pu composant informatique. C’est donc un ensemble de fonction typée (décrites
dans un *.h) qui indique comment on peut interagir avec le composant. Les threads implémentent la
norme POSIX. Ceux sont des processus légers car ils ont été créés par un processus père avec qui ils
partagent avec lui le même espace mémoire.
Ils ont les caractéristiques suivantes :
• Ils peuvent avoir des variables communes (globales) et des variables locales ;
• Ils partagent les mêmes fichiers et les mêmes ressources ;
• Ils ont leur propre pile d’exécution ;
• Ils sont ordonnancés ;
Voir le code : API "pthread.h"
2.3.1 Création de thread
int pthread_create(pthread_t *thread,
const pthread_attr_t *attr,
void *(*start_routine)(void *),
void *arg);
• thread : identifiant, descripteur du thread ;
• attr : attribut de création ;
• start_routine : fonction constituant le corps du thread ;
• arg : argument de la fonction.
void pthread_exit(void *value_ptr) ;
int pthread_join(pthread_t thread,
void **value_ptr) ;
value_ptr : valeur de retour au père. thread : identifiant
Voir le code : thread2.c
Deux threads qui partagent et modifient une même variable globale peuvent provoquer un com-
portement non déterministe de l’application.
#include
#include
#include
#include
#include
#define NBITER 11000
29unsigned int globale=0;
void *ligne1(void *arg);
void *ligne2(void *arg);
int main(){
int res;
pthread_t l1, l2;
char c;
//***************************************************************************
res=pthread_create(&l1, NULL, ligne1, NULL);
//***************************************************************************
if (res == -1) {
perror(" erreur de creation du thread\n");
exit (EXIT_FAILURE);
}
//***************************************************************************
res=pthread_create(&l2, NULL, ligne2, NULL);
//***************************************************************************
if (res == -1) {
perror(" erreur de creation du thread\n");
exit (EXIT_FAILURE);
}
printf("attente des fils\n");
pthread_join(l1,NULL);
pthread_join(l2,NULL);
printf("Fin du père, valeur finale de la variable globale = %d\n",globale);
exit(EXIT_SUCCESS);
}
void *ligne1(void *arg) {
for(int i=0;iglobale=globale+10;
}
printf("Fin du fils2\n");
pthread_exit(NULL);
}
2.3.2 Protéger une variable globale accédèe par plusieurs thread, à l’aide
d’un sémaphore
Pour assurer un accès atomique à une variable globale on va s’assurer que l’on ne sera pas interrompu
lorsque l’on modifie la variable. L’usage d’un sémaphore va premettre :
1. Eviter une élection par l’ordonnanceur dans une région.
2. Eviter toute interruption.
3. Masquer les interruptions en début de région et les démasquer en fin de région
#include
#include
#include
#include
#include
#include "semaphore.h"
#define NBITER 11000
unsigned int globale=0;
int ecran;
void *ligne1(void *arg);
void *ligne2(void *arg);
int main(){
int res;
pthread_t l1, l2;
char c;
sem_init();
ecran=sem_creer(1);
//***************************************************************************
res=pthread_create(&l1, NULL, ligne1, NULL);
//***************************************************************************
31if (res == -1) {
perror(" erreur de creation du thread\n");
exit (EXIT_FAILURE);
}
//***************************************************************************
res=pthread_create(&l2, NULL, ligne2, NULL);
//***************************************************************************
if (res == -1) {
perror(" erreur de creation du thread\n");
exit (EXIT_FAILURE);
}
printf("attente des fils\n");
pthread_join(l1,NULL);
pthread_join(l2,NULL);
sem_detruire();
printf("Fin du père, valeur finale de la variable globale = %d\n",globale);
exit(EXIT_SUCCESS);
}
void *ligne1(void *arg) {
for(int i=0;i2.3.3 Tableau de threads et passage de paramètre
Boucle de création de thread. On va faire un travail à chaque thread qui est différent grâce à la variable
i. On utilise un sémaphore pour que chaque thread écrive sur une seule et même ligne.
#include
#include
#include
#include
#include "semaphore.h"
#define N 5 // nombre de threads
int ligne;
void *imprime(void *k){
int p=(int) k+5,j=0;
sem_P(ligne);
for(j=1;j34
Chapter 3
Système embarqué temps réel
3.1 La cible
La cible est un rack 5U ou 3A relié au PC par le réseau et par une liaison série. On y accède par son
adresse IP. Dans ce rack, on peut y ficher 3 à 5 cartes, dont une est la carte processseurs et les autres
des cartes d’entrées-sorties. On doit tout d’abord booter la cible comme on le ferait pour un PC.
3.1.1 Boot de la cible
Remarque 3.1.1 Boot Le boot c’est l’amorçage d’un système hardware par un programme appelé
bootloader. Le bootloader va chercher sur un périphérique (Disque Dur, Clef USB ou le réseau) un
exécutif qui s’installera en mémoire vive et appellera lui-même des programmes applicatifs.
Remarque 3.1.2 bootloader et MBR Le bootloader d’un PC est un programme placé dans le Master
Boot Record (MBR) qui réalise le boot. Le MBR est la zone d’amoçage d’un PC. Elle contient la table
des partitions (les 4 partitions primaires) du disque dur et le bootloader dont le but est de charger le
système d’exploitation.
3.1.2 Configurer le boot : U-Boot
Remarque 3.1.3 U-Boot U-Boot est un bootloader (logiciel libre), permettant de loader un exécutif
linux par le réseau (Ethernet). U-Boot implémente le protocole TFTP. U-Boot fonctionne sur des
centaines de cartes mère et a été développé pour la très grande majorité des processeurs existant :
PowerPC, ARM, XScale, MIPS, Coldfire, NIOS, Microblaze, et x86.
Proposition 3.1.1 TFTP Trivial File Tranfer Protocol : ce protocole permet de faire des transfert
de fichiers d’une machine à une autre. Il est basé sur l’architecture Client Serveur.
Commande de U-Boot : printenv
printenv : Cette commande affiche l’ensemble des variables de l’environnement.
35=> printenv
baudrate=9600
bootdelay=5
stdin=serial
stdout=serial
netmask=255.255.255.0
ipaddr=172.22.64.170
serverip=172.22.64.172
Environment size: 992/16380 bytes
=> printenv ipaddr netmask
ipaddr=172.22.64.170
netmask=255.255.255.0
=>
Commande de U-Boot : setenv
setenv : Cette commande permet de définir une variable ou de supprimer une variable.
usage :
=> setenv nom valeur
permet de definir la variable nom avec valeur
=> setenv nom
permet de supprimer la variable valeur
Autre exemple :
=> setenv cons_opts console=tty0 console=ttyS0,${baudrate}
=> printenv cons_opts
cons_opts=console=tty0 console=ttyS0,${baudrate}
Commande de U-Boot : saveenv
Permet de sauvegarder de façon persistante dans la mémoire flash, toutes les valeurs des variables
positionnées par la commande setenv.
=> saveenv
Saving Enviroment to Flash...
Writing to Flash... done
=>
Commande de U-Boot : tftpboot
tfypboot : boote l’image par le réseau suivant les variables définies par setenv. Elle va chercher l’image
sur $serverip
=> help tftpboot
tftpboot [loadAddress] [bootfilename]
363.2 La carte d’entrée-sortie : VMOD
Spécifications générales
• On a une carte porteuse VMOD_IO : proposant 4 emplacements en mezzanine pour des cartes
filles ;
• Cette carte porteuse réalise l’interface avec le Bus VME ;
3.2.1 VMOD_IO
Sur les 4 emplacements on a :
1. deux cartes VMOD_TTL ;
2. une carte VMOD_12E816 : carte d’entrée Convertisseur analogique-numérique ;
3. une carte VMOD_12a4 : carte de sortie Convertisseur numérique-analogique ;
3.2.2 Les ports d’Entrées-sorties
Les Ports A, B et C
VMOD_TTL
Les 3 ports A, B et C :
Cette carte sur un bus V M E via une interface de type M ODU Lbus+ propose 2 ports 8 bits et un
port 4 bits.
• 20 entreées-sorties T T L optocouplées ;
• Les 3 ports sont configurables en entrée ou en sortie.
• Chaque bit du port peut fournir un courant max de 48 mA il est de type collecteur ouvert ;
• A chaque port doit être alimenté.
• Fonction secondaire timer (Zilog Z8536) sur les ports B et C.
37VMOD_TTL VMOD_12E8/16 VMOD12A4
2O ES TTL 12 Entrees Analogiques 4 sorties Analogiques
16 bits
VMOD_TTL
PORT C
PORT B
PORT A
Vcc/Gnd
383.3 Drivers
Definition 3.3.1 Driver Un Driver (module) est un programme écrit généralement en Assembleur
permettant de lire et d’écrire sur un périphérique ou de réaliser des actions appellées "services". Un
module fournit des services ou utilise des services d’autres modules.
Le cas des drivers linux :
• Statique : Les modules sont rajoutés dans la partie "File System" et compilé avec le noyau. Il
sera présent même si le périphérique n’est plus utilisable
• Dynamique : On alors un "module chargeable", les modules/drivers ne sont chargés QUE lorsque
un programme en a besoin.
Il existe différents types de pilotes suivant le périphérique à contrôler:
• les pilotes en mode caractère
Ex : ports séries et parallèles
• les pilotes en mode bloc
Ex : Disque dur.
• les pilotes réseaux
3.3.1 Driver caractère
Avec ce matériel de TP, on n’utilisera que des pilotes en mode caractère. Ces pilotes sont accessibles
à travers des fichiers spéciaux appelés également noeuds (nodes). Ces fichiers sont localisés sur le
répertoire /dev et sont caractérisés par deux valeurs numériques :
• Le MAJEUR (MAJOR) qui identifie le pilote
• Le MINEUR (MINOR) qui représente une sous-adresse en cas de présence de plusieurs pé-
riphériques identiques, contrôlés par un même pilote.
3.3.2 Installation de Drivers
Le fichier /etc/rc.sysinit permet de réaliser des installations des drivers/modules spécifiques.
• La commande depmod a :
Elle établit la liste des dépendances de modules en lisant pour tous les modules les services
exportés ou importés.
• La commande insmod programme simple permettant d’insérer un module dans le noyau sans
s’occuper de dépendances éventuellement non satisfaites.
• La commande modprobe programme simple permettant d’insérer un module dans le noyau.
modprobe charge un module et les modules qui en dépendent.
• rmmod décharge un module
393.3.3 Drivers de nos cartes d’ES
#depmod a
#insmod copy_universe
#modprobe universe #modprobe vme_mod log = 4 level = 3
#modprobe modvme
#modprobe v modat0
3.3.4 Installation du driver de la MTTL
#modprobe mttl.o io = 62, 0, 0, 0x3000a800, 0xa0, 0xd
• 62 : major number : celui de la carte M T T L
• 0 : num. carte V M ODIO sur bus V M E 2 [0, 15]
• 0 : minor number emplacement de M T T L sur V M ODIO 2 [0, 3]
• 0x3000a800 adr physique carte V M ODIO sur bus V M E
• 0xa0 : adresse du vecteur d’IT
• 0x0d : 0000 1101
1101 : 1: Opto, 1: C en sortie, 0: B en entrée, 1: A en sortie
Drivers de nos cartes d’ES
Installation des deux cartes T T L :
#insmod mttl v io = 62, 0, 0, 0x3000a800, 0xa0, 0xd 62, 0, 0, 0x3000a800, 0xa0, 0xd
Exemple simple de Driver Linux
Ecriture du driver hello.c:
#include
#include
int init_module(void)
{
printk("Driver chargé n");
return 0;
}
40void cleanup_module(void)
{
printk("Driver déchargé \n");
}
Compilation et utilisation de Driver Linux
Ce code constitue la base d’un module chargeable. Si on le compile par:
$gcc -Wall -c hello.c -o hello.o -D__KERNEL__
-I /usr/include/linux/ -O2
on pourra insérer dynamiquement le module par la commande insmod:
$insmod hello.o
Ce qui provoque le chargement du module (voir lsmod) et l’apparition du message dans les traces du
noyau.
Chargement du module :
[exemple]# lsmod
Module Size Used by
hello 184 0 (unused)
3c509 5972 1 (autoclean)
vfat 9116 0 (unused)
fat 30048 0 [vfat]
[exemple]# dmesg | tail -1
Module chargé
De même si on décharge le module par rmmod on obtient:
[exemple]# rmmod hello S
[exemple]# dmesg | tail -1
Module déchargé
4142
Chapter 4
ANNEXES
4.1 Connectivité IP
Definition 4.1.1 Connectivité IP La connectivité IP permet de raccorder tout système électronique
au réseau internet. Elle met en oeuvre une suite de protocole que l’on doit embarquer sur le système.
Avantages :
• Contrôler à distance les SETR ;
• usage d’interfaces graphiques modernes et banalisées : navigateur web ;
• Evolution du télécontrôle : RS232 et terminal V T 100.
4.1.1 Le protocole IP
Definition 4.1.2 Protocole IP Protocole basé sur le modèle OSI à 7 couches.
Definition 4.1.3 Modèles OSI Ensemble de couches. Une couche crée un niveau d’abstraction en
raffinant un service de base pour donner des services plus élaborés au niveau supérieur.
4.1.2 Les 7 couches du modèle OSI
1. Couche physique : transmettre des bits ;
2. Couche liaison : transmettre des trames, détection et correction d’erreurs ;
3. Couche réseau : routage et acheminement des données, constitutions de paquets de trames,
gestion de la congestion du réseau ;
4. Couche Transport : gestion du dialogue entre 2 noeuds (sockets, pipe, ....), mode connecté (TCP)
ou non (UDP).
5. Couche session : structuration du dialogue (client-serveur) ;
436. Couche représentation : représentation des données format, compression, cryptage,...
7. Couche Application : Interface shell, webmail, firefox, ...
4.1.3 Le réseau Internet : 4 couches
1. Couche médium : transmettre des trames de bits (couche 1 et 2) : Ethernet, GSM, Courant
porteur,...
2. Couche IP : routage et Acheminement des données (couche 3)
3. Couche TCP (ou UDP) : gestion du dialogue entre 2 noeuds mode connecté (TCP) ou non (UDP)
(couche 4);
4. Couche Application : de structuration du dialogue jusqu’a l’interface (couche 5,6,7).
Architecture Internet
Client FTP Protocole ftp Serveur FTP
TCP Protocole TCP TCP
IP IP
Protocole IP
Médium Médium
trames propres au médium
Figure 4.1: Réseaux 4 couches
Adressage
1. Chaque ordinateur ou système embarqué est repéré par une adresse IP unique sur 32 bist.
2. Notation décimale : 172.22.64.173 : 4 octets (255 < x < 0)
3. ADRESSE IP : id réseau + id machine
4. 1 octet : id Réseau
5. dernier octet : 255 broadcast, 1 : Gateway
44Protocole IP
1. version IPv4 : 4 bits d’entête
2. 8 bits : priorité, préférences sur la qualité
3. 2 octets : Longueur totale
4. 4 octets : identification, drapeaux,..
5. 1 octet durée de vie : nombre de routeurs traversés
6. 1 octet de protocole : 6 -> TCP, 17 UDP,...
7. header checksum
8. 20 octets maximum pour le message
9. adresse IP source et destination
10. options
Protocole TCP et UDP
1. Utilise IP comme service réseau
2. TCP procure un service de transport en mode connecté sécurisé (demande de ré-emission si
echec)
• Connexion par handshake ;
• Transfert de données ;
• acquitement ;
• fermeture des connexions;
• exemple : chat, telnet, ftp
3. U DP procure un service de transport en mode non connecté et non sécurisé.
• Adresse materielle de la machine appellée
• adresse IP
• numéro du port
• exemple : mail
45L’API Socket
LES SOCKETS IMPLEMENTENT LES PROTOCOLES TCP ET UDP
1. Elles permettent d’échanger des octets entre une application cliente et une application serveur.
2. Les données passent en clair dans le réseau.
3. SSL : est une nouvelle API basée sur les sockets pour échanger des données sécurisées.
Applications telnet et rlogin
Elles utilisent TCP
1. telnet est une appli client/serveur en mode connecté.
2. rlogin ne fonctionne qu’entre 2 machine UNIX. telnet est faisable sous windows
3. Un daemon serveur doit tourner sur la machine appellée.
4.1.4 Applications NFS
1. Permet de rendre transparente l’utilisation de fichiers répartis sur différentes machines.
2. NFS utilise UDP, les nouvelles versions utilisent TCP.
3. Est particulièrement utile pour les SETR diskless
Montage NFS
NFS
• NFS (Network File System) permet de partager des fichiers entre ordinateurs sous un environ-
nement Linux et/ou Unix (des implémentations existent pour Macintosh et MS Windows).
• Il existe plusieurs version de NFS : NSF 1 et 2 son obsolètes et NFS 3 : Non sécurisé et NFS 4.
• Usage : Partage d’un répertoire (projet).
• Basée sur la notion de point de montage
Point de Montage
En linux tout est fichier ou répertoire (Noeud).
Definition 4.1.4 Point de montage Sous linux : Un disque dur, un lecteur de CDROM ou une clef
USB correspondent à un répertoire. Ces éléments physiques doivent être montés et démontés après
usage. Le montage correspond à la création d’un lien entre l’élément physique et le répertoire.
• mount t iso9660 /dev/cdrom/media/cdrom
• umount /media/cdrom
46Montage NFS
C’est un système client serveur.
• Le client importe des fichiers.
• Le serveur exporte ses fichiers.
Principe
• Installation sur le serveur : Dans /etc/exports
/public ⇤ (rw, no_root_squash, sync)
#exportf s a
#/etc/init.d/nf s_kernel_server restart
• Le Client :
• mount t nf s 172.22.64.175 : /public /mnt o nolock
• umount/mnt
4.1.5 Applications ftp
1. Permet de faire des transfert de fichiers ;
2. nécessite une connexion par login et mot de passe.
3. il existe des serveurs anonymous, le mot de passe est alors son email.
• ftp 172.22.64.173
• login passwd
• put file
• mget file.*
• bye
4.1.6 Applications http
1. Protocole de communicatoin et d’échange de documents sur le web
2. Est écrit en utilisant l’API SOCKET
3. Tous les navigateurs sont des applications client/serveur basé sur l’API Socket.
1. Protocole de communicatoin et d’échange de documents sur le web
2. Est écrit en utilisant l’API SOCKET
3. Tous les navigateurs sont des applications client/serveur basé sur l’API Socket.
47Vous pouvez aussi lire
