Revision

ARCHITECTURE

APPLICATION

ADAPTATION

NOYAU STANDARD

HARDWARE

BOARD SUPPORT PACKAGE (BSP)

• La couche d’adaptation est à la charge du concepteur du hardware

• Elle comprend– des fonctions d’adaptation au hardware OAL (OEM Adaptation

Layer, OEM:Original Equipment Manufacturer)– un certain nombre de drivers (pilotes de périphériques)– Le Boot Loader

• L’ensemble de cette couche est appelé BSP

• Des BSP existent pour des cartes industrielles de référence

PROCESS

• Un process ou processus est une instance d’application en cours ou en attente d’exécution

• Allocation de ressources au niveau du process• 32 MB d’adressage virtuel par process• Un process démarre avec un seul thread (Primary

Thread) mais il peut créer d’autres threads• Plusieurs threads peuvent s’exécuter simultanément• Un process peut aussi créer d’autres process• Windows CE peut gérer jusqu’à 32 process

simultanément

THREAD

• La plus petite unité d’exécution• Plusieurs threads peuvent s’exécuter simultanément• Les threads ont accès à l’ensemble des ressources

du process • Ordonnancé (schédulé) par le noyau• Quantum de temps configurable (100ms)• Préemptif• 256 niveaux de priorités• Priorité tournante pour des threads de même priorité

Section critique : types

• Les types « section critique » et « pointeur sur section critique » sont définis par des typedef

CRITICAL_SECTION cs;

LPCRITICAL_SECTION lpcs;

• Cela permet des contrôles par le compilateur et contribue à éviter un usage inapproprié

Mutex

• Mutex : raccourci pour mutual exclusion• Objet système destiné à gérer les

synchronisations par exclusion mutuelle• Synchronisation

– Intra-processus– Inter-processus

• Alloué au plus à un thread à un instant donné

Synchronisation par événement

• Autre forme de synchronisation plus souple que par les mutex

• Gestion plus riche des événements– Création– Prise de possession– Restitution– Transmission de données– Ouvertures multiples

Sémaphore (1)

• Contrôle le nombre des accès à une ressource par la distribution de jetons

• Valeur maximale fixée à la création• Chaque utilisateur prend et restitue un ou

plusieurs jetons sur le sémaphore• Fonctionne entre processus indépendants• Exclusion mutuelle dans le seul cas d’un

jeton à valeur maximum de 1

Sémaphore (2)

• Le nombre de jetons disponibles est égal à tout instant au nombre des utilisateurs de la ressource gérée par le sémaphore

• Chaque fois qu’un un jeton est pris, le compteur de jeton est décrémenté

• Chaque fois qu’un jeton est restitué, le compteur de jeton est incrémenté

• Lorsque le nombre de jetons disponibles est 0, la ressource n’est plus disponible

Système de base NOYAU (1)

• Principaux blocs constitutifs

KERNELGWES

DEVICE DRIVERSOAL

DEVICEMANAGER

FILESYS

NOYAU (2)

• KERNEL– OS minimal ; il gère les process, les threads, la mémoire,

les interruptions, etc.• GWES (Graphics Windowig Events Subsystem)

– Gère l’interface graphique et les entrées-sorties (I/O) des utilisateurs

• DEVICE DRIVERS– Native Drivers : interface utilisateur de base sauf clavier,

écran et souris qui sont gérés par GWES et chargés lors du boot

– Stream Drivers : gérés par le Device Manager

NOYAU (3)

• DEVICE MANAGER– Gère les Stream Drivers : charge lors du boot ceux qui

sont listés dans la Registry

– Gère de manière dynamique les drivers chargeables à la demande

• FILESYS– Gère le système de fichiers, la registry et la Property

Data Base (base de donnée non hiérarchisée pour stocker des adresses, des mails et des informations)

Fonctions d’un driver

• XXX_Init• XXX_Deinit• XXX_Open• XXX_Close• XXX_Read• XXX_Write• XXX_IoControl• XXX_Seek• XXX_PowerUp• XXX_PowerDown

Fonction XXX_Init

• Fonction appelée pour démarrer le driver par le Device Manager via l’appel de ActivateDeviceEx ou de RegisterDevice

• Initialise les ressources nécessaires au fonctionnement du driver (mémoire, registres des périphériques…)

