Revision

1. Revision

2. ARCHITECTURE APPLICATION NOYAU STANDARD ADAPTATION HARDWARE

3. 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

4. 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

5. 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é

6. 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é

7. 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é

8. 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

9. 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

10. 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

11. Système de base NOYAU (1) • Principaux blocs constitutifs KERNEL GWES DEVICE MANAGER FILESYS DEVICE DRIVERS OAL

12. 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

13. 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)

14. Fonctions d’un driver • XXX_Init • XXX_Deinit • XXX_Open • XXX_Close • XXX_Read • XXX_Write • XXX_IoControl • XXX_Seek • XXX_PowerUp • XXX_PowerDown

15. 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

16. 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

17. 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

18. XXX_Close BOOL XXX_Close( DWORD hOpenContext); Parameters hOpenContext [in] Handle returned by the XXX_Open function, used to identify the open context of the device. Return Values TRUE indicates success. FALSE indicates failure. • Fonction appelée par l’operating system en réponse à un appel par l’application de la fonction CloseHandle

19. 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

20. Fonction XXX_Read DWORD XXX_Read( DWORD hOpenContext, LPVOID pBuffer, DWORD Count ); Parameters hOpenContext [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 Values Returns zero to indicate end-of-file. Returns –1 to indicate an error. Returns the number of bytes read to indicate success.

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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);