• XXX_Init crée un handle hDeviceContext passé par RegisterDevice à XXX_Open, XXX_Deinit, XXX_PowerUp et XXX_PowerDown

Fonction XXX_Deinit

• BOOL XXX_Deinit(DWORD hDeviceContext);• Fonction appelée quand le Device Manager arrête

le driver via l’appel des fonctions DeactiveDeviceEx ou DeregisterDevice par l’application

• L’application devra compléter par un appel à CloseHandle pour détruire le handle associé et libèrer toutes les ressources matérielles et/ou logicielles utilisées par le driver

Fonction XXX_Open

• Ouvre un driver en lecture et/ou écriture • Fonction appelée par l’application à travers la

fonction CreateFile• Alloue les ressources propres à chaque contexte

ouvert• Crée un handle hOpenContext utilisé par

XXX_Close, XXX_Read, XXX_Write, XXX_Seek XXX_IOControl

• Peut-être appelée plusieurs fois

XXX_Close

BOOL XXX_Close( DWORD hOpenContext);ParametershOpenContext

[in] Handle returned by the XXX_Open function, used to identify the open context of the device.

Return ValuesTRUE indicates success. FALSE indicates failure.

• Fonction appelée par l’operating system en réponse à un appel par l’application de la fonction CloseHandle

XXX_Read

DWORD XXX_Read( DWORD hOpenContext, LPVOID pBuffer, DWORD Count);• Fonction appelée par l’operating system en

réponse à la fonction ReadFile de l’application• Utilise un contexte ouvert par XXX_Open• Les caractères lus sont placés dans le buffer pointé

par pBuffer• Count indique le nombre de caractères à lire• La fonction retourne le nombre de caractères lus

Fonction XXX_Read

DWORD XXX_Read( DWORD hOpenContext, LPVOID pBuffer, DWORD Count );

ParametershOpenContext

[in] Handle to the open context of the device. The XXX_Open function creates and returns this identifier.

pBuffer [out] Pointer to the buffer that stores the data read from the device. This buffer should be at least Count bytes long.

Count [in] Number of bytes to read from the device into pBuffer.

Return ValuesReturns zero to indicate end-of-file. Returns –1 to indicate an error. Returns the number of bytes read to indicate success.

XXX_Write

DWORD XXX_Write( DWORD hOpenContext, LPVOID pBuffer, DWORD Count);• Appelée par l’operating system en réponse à la

fonction WriteFile de l’application• Les caractères à écrire sont placés dans le buffer et

Count indique le nombre de caractères à écrire• L’OS écrira dans le device connu par un handle de

« contexte ouvert » créé par XXX_Open • Fournit le nombre de caractères écrits ou erreur

XXX_Seek

• DWORD XXX_Seek( DWORD hOpenContext,long Amount,WORD Type);

• Appelée par l’operating system en réponse à la fonction SetFilePointer de l’application

• Amount indique le nombre de bytes dont doit être modifié le pointeur de données du device

• Type spécifie le point de départ du pointeur de données

Fonction SetFilePointer

• Permet de déplacer un pointeur dans un fichier ouvert

• Suppose un objet qui supporte un positionnement, pas un port qui travaille toujours au même endroit

• Peut renseigner sur la position dans le fichier• Retourne la nouvelle valeur du pointeur ou une

erreur

IOCTL

#define IOCTL_essai1 CTL_CODE(\ FILE_DEVICE_UNKNOWN,2048,\METHOD_BUFFERED,FILE_ANY_ACCESS)

• Permet de définir des fonctions spécifiques à un device donné

• IOControl est un code 32 bits défini avec la macro CTL_CODE

XXX_IOControl

• BOOL XXX_IOControl( DWORD hOpenContext, DWORD dwCode, PBYTE pBufIn, DWORD dwLenIn, PBYTE pBufOut, DWORD dwLenOut, PDWORD pdwActualOut);

• dwCode identifie une opération• On dispose d’un buffer d’entrée• On dispose d’un buffer de sortie• pdwActualOut permet de retourner le nombre de

caractères effectivement lus sur le device.• Appelé par l’application avec DeviceIoControl

XXX_ PowerDown XXX_PowerUp

• Appelés par l’operating system pour gérer l’énergie sur des périphériques disposant des fonctionnalités de mise en veilleuse ou d’extinction

• Void XXX_PowerUp(DWORD hDeviceContext);

• Void XXX_PowerDown(DWORD hDeviceContext);