MCTS i Exam 70-571 Windows Embedded CE 6.0 Kit de préparation Inclut la mise à jour R2 Préparation à l'examen de certification Revente interdite.
Généralités Préface............................................................................................... Introduction....................................................................................... xi xiii 1 Personnalisation de l OS Design......................................................... 1 2 Génération et déploiement d'une image d exécution......................... 43 3 Programmation système.................................................................... 91 4 Débogage et test du système............................................................. 161 5 Personnalisation d un package de support de carte électronique (BSP) 217 6 Développement de pilotes de périphériques...................................... 265 Glossaire............................................................................................ 341 Index.................................................................................................. 347 À propos des auteurs......................................................................... 365 iii
Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Les développeurs d applications n ont pas souvent besoin de créer un package de support de carte électronique (BSP). Toutefois, les fabricants OEM sont confrontés à cette exigence lors de la mise à niveau de Microsoft Windows Embedded CE 6.0 R2 vers une nouvelle plate-forme matérielle. Pour aider les fabricants OEM à accomplir efficacement cette tâche, Windows Embedded CE comprend une architecture de couche d adaptation OEM de «qualité de la production» (PQOAL) qui promeut la réutilisation du code sous la forme d une collection de librairies OAL, organisées par modèle de processeur et de fonctionnalité de l OAL. Microsoft encourage les développeurs OEM à cloner et à personnaliser un BSP existant pour adapter les BSP à leur architecture et pour tirer pleinement parti des fonctionnalités de production testées et éprouvées qui couvrent la gestion de l alimentation, l optimisation des performances, et les contrôles d entrée/sortie (IOCTL). Ce chapitre traite de l architecture PQOAL, explique comment cloner les BSP, et énumère les fonctions que les développeurs OEM doivent implémenter pour adapter Windows Embedded CE à de nouvelles architectures matériels. Il est avantageux de comprendre les divers aspects de la personnalisation d un BSP, même si vous n avez pas l intention de développer votre propre BSP. Ce chapitre fournit une vue d ensemble des aspects de la personnalisation des BSP, allant des modifications du processus de démarrage et de l implémentation de routines d initialisation du noyau à l ajout de pilotes de périphériques, de fonctionnalités de gestion de l alimentation, et l optimisation des performances. Objectifs d examen abordés dans ce chapitre : Comprendre l architecture des BSP de Windows Embedded CE Modifier et adapter les BSP et les bootloaders pour des terminaux cibles spécifiques Comprendre la gestion et le l organisation de la mémoire Activer la gestion de l alimentation 217
218 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Avant de commencer Pour suivre les cours de ce chapitre, vous devez : Avoir au moins des connaissances de base sur le développement de logiciels Windows Embedded CE. Bien connaître les architectures matérielles des terminaux embarqués. Avoir des connaissances de base sur la gestion de l alimentation et sur son implémentation dans les pilotes et applications. Disposer d un ordinateur de développement sur lequel Microsoft Visual Studio 2005 Service Pack 1 et Platform Builder for Windows Embedded CE 6.0 R2 sont installés.
Cours 1 : Adaptation et configuration d'un package de support de carte électronique (BSP) 219 Cours 1 : Adaptation et configuration d'un package de support de carte électronique (BSP) Le processus de développement d un BSP pour une nouvelle plate-forme matérielle commence généralement après l exécution de tests fonctionnels du matériel à l aide d un moniteur ROM, en clonant un BSP de référence approprié, puis en implémentant un bootloader et les fonctions OAL principales permettant le démarrage du noyau. L objectif est de créer un noyau doté de la plus petite quantité possible de code personnalisé. Vous pouvez ensuite ajouter, à ce BSP minimal, des pilotes de périphériques pour prendre en charge le matériel intégré et les périphériques. Ensuite envisagez d étendre le système en implémentant la gestion de l alimentation et d autres fonctionnalités avancées de système d exploitation en fonction des capacités du terminal cible. Après ce cours, vous serez à même de : Identifier et localiser le contenu d un package de support de carte électronique basé sur PQOAL. Identifier les librairies spécifiques au matériel et de code commun. Comprendre comment cloner un BSP. Adapter un bootloader, la couche OAL, et des pilotes de périphériques. Durée approximative du cours : 40 minutes. Vue d ensemble des packages de support de carte électronique Un BSP contient le code source du bootloader, de la couche OAL, et des pilotes de périphériques d une plate-forme donnée. Outre ces composants, le BSP contient aussi les fichiers de génération et de configuration du système, comme illustré à la Figure 5 1. Les fichiers de configuration ne sont pas inclus dans l image d exécution, mais ils font partie du package BSP pour spécifier les fichiers utiles, l organisation de la mémoire, les paramètres de la base de registre, et d autres éléments nécessaire pour la compilation et génération l image d exécution, comme expliqué au Chapitre 2, «Création et déploiement d une image d exécution».
220 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Fichiers de configuration Image d'exécution Applications Windows Embedded CE Shell et applications Shell incorporé Services Shell Windows Embedded CE Connectivité à distance API Win 32 CoredII WinSock OLE CommCtrl CommDlg WinInet TAPI Librairie du noyau Gestionnaire de périphériques GWES Gestionnaire de fichiers TCP/IP IrDA Chargeur de démarrage Librairie RTC Librairie de l'horloge du OS Librairie du cache Librairie de démarrage Librairie d'interruptions Librairie IOCTL Librairie KITL Pilotes de périphériques Pilotes natifs Pilotes du système de fichiers OAL Pilotes réseau RTC Horloge Caches SDB (Standard Development Board) Port USB Port Ethernet Port série Autre matériel Package de support de carte électronique Figure 5 1 Composition d un BSP par rapport aux autres éléments de Windows Embedded CE 6.0
Cours 1 : Adaptation et configuration d'un package de support de carte électronique (BSP) 221 Selon la Figure 5 1, le développement d un BSP fait intervenir les composants principaux suivants : Bootloader S exécute au démarrage ou à la réinitialisation du terminal. Le rôle du bootloader est d initialiser la plate-forme matérielle et de charger en mémoire puis lancer le système d exploitation. Couche d adaptation OEM (OAL) Représente l élément principal du BSP et fait l interface entre le noyau et le matériel. Comme elle est directement liée au noyau, elle devient partie intégrante du noyau dans une image d exécution CE. Certains des principaux composants du noyau dépendent directement de la couche OAL pour l initialisation du matériel, comme le traitement des interruptions et la gestion de l horloge de l ordonnanceur de threads. Pilotes de périphériques Gèrent la fonctionnalité d un périphérique donné et fournissent une interface entre le matériel et le système d exploitation. Windows Embedded CE prend en charge une variété d architectures de pilotes en fonction des interfaces qu elles exposent, comme expliqué au Chapitre 6, «Développement de pilotes de périphériques». Fichiers de configuration Fournissent les informations nécessaires pour contrôler le processus de génération et jouent un rôle essentiel dans la conception du système d exploitation d une plate-forme. Les fichiers de configuration types inclus dans les BSP sont les fichiers Sources, les fichiers Dirs, Config.bib, Platform.bib, Platform.reg, Platform.db, Platform.dat, et les fichiers de catalogue (*.pbcxml). Adaptation d un package de support de carte électronique Il est généralement judicieux de commencer le développement d un BSP en clonant un BSP de référence existant au lieu de créer un BSP de toutes pièces. Même si vous devez développer un BSP pour une plate-forme entièrement nouvelle dotée d un micro-processeur entièrement nouveau, il est recommandé de cloner le BSP de référence pour l architecture du processeur. De cette manière, vous pouvez réduire le temps de développement du BSP en réutilisant le code, indépendant du matériel, du BSP existant et réduire les futurs cycles de migration aux versions ulterieures de Windows Embedded à mesure qu elles apparaissent sur le marché. La migration d un BSP à l architecture propriétaire est généralement beaucoup plus difficile à effectuer que celle pour un BSP basé sur une architecture de type PQOAL car le BSP propriétaire ne peut pas tirer parti de ces portions de code PQOAL que Microsoft fait
222 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) migrer et teste implicitement dans le cadre de la réalisation de la nouvelle version du système d exploitation. L adaptation d un package de support de carte électronique fait intervenir la séquence de tâches suivante : 1. Clonage d un BSP de référence. 2. Implémentation d un bootloader. 3. Adaptation des fonctions OAL. 4. Modification des fichiers de configuration de l image d exécution. 5. Développement de pilotes de périphériques. Clonage d un BSP de référence Platform Builder comprend un assistant qui facilite le clonage d un BSP de référence. Cet assistant copie tout le code source du BSP de référence sélectionné, dans une nouvelle structure de dossiers, afin que vous puissiez personnaliser le BSP pour le nouveau matériel, sans affecter le BSP de référence ou d autres BSP situés dans la hiérarchie du dossier %_WINCEROOT%\Platform. La Figure 5 2 illustre le démarrage de l Assistant de clonage de BSP de Microsoft Visual Studio 2005 avec Platform Builder for Windows Embedded CE 6.0. REMARQUE Nommage des BSP Lors du clonage d un BSP, vous devez choisir un nouveau nom pour ce nouvel ensemble de fichiers. Le nom que vous choisissez pour la plate-forme doit correspondre au nom du dossier sur votre disque dur. Comme mentionné dans le chapitre précédent, le moteur de génération est basé sur un script de ligne de commande et n est pas compatible avec les espaces dans les noms de dossiers. Ainsi, le nom du BSP ne doit comprendre aucune espace. Pour tout de même pouvoir utiliser un nom explicite, remplacer les espaces par le symbole de soulignement (_).
Cours 1 : Adaptation et configuration d'un package de support de carte électronique (BSP) 223 Figure 5 2 Clonage d un BSP dans Visual Studio 2005 Structure des dossiers BSP Pour maximiser la capacité à réutiliser le code, les BSP basés sur PQOAL, PQOAL présentent une architecture commune et une structure de dossiers correspondante homogènes pour toutes les familles de processeurs. Grâce à cette architecture commune, de grandes portions de code source peuvent être réutilisées quelles que soient les exigences matérielles des BSP. La Figure 5 3 illustre la structure typique des dossiers BSP et le Tableau 5 1 résume les dossiers BSP les plus importants.
224 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Figure 5 3 Structure de dossiers d un BSP typique CONSEIL %_TARGETPLATROOT% Vous pouvez utiliser la variable d environnement %_TARGETPLATROOT% de la fenêtre de génération pour localiser le chemin du BSP utilise dans l OS design actuel (option Open Release Directory In Build Window (Ouvrir le répertoire d édition dans la fenêtre de génération) du menu Générer de Visual Studio). Tableau 5 1 Dossiers Dossiers BSP importants Description Dossier racine Contient les fichiers de configuration et de commandes. Les deux plus importants fichiers pour les développeurs sont les suivants : Sources.cmn Contient des définitions de macros qui sont communes dans tout le BSP. <NomDuBSP>.bat Définit les variables d environnement de BSP par défaut.
Cours 1 : Adaptation et configuration d'un package de support de carte électronique (BSP) 225 Tableau 5 1 Dossiers CATALOG Dossiers BSP importants Description Contient le fichier catalogue du BSP dans lequel tous les composants du BSP sont définis. Ce fichier est utilisé au cours de l étape de personnalisation d OS design pour ajouter ou supprimer des fonctionnalités de BSP. Le Chapitre 1, «Personnalisation de l OS Design», traite de la gestion des éléments de catalogue. CESYSGEN FILES SRC COMMON Contient le fichier Makefile de l outil Sysgen. La configuration d un BSP ne nécessite aucun changement dans ce répertoire. Contient les fichiers de configuration de la génération, tels que les fichiers.bib,.reg,.db, et.dat. Contient le code source spécifique à la plate-forme que vous devez adapter en fonction du modèle PQOAL, qui divise le code entre les composants spécifiques à la plate-forme et les composants communs par type de micro-processeur. Existe sous le répertoire de la plate-forme et contient la plupart du code source du BSP. Consiste en un ensemble commun de composants spécifiques au processeur. Les différents binaires du BSP, pilotes de périphériques et OAL, se lient aux librairies de ce dossier, générées au cours du processus de génération. Si le matériel utilise un micro-processeur de la famille des processeurs pris en charge, la plupart de ces librairies peuvent être réutilisées sans modification. Code source spécifique à la plate-forme Le plus important code source spécifique à la plate-forme que vous devez adapter dans le cadre de votre BSP est celui du bootloader, de la couche OAL, et des pilotes de périphériques. Le code source correspondent est situé sous le dossier Src dans les sous-répertoires suivants : Src\Boot Loader Contient le code du bootloader. Toutefois, si le bootloader utilise BLCOMMON et les librairies apparentées, seule la partie de base spécifique au matériel du bootloader se trouve dans ce répertoire. Le code réutilisable du bootloader est disponible dans le dossier Public
226 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) (%_WINCEROOT%\Public\Common\Oak\Drivers\Ethdbg) et lié en tant que librairies au composant du BSP. Le Chapitre 4, «Débogage et test du système», présente les librairies statiques qui facilitent le développement du bootloader. Src\Oal Contient la quantité minimale de code spécifique à la plate-forme matérielle. La majorité du code OAL est située dans le dossier %_WINCEROOT%\Platform\Common, répartie en plusieurs groupes : indépendant du matériel, apparenté à la famille du processeur, spécifique à la puce et spécifique à la plate-forme. Ces groupes de code fournissent la plupart des fonctionnalités OAL et son liés aux composants spécifiques à la plate-forme en tant que librairies. Src\Common et Src\Drivers Contient le code source des pilotes, organisé en plusieurs catégories pour faciliter la maintenance et l utilisation. Ces catégories sont généralement les catégories spécifiques au processeur et spécifiques à la plate-forme. Le composant spécifique au processeur est situé dans le répertoire Src\Common et ne nécessite aucune modification lorsqu il est adapté à du nouveau matériel basé sur la même famille de processeurs. Implémentation d un bootloader à partir de librairies existantes Plusieurs aspects doivent être pris en compte lors de l adaptation d un bootloader pour une nouvelle plate-forme, y compris : Les changements de l architecture du processeur. L emplacement du binaire du bootloader sur le terminal cible. L architecture de la mémoire de la plate-forme. Les tâches à effectuer lors du processus de démarrage. Les transports pris en charge pour le téléchargement de l image d exécution. Les fonctionnalités additionnelles qui doivent être prises en charge. Mappages de mémoire La première tâche d adaptation importante s articule autour de la définition des mappages de la mémoire du bootloader. Les BSP standards inclus dans Windows Embedded CE définissent la configuration de la mémoire dans un fichier.bib, situé dans un sous-répertoire du bootloader, tel que %_WINCEROOT%\Platform \Arubaboard\Src\Boot Loader\Eboot\Eboot.bib. Le listing suivant montre un
Cours 1 : Adaptation et configuration d'un package de support de carte électronique (BSP) 227 exemple de fichier Eboot.bib, que vous pouvez personnaliser en fonction de vos besoins. MEMORY ; Name Start Size Type ; ------- -------- -------- ---- ; Réserver de la RAM avant l Eboot. ; Cette mémoire sera utilisée ultérieurement. DRV_GLB A0008000 00001000 RESERVED ; Driver Globals ; 4 Ko suffisent. EBOOT A0030000 00020000 RAMIMAGE ; Réserver 128 Ko pour le chargeur ; finaliser plus tard. RAM A0050000 00010000 RAM ; Libérer de la RAM ; finaliser plus tard. CONFIG COMPRESSION=OFF PROFILE=OFF KERNELFIXUPS=ON ; Ces options de configuration peuvent entraîner la création du fichier.nb0. ; Un fichier.nb0 peut être écrit directement dans la mémoire flash puis ; démarré. Comme le chargeur est lié pour une exécution à partir de la RAM, ; les options de configuration suivantes ; doivent correspondre à la section RAMIMAGE. ROMSTART=A0030000 ROMWIDTH=32 ROMSIZE=20000 MODULES ; Name Path Memory Type ; ----------- --------------------------------------------- ----------- nk.exe $(_TARGETPLATROOT)\target\$(_TGTCPU)\$(WINCEDEBUG)\EBOOT.exe EBOOT Driver Globals Vous pouvez utiliser, entre autres, le fichier Eboot.bib pour réserver une section de mémoire pour le bootloader afin de communiquer des informations au système d exploitation au cours du processus de démarrage. Ces informations peuvent refléter l état actuel du matériel initialisé, les capacités de communication réseau si le bootloader prend en charge les téléchargements Ethernet, les indicateurs utilisateur et du système d exploitation, comme l activation de KITL (Kernel Independent Transport Layer, couche de transport indépendante du noyau), et ainsi de suite. Pour activer cette communication, le bootloader et le système d exploitation doivent partager une région commune de mémoire physique, qui est appelée Driver Globals (DRV_GLB). Le listing Eboot.bib suivant comprend un mappage DRV_GLB. Les
228 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) données que le bootloader fait passer au système d exploitation dans la région DRV_GLB doivent adhérer à une structure BOOT_ARGS que vous définissez en fonction de vos besoins. La procédure suivante illustre comment faire passer des informations de configuration Ethernet et IP à partir du bootloader vers le système d exploitation par le biais de la région DRV_GLB. Pour ce faire, créez un fichier d en-tête dans le dossier %_WINCEROOT%\Platform\<Nom du BSP>\Src\Inc, comme par exemple Drv_glob.h, dont le contenu est le suivant : #include <halether.h> // Déboguer les paramètres Ethernet. typedef struct _ETH_HARDWARE_SETTINGS { EDBG_ADAPTER Adapter; // La carte réseau servant à communiquer avec Platform Builder. UCHAR ucedbgadaptertype; // Type de carte de débogage Ethernet. UCHAR ucedbgirq; // Ligne IRQ à utiliser pour la carte de débogage Ethernet. DWORD dwedbgbaseaddr; // Adresse E/S de base de la carte de débogage Ethernet. DWORD dwedbgdebugzone; // Zones de débogage EDBG à activer. // Base pour la création dun nom de terminal. // Ceci sera combiné avec ladresse MAC EDBG // pour générer un nom de terminal unique pour identifier // le terminal auprès de Platform Builder. char szplatformstring[edbg_max_dev_namelen]; UCHAR uccpuid; // Type de micro-processeur. } ETH_HARDWARE_SETTINGS, *PETH_HARDWARE_SETTINGS; // BootArgs Paramètres passés au système dexploitation à partir du bootloader. #define BOOTARG_SIG 0x544F4F42 // "BOOT" typedef struct BOOT_ARGS { DWORD dwsig; DWORD dwlen; // Longueur totale de la structure de BootArgs. UCHAR ucloaderflags; // Indicateurs configurés par le bootloader. UCHAR uceshellflags; // Indicateurs d Eshell. DWORD dwedbgdebugzone; // Quels messages de débogage sont activés? // Les adresses suivantes ne sont valides que si LDRFL_JUMPIMG est configuré et // si le bit correspondant dans uceshellflags est défini (configuré par Eshell, définitions // de bit dans Ethdbg.h). EDBG_ADDR EshellHostAddr; // Adresse IP/Ethernet et port UDP de lhôte // qui exécute Eshell. EDBG_ADDR DbgHostAddr; // Adresse IP/Ethernet et port UDP de lhôte // qui reçoit les messages de débogage.
Cours 1 : Adaptation et configuration d'un package de support de carte électronique (BSP) 229 EDBG_ADDR CeshHostAddr; EDBG_ADDR KdbgHostAddr; // Adresse IP/Ethernet et port UDP de lhôte // qui exécute le shell Ethernet de texte. Adresse IP/Ethernet et port UDP de lhôte // qui exécute le débogueur du noyau. ETH_HARDWARE_SETTINGS Edbg; // Le contrôleur Ethernet de débogage. } BOOT_ARGS, *PBOOT_ARGS; // Définitions des indicateurs configurés par le bootloader. #define LDRFL_USE_EDBG 0x0001 // Configuré pour tenter d utiliser le débogage Ethernet. // Les deux indicateurs suivants ne sont examines que si LDRFL_USE_EDBG est configuré. #define LDRFL_ADDR_VALID 0x0002 // Configuré si le membre EdbgAddr est valide. #define LDRFL_JUMPIMG 0x0004 // Sil est configuré, ne pas communiquer avec Eshell // pour obtenir des informations de configuration, // utiliser plutôt le membre uceshellflags. typedef struct _DRIVER_GLOBALS { // // TODO : Plus tard, remplir cette zone avec les informations partagées entre // les pilotes et le système dexploitation. // BOOT_ARGS bootargs; } DRIVER_GLOBALS, *PDRIVER_GLOBALS; Point d entrée StartUp et fonction principale Le point d entrée StartUp du bootloader doit être placé dans la mémoire linéaire à l adresse où le micro-processeur commence à extraire du code pour exécution, car cette routine accomplit l initialisation du matériel nécessaire au démarrage du bootloader. Si l adaptation est basée sur un BSP de référence, la plupart du code apparenté au micro-processeur et au contrôleur de mémoire peut rester inchangé. D autre part, si l architecture de micro-processeur est différente, vous devez adapter la routine de démarrage pour accomplir les tâches suivantes : 1. Mettre le micro-processeur dans le mode approprié. 2. Désactiver toutes les interruptions. 3. Initialiser le contrôleur de mémoire. 4. Configurer les caches, les tampons TLB (Translation Lookaside Buffers), et l unité de gestion de la mémoire (MMU). 5. Copier le bootloader de la mémoire flash vers la RAM pour une exécution plus rapide. 6. Passer directement au code C de la fonction principale.
230 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) La routine StartUp appelle la fonction principale du bootloader, et si le bootloader est basé sur BLCOMMON, cette fonction appelle à son tour BootLoaderMain, qui initialise le transport de téléchargement en appelant les fonctions de la plate-forme OEM. L avantage de l utilisation des librairies standard fournies par Microsoft est que les modifications nécessaires pour adapter un BSP à une nouvelle plate-forme matérielle sont organisées en composants, isolées et minimisées. Sortie de débogage en série L étape suivante de l adaptation du bootloader est l initialisation de la sortie de débogage sur port série. Il s agit d une partie importante du processus de démarrage car elle permet à l utilisateur d interagir avec le bootloader et au développeur d analyser les messages de débogage, comme abordé au Chapitre 4, «Débogage et test du système». Le Tableau 5-2 énumère les fonctions de plates-formes OEM nécessaires pour prendre en charge la sortie de débogage en série dans le bootloader : Tableau 5 2 Fonction Fonction de sortie de débogage sur port série Description OEMDebugInit OEMWriteDebugString OEMWriteDebugByte OEMReadDebugByte Initialise l UART de débogage de la plate-forme. Écrit une chaîne de caractères dans l UART de débogage. Écrit un octet dans l UART de débogage, utilisé par la fonction OEMWriteDebugString. Lit un octet de l UART de débogage. Initialisation de la plate-forme Une fois le micro-processeur et la sortie de débogage sur port série initialisés, vous pouvez vous concentrer sur les autres tâches d initialisation du matériel. La routine OEMPlatformInit exécute ces tâches restantes, y compris les suivantes : Initialisation de l horloge temps réel. Configuration de la mémoire externe, particulièrement la mémoire flash. Initialisation du contrôleur réseau.
Cours 1 : Adaptation et configuration d'un package de support de carte électronique (BSP) 231 Téléchargement via Ethernet Si la plate-forme matérielle comprend un contrôleur réseau, le bootloader peut télécharger l image d exécution par le biais du contrôleur Ethernet. Le Tableau 5 3 énumère les fonctions que vous devez implémenter pour prendre en charge la communication basée sur Ethernet. Tableau 5 3 Fonction OEMReadData OEMEthGetFrame OEMEthSendFrame OEMEthGetSecs Fonctions de prise en charge d Ethernet Description Les fonctions de prise en charge de l Ethernet utilisent des fonctions de rappels (callbacks)spécifiques au contrôleur réseau. Cela signifie que vous devez implémenter ces routines supplémentaires et configurer les pointeurs de fonction appropriés dans la fonction OEMPlatformInit, si vous voulez prendre en charge un contrôleur réseau différent, comme démontré dans l exemple de code suivant : cadapttype=pbootargs->ucedbgadaptertype; // Configurer des rappels de pilote EDBG basés sur // le type de contrôleur Ethernet. switch (cadapttype) { case EDBG_ADAPTER_NE2000 : pfnedbginit = NE2000Init; pfnedbginitdmabuffer = NULL; pfnedbggetframe = NE2000GetFrame; pfnedbgsendframe = NE2000SendFrame; break; case EDBG_ADAPTER_DP83815 : pfnedbginit = DP83815Init; pfnedbginitdmabuffer = DP83815InitDMABuffer; pfnedbggetframe = DP83815GetFrame;... } Lit des données à partir de la couche de transport utilisée pour le téléchargement. Lit des données à partir de la carte réseau à l aide du pointeur de fonction pfnedbggetframe. Écrit des données sur la carte réseau à l aide du pointeur de fonction pfnedbfsendframe. Retourne le nombre de secondes écoulées depuis le démarrage de la plate-forme.
232 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Prise en charge de la mémoire flash Après avoir implémenté les fonctionnalités de communication réseau, vous devez réaliser les fonctions permettant le téléchargement l image d exécution sur la plateforme et lancer son exécution. Vous pouvez également enregistrer l image d exécution dans la mémoire flash. Le Tableau 5 4 énumère les fonctions de prise en charge du téléchargement et de l accès à la mémoire flash, que vous devez implémenter dans ce but, si le bootloader du BSP de référence ne possède pas déjà ces fonctionnalités. Tableau 5 4 Fonction Fonctions de prise en charge du téléchargement et de la mémoire flash Description OEMPreDownload OEMIsFlashAddr OEMMapMemAddr OEMStartEraseFlash OEMContinueEraseFlash OEMFinishEraseFlash OEMWriteFlash Configure le protocole de téléchargement nécessaire pris en charge par Platform Builder. Vérifie si l image est pour la mémoire flash ou pour la RAM. Exécute le remappage temporaire de l image dans la RAM. Prépare la libération d un espace suffisamment volumineux de la mémoire flash pour héberger l image du système d exploitation. Continue à effacer de la mémoire flash en fonction de la progression du téléchargement. Termine d'effacer la mémoire flash une fois le téléchargement effectué. Écrit l image du système d exploitation dans la mémoire flash. Interaction utilisateur Les bootloaders prennent en charge l interaction avec l utilisateur en proposant un menu fournissant différentes options pour le démarrage de la plate-forme, ce qui peut être utile lors du processus de développement et plus tard pour la maintenance et les mises à jour de logiciels. La Figure 5 4 illustre un menu standard de bootloader. Pour voir un exemple de code source, consultez le fichier Menu.c situé dans le répertoire
Cours 1 : Adaptation et configuration d'un package de support de carte électronique (BSP) 233 Src\Boot Loader\Eboot d un BSP de référence ou dans le dossier %_WINCEROOT%\Platform\Common\Src\Common\Boot\Blmenu. Figure 5 4 Un exemple de menu de bootloader Fonctionnalités supplémentaires Outre la fonctionnalité principale, vous pouvez ajouter des fonctionnalités pratiques, comme l indication de la progression d un téléchargement, la prise en charge du téléchargement de plusieurs fichiers.bin pendant une même session de téléchargement (notification d images bin multiples), ou le téléchargement d images d exécution certifiées. En outre, vous pouvez implémenter la prise en charge du téléchargementdes images d exécution directement à partir de Platform Builder. Pour accomplir cette tâche, le bootloader doit préparer un paquet BOOTME avec des détails sur le terminal cible et l envoyer par le biais du transport sous-jacent. Si le transport est Ethernet, ce paquet est diffusé sur le réseau. Les librairies fournies par Microsoft prennent en charge ces fonctionnalités, et vous pouvez les personnaliser en fonction de vos besoins. REMARQUE Fonctions OEMdu bootloader Pour des informations détaillées sur les fonctions de bootloader facultatives et obligatoires et sur les structures utilisées par le bootloader, voir la section «Boot Loader Reference» de la documentation de Windows Embedded CE 6.0, disponible sur le site Web Microsoft MSDN à l adresse http ://msdn2.microsoft.com/en-us/library/aa908395.aspx.
234 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Adaptation d une couche OAL L adaptation d un BSP s articule en grande partie autour de la couche OAL qui est spécifique à la plate-forme. Si la nouvelle plate-forme utilise un micro-processeur qui n est pas actuellement pris en charge, l adaptation de la couche OAL nécessite que vous modifiiez la plupart du code OAL pour prendre en charge cette nouvelle l architecture. D autre part, si le nouveau matériel est très proche de celui pour lequel le BSP de référence a été développé initialement, vous pourrez peut-être réutiliser la plupart du code existant. Table d adresses OEM Le noyau exécute des tâches spécialisées, telles que l initialisation de la mémoire virtuelle, et pour ce faire, il ne peut pas se fier au bootloader, car le noyau doit être entièrement autonome. Sinon, le système d exploitation dépendrait de la présence d un bootloader et il ne serait pas possible de démarrer l image d exécution directement sans intermédiaire. Toutefois, pour établir des mappages d'adresses virtuelles sur des adresses physiques par le biais de l unité de gestion de la mémoire (MMU), le noyau doit connaître l organisation de la mémoire de la plate-forme. Pour obtenir ces informations, le noyau utilise une table importante appelée OEMAddressTable (ou g_oaladdresstable) qui définit les régions de mémoire virtuelle statique. La couche OAL comprend une déclaration d OEMAddressTable en tant que section de code en lecture seule et une des premières actions effectuées par le noyau est de lire cette section, de configurer les tables de mappages de mémoire correspondantes, puis d effectuer la transition vers l adressage virtuelle où le noyau peut exécuter du code. Le noyau peut déterminer l adresse physique d OEMAddressTable en mémoire linéaire en fonction des informations d adresse disponibles dans l image d exécution. Vous devez indiquer les éventuelles différences qui existent dans la configuration de la mémoire de la nouvelle plate-forme en modifiant la section OEMAddressTable. L exemple de code suivant illustre la déclaration de la section OEMAddressTable. ;-------------------------------------------------------------- public _OEMAddressTable _OEMAddressTable : ; OEMAddressTable définit le mappage entre les adresses physique et virtuelle ; o DOIT être dans une section READONLY ; o Première entrée DOIT être RAM, mappage de 0x80000000 -> 0x00000000 ; o chaque entrée est au format ( VA, PA, cbsize ) ; o cbsize doit être un multiple de 4M
Cours 1 : Adaptation et configuration d'un package de support de carte électronique (BSP) 235 ; o la dernière entrée doit être (0, 0, 0) ; o doit avoir au moins une entrée non nulle ; RAM 0x80000000 -> 0x00000000, taille 64M dd 80000000h, 0, 04000000h ; FLASH et autre mémoire, le cas échéant ; dd FlashVA, FlashPA, FlashSize ; Dernière entrée, toutes valeurs égales à zéro dd 0 0 0 Point d entrée StartUp Comme le bootloader, la couche OAL contient un point d entrée StartUp vers lequel le bootloader ou le système peut passer directement afin de démarrer l'exécution du noyau et l'initialisation du système. Par exemple, le code assembleur servant à placer le processeur dans l état adéquat est généralement identique au code utilisé dans le bootloader. En fait, le partage du code entre le bootloader et la couche OAL est une pratique communément utilisée pour minimiser la duplication du code dans le BSP. Toutefois, tout le code n est pas exécuté deux fois. Par exemple, sur les plates-formes matérielles qui démarrent à partir d un bootloader, StartUp passe directement à la fonction KernelStart lorsque le bootloader a déjà effectué le travail d initialisation. La fonction KernelStart initialise les tables de mappage de la mémoire, comme nous l'avons vu à la section précédente, et charge la librairie du noyau pour exécuter le code du noyau de Microsoft. Le code du noyau de Microsoft appelle alors la fonction OEMInitGlobals pour faire passer un pointeur vers une structure NKGLOBALS statique à la couche OAL et extraire un pointeur vers une structure OEMGLOBALS sous la forme d une valeur de retour en provenance de la couche OAL. NKGLOBALS contient des pointeurs vers toutes les fonctions et variables utilisées par KITL et par le code du noyau de Microsoft. OEMGLOBALS a des pointeurs vers toutes les fonctions et variables implémentées dans la couche OAL pour le BSP. En échangeant les pointeurs vers ces structures globales, Oal.exe et Kernel.dll peuvent accéder aux fonctions et aux données l une de l autre, et continuer à effectuer des tâches de démarrage génériques à l architecture et spécifiques à la plate-forme. Les tâches de démarrage génériques à l architecture comprennent la configuration de tables et d'informations de cache, la purge de tampons TLB (Transition Lookaside Buffer), l initialisation de bus et de composants spécifiques à l'architecture, la configuration du code d API Interlocked, le chargement de KITL pour prendre en charge la communication du noyau en vue du débogage, et l initialisation de la sortie de débogage du noyau. Le noyau appelle ensuite la fonction OEMInit par le biais du
236 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) pointeur de fonction de la structure OEMGLOBALS pour effectuer une initialisation spécifique à la plate-forme. Le Tableau 5 5 énumère les fonctions spécifiques à la plate-forme que Kernel.dll appelle et que vous devrez peut-être modifier dans votre BSP pour exécuter Windows Embedded CE sur une nouvelle plate-forme matérielle. Tableau 5 5 Fonction OEMInitGlobals OEMInit Fonctions de prise en charge du démarrage du noyau OEMGetExtensionDRAM OEMGetRealTime OEMSetAlarmTime OEMSetRealTime OEMIdle OEMInterruptDisable OEMInterruptEnable OEMInterruptDone OEMInterruptHandler OEMInterruptHandler OEMIoControl OEMNMI Description Echange des pointeurs globaux entre Oal.exe et Kernel.dll. Initialise les interfaces matérielles de la plate-forme. Fournit des informations sur la RAM supplémentaire, le cas échéant. Extrait l heure de la RTC. Configure l alarme dans le RTC. Configure l heure dans la RTC. Met le micro-processeur en état inactif lorsqu aucun thread n est en cours d exécution. Désactive l interruption d un périphérique particulier. Active l interruption d un périphérique particulier. Signale la fin du traitement de l interruption. Traite les interruptions (si différentes pour les processeurs SHx). Traite FIQ (spécifique pour les processeurs ARM). Code de contrôle des ES pour les informations sur l OEM. Prend en charge d une interruption ne pouvant être masquée (spécifique au processeur SHx).
Cours 1 : Adaptation et configuration d'un package de support de carte électronique (BSP) 237 Tableau 5 5 Fonction Fonctions de prise en charge du démarrage du noyau Description OEMNMIHandler OEMPowerOff Gestionnaire pour l interruption ne pouvant être masquée (spécifique au processeur SHx). Met le micro-processeur en état de suspension et exécute les opérations finales de mise hors tension. KITL (Kernel Independent Transport Layer, couche de transport indépendante noyau) La fonction OEMInit est la principale routine OAL qui initialise les périphériques spécifiques à la carte électronique, configure les variables du noyau, et démarre KITL en faisant passer un IOCTL de KITL au noyau. Si vous avez ajouté et activé KITL dans l image d exécution, le noyau démarre KITL pour le débogage par le biais de plusieurs couches de transport, comme abordé au Chapitre 4, «Débogage et test du système». Le Tableau 5 6 énumère les fonctions que la couche OAL doit comprendre pour activer la prise en charge de KITL sur une nouvelle plate-forme. Tableau 5 6 Fonction Fonctions de prise en charge de KITL Description OEMKitlInit OEMKitlGetSecs TransportDecode TransportEnableInt TransportEncode TransportGetDevCfg TransportReceive TransportSend KitlInit Initialise KITL. Retourne l heure actuelle en secondes. Décodes les trames reçues. Active ou désactive l interruption de KITL si basé sur les interruptions. Code des données en fonction de la structure de trame requise par le transport. Extrait la configuration du transport KITL du terminal. Reçoit une trame du transport. Envoie une trame par le biais du transport. Initialise le système KITL.
238 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Tableau 5 6 Fonction Fonctions de prise en charge de KITL Description KitlSendRawData KitlSetTimerCallback KitlStopTimerCallback Envoie des données brutes à l aide du transport en contournant le protocole. Enregistre un rappel qui est appelé après un laps de temps spécifié. Désactive un chronomètre utilisé par la routine précédente. Prise en charge d horloge de profils Situé au sein du système d exploitation, la couche OAL est un choix idéal pour les mécanismes qui doivent mesurer la performance du système et prendre en charge l optimisation des performances. Comme abordé au Chapitre 3, «Programmation du système», vous pouvez utiliser l outil ILTiming (Interrupt Latency Timing) pour mesurer le temps nécessaire pour invoquer une routine ISR (Interrupt Service Routine, routine du service d'interruption) après une interruption (latence d ISR) et la durée entre le moment où l ISR se termine et celui où l IST (Interrupt Service Thread, thread du service d interruption) commence (latence d IST). Toutefois, cet outil nécessite une horloge matérielle callée sur le battement système ou toute autre horloge haute résolution qui n est pas disponible sur toutes les plates-formes. Si la nouvelle plate-forme matérielle prend en charge une horloge matérielle haute résolution, vous pouvez prendre en charge ILTiming et des outils similaires en implémentant les fonctions énumérées au Tableau 5 7. Tableau 5 7 Fonction Fonctions de prise en charge d horloge de profils Description OEMProfileTimerEnable OEMProfileTimerDisable Active une horloge de profileur. Désactive une horloge de profileur. REMARQUE Planification de threads et traitement des interruptions La couche OAL doit également prendre en charge le traitement des interruptions et l ordonnanceur de tâches du noyau. L ordonnanceur est indépendant du type du processeur, cependant le traitement des interruptions doit être optimisé pour différent types de processeurs.
Cours 1 : Adaptation et configuration d'un package de support de carte électronique (BSP) 239 Intégration de nouveaux pilotes de périphériques Outre les fonctions système principales, le BSP contient les pilotes de périphériques des terminaux. Ces périphériques peuvent être des composants de la puce du processeur ou des composants externes. Même lorsqu ils sont distincts du processeur, ils demeurent une partie intégrante de la plate-forme matérielle. Emplacements du code de pilotes de périphériques Le Tableau 5 8 contient les emplacements du code source des pilotes de périphériques en fonction du modèle PQOAL. Si votre BSP est basé sur le même processeur que le BSP de référence, l adaptation des pilotes de périphériques nécessite principalement la modification du code source situé dans le dossier %_TGTPLATROOT%. Il est également possible d ajouter de nouveaux pilotes au BSP si la nouvelle plate-forme comprend des périphériques qui ne sont pas présents sur la plate-forme de référence. Pour plus d informations sur le développement de pilotes de périphériques, voir le Chapitre 6, «Développement de pilotes de périphériques». Tableau 5 8 Dossier Dossier de code source des pilotes de périphériques Description %_WINCEROOT%\Platform\%_TGTPLAT%\Src %_WINCEROOT%\Platform\Common\Src\Soc %_WINCEROOT%\Public\Common\Oak\Drivers Contient les pilotes dépendants de la plate-forme. Contient les pilotes des périphériques natifs du processeur. Contient les pilotes des périphériques non natifs du processeur qui incluent les contrôleurs externes. Modification des fichiers de configuration Si vous avez cloné votre BSP à partir d'un BSP existant, tous les fichiers de configuration sont déjà en place. Toutefois, il est important de réviser l organisation de la mémoire dans le fichier Config.bib, comme expliqué en détail dans le Cours 2. Vous ne devez modifier les autres fichiers de configuration que si vous avez ajouté de nouveaux pilotes ou modifié des composants du BSP, comme expliqué au Chapitre 2, «Création et déploiement d une image d exécution».
240 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Récapitulatif du cours Il est avantageux de commencer le processus de développement d un BSP en clonant un BSP de référence adéquat. De manière idéale, ce BSP doit être basé sur une plateforme matérielle identique ou similaire, pour tirer parti au maximum des fonctionnalités de production testées et éprouvées. Windows Embedded CE comprend une architecture PQOAL et des outils de Platform Builder qui facilitent le processus de clonage. L objectif est de créer un système bootable à l aide d un minimum de personnalisations, puis d ajouter des fonctionnalités supplémentaires et la prise en charge de périphériques selon les besoins. Le premier composant de BSP qu il vous faudra sans doute adapter est le bootloader, qui est chargé d initialiser la plate-forme matérielle et de faire passer l exécution au noyau. Le second composant est la couche OAL, qui contient le code spécifique à la plate-forme nécessaire au noyau pour l initialisation du matériel, le traitement des interruptions, et la gestion de l horloge du planificateur de threads, KITL, et la sortie de débogage du noyau. La troisième partie du BSP à adapter est constituée des pilotes de périphériques des terminaux. La quatrième partie du BSP nécessitant une adaptation regroupe les fichiers de configuration qui contrôlent le processus de génération, déterminent l organisation de la mémoire, et spécifient les paramètres de configuration du système. Si l adaptation du BSP est basée sur un BSP de référence pour la même architecture de processeur, la plupart du code de BSP lié au microprocesseur et lié au contrôleur de mémoire peut demeurer inchangée. Vous ne devez adresser que les portions du code spécifique à la plate-forme qui ont pour but de démarrer le matériel, au lieu de créer la configuration nécessaire pour le BSP.
Cours 2 : Configuration du mappage de mémoire d un BSP 241 Cours 2 : Configuration du mappage de mémoire d un BSP La gestion de la mémoire dans Windows Embedded CE a considérablement changé par rapport aux versions précédentes. Dans les versions antérieures, tous les processus partageaient le même espace d adressage de 4 Go. Dans CE 6.0, chaque processus a son propre espace d'adressage unique. Le nouveau système de gestion de la mémoire virtuelle permet à CE 6.0 d exécuter jusqu à 32 768 processus, alors qu auparavant, la limite était de 32 processus. Ce cours traite des détails de la nouvelle architecture et gestion de la mémoire afin que vous puissiez mapper correctement les régions de mémoire virtuelle sur les adresses de mémoire physique de la plate-forme. Après ce cours, vous serez à même de : Décrire comment Windows Embedded CE gère la mémoire virtuelle. Configurer les mappages de mémoire statique pour une plate-forme matérielle. Mapper la mémoire physique non contiguë à la mémoire virtuelle du système. Partager des ressources entre la couche OAL et les pilotes de périphériques. Durée approximative du cours : 15 minutes. Mappage de la mémoire système Windows Embedded CE utilise un système paginé de gestion de la mémoire virtuelle avec un espace d adressage virtuel de 32 bits, mappé sur la mémoire physique à l aide de la MMU. Avec 32 bits, le système peut adresser un total de 4 Go de mémoire virtuelle, que CE 6.0 divise en deux zones, comme suit (voir la Figure 5 5) : Espace noyau Situé dans les 2 Go supérieurs de mémoire virtuelle et partagé par tous les processus d applications s exécutant sur le terminal cible. Espace utilisateur Situé dans les 2 Go inférieurs de mémoire virtuelle et utilisé exclusivement par chaque processus individuel. Chaque processus a son propre espace d'adressage unique. Le noyau gère ce mappage de l espace d adressage du processus lorsqu un changement de processus se produit. Les processus ne peuvent pas directement accéder à l espace d adressage du noyau.
242 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) 2 Go d'espace noyau Système de fichiers du noyau Pilotes GWES 2 Go de mémoire virtuelle par processus Fichiers mappés sur la mémoire DLL utilisateur Code de processus Figure 5 5 Espace de mémoire virtuelle dans Windows Embedded CE 6.0 Espace d adressage du noyau 32 Ko de processus Windows Embedded CE 6.0 divise encore l espace d adressage du noyau en plusieurs régions dans un but précis, comme illustré à la Figure 5 6. Les deux régions inférieures de 512 Mo mappent chacune statiquement la mémoire physique dans la mémoire virtuelle en cache ou hors du cache. Les deux régions du milieu pour les DLL XIP (execute in place) du noyau et la banque d objets sont importantes pour l OS design. L espace restant est réservé aux modules du noyau et pour des opérations spécifiques au micro-processeur.
Cours 2 : Configuration du mappage de mémoire d un BSP 243 MV spécifique à l'uc MV du noyau (si pris en charge par l'uc) 256 Mo Espace du noyau 2 Giga-octets Fixe Mappage indépendant de l'espace utilisateur MV du noyau 256 Mo Magasin d'objets (128 Mo) DLL XIP du noyau (128 Mo) Mappés de manière statique Non mis en cache 512 Mo Mappés de manière statique Mis en cach 512 Mo Figure 5 6 Espace du noyau dans Windows Embedded CE 6.0 Le Tableau 5 9 comprend les régions de la mémoire virtuelle du noyau et leurs adresses de début et de fin. Tableau 5 9 Adresse de début Régions de mémoire du noyau Adresse de fin Description 0xF0000000 0xFFFFFFFF Utilisé pour les interruptions système spécifiques au micro-processeur et les pages de données du noyau. 0xE0000000 0xEFFFFFFF Machine virtuelle du noyau, dépendante du micro-processeur, par exemple cet espace n est pas disponible pour SHx. 0xD0000000 0xDFFFFFFF Utilisé pour tous les modules en mode noyau du système d'exploitation. 0xC8000000 0xCFFFFFFF Banque d objets utilisée pour le système de fichiers RAM, la base de données et la base de registre. 0xC0000000 0xC7FFFFFF DLL XIP.
244 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Tableau 5 9 Adresse de début Régions de mémoire du noyau Adresse de fin 0xA0000000 0xBFFFFFFF Mappage non mis en cache de la mémoire physique. 0x80000000 0x9FFFFFFF Mappage mis en cache de la mémoire physique. Espace d'adressage du processus Description L espace d'adressage du processus s étend de 0x00000000 à 0x7FFFFFFF, et est divisé en une section de données du noyau dépendante du micro-processeur, quatre régions principales de processus, et un tampon de 1 Mo entre les espaces utilisateur et du noyau. La Figure 5 7 illustre les régions principales. La première région de processus de 1 Go est dédiée aux données et au code d application. La région de processus suivante de 512 Mo est dédiée aux DLL et aux données en lecture seule. Les deux régions suivantes de 256 Mo et 255 Mo sont réservées aux objets mappés sur la mémoire et au segment de mémoire système partagé. Le segment de mémoire système partagé est en lecture seule pour le processus d application, mais accessible en lecture et en écriture pour le noyau. Espace utilisateur 2 Giga-octets Chaque prodcessus a son propre mappage Segment de mémoire système partagé 255 Mo Fichiers de mappage sauvegardés dans la RAM 256 Mo DLL utilisateur partagées 512 Mo Espace de processus 1 Go de processus Figure 5 7 Espace de processus dans Windows Embedded CE 6.0 Le Tableau 5 10 récapitule les régions de mémoire virtuelle de l espace utilisateur et leurs adresses de début et de fin.
Cours 2 : Configuration du mappage de mémoire d un BSP 245 Tableau 5 10 Adresse de début Région de la mémoire pour les processus Adresse de fin Description 0x7FF00000 0x7FFFFFFF Un tampon non mappé pour la protection entre les espaces utilisateur et du noyau. 0x70000000 0x7FEFFFFF Segment de mémoire partagé par le noyau et les processus. 0x60000000 0x6FFFFFFF Objets fichier mappés sur la mémoire qui ne correspond pas à un réel fichier physique, principalement pour la compatibilité descendante avec des applications qui utilisent des fichiers de mappage enregistrés dans la RAM pour la communication entre les processus. 0x40000000 0x5FFFFFFF DLL chargées dans le processus et données en lecture seule. 0x00010000 0x3FFFFFFF Données et code d application. 0x00000000 0x00010000 Données du noyau utilisateur dépendantes du micro-processeur (en lecture seule pour les processus utilisateur). Unité de gestion de la mémoire Windows Embedded CE 6.0 requiert que le processeur fournisse un mécanisme de mappage de la mémoire pour associer la mémoire physique à la mémoire virtuelle, jusqu à un maximum de 512 Mo de mémoire physique mappée. La Figure 5 8 montre un exemple de 32 Mo mémoire flash et 64 Mo de RAM mappés dans les régions de mappage statique mises en cache et non mises en cache du noyau. Sur les plates-formes basées sur ARM et basées sur x86, le mappage de la mémoire utilise une table OEMAddressTable définie par l utilisateur, alors que sur les plates-formes basées sur SHx et basées sur MIPS, le mappage est défini directement par le microprocesseur. L unité de gestion de la mémoire (MMU) est chargée d administrer les mappages d adresses physiques sur des adresses virtuelles.
246 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Mémoire physique Mémoire virtuelle Espace du noyau FFFF FFFF 32 Mo Flash 64 Mo RAM 512 Mo Non mis en cache C000 0000 A000 0000 82000000 04000000 Figure 5 8 32 Mo Flash 32 Mo Flash 64 Mo RAM 512 Mo Mis en cache 2 Go Utilisateur 8000 0000 64 Mo RAM Espace Traduction utilisateur 00000000 d'adresses 0000 0000 Exemple de mappage d adresses physiques sur des adresses virtuelles REMARQUE Initialisation de MMU Le noyau initialise la MMU et crée les tableaux de pages nécessaires pour le démarrage du système. Cette partie du noyau spécifique au processeur dépend de l architecture de la plateforme matérielle. Pour des détails sur l implémentation, voir le code privé de Windows Embedded CE, situé dans les sous-répertoires par type de processeur sous %_PRIVATEROOT%\Winceos\Coreos\Kernel. Adresses virtuelles mappées statiquement Les régions de mémoire virtuelle décrites à la Figure 5 8 sont des adresses virtuelles mappées statiquement pour souligner le fait qu elles sont définies lors du démarrage et que le mappage ne change pas. Les adresses virtuelles mappées statiquement sont toujours disponibles et directement accessibles en mode noyau. Il est important de noter, toutefois, que Windows Embedded CE prend également en charge le mappage statique au moment de l exécution par le biais des API CreateStaticMapping et NKCreateStaticMapping. Ces fonctions retournent une adresse virtuelle non mise en cache mappée sur l adresse physique spécifiée.
Cours 2 : Configuration du mappage de mémoire d un BSP 247 Adresses virtuelles mappées dynamiquement Le noyau peut également administrer le mappage d adresses physiques sur des adresses virtuelles de manière dynamique, ce qui est la technique utilisée pour tous les mappages non statiques. Un pilote ou une DLL chargés dans le noyau par le biais de LoadKernelLibrary peuvent réserver une région de mémoire virtuelle dans l espace d adressage du noyau en appelant VirtualAlloc, puis mapper l adresse virtuelle sur l adresse physique en créant une nouvelle entrée de table de page par le biais d un appel de VirtualCopy. Ceci est une technique commune pour mapper des adresses virtuelles sur les bases de registre ou les tampons de trame de périphériques pour exécuter des opérations d'entrée/de sortie. Si le tampon mappé n est plus utile, le pilote de périphérique ou la DLL peut appeler VirtualFree pour supprimer l entrée de table de page et libérer la mémoire virtuelle allouée. Mappage de la mémoire et le BSP Vous devez personnaliser deux éléments pour inclure des informations sur les mappages de mémoire statique dans un BSP : Fichier Config.bib Fournit des informations sur la manière dont le système doit utiliser les différentes régions de la mémoire sur la plate-forme. Par exemple, vous pouvez spécifier combien de mémoire est disponible pour le système d exploitation, quelle quantité peut être utilisée en tant que RAM disponible et également réserver de la mémoire pour des besoins spécifiques. OEMAddressTable Fournit des informations sur l organisation de la mémoire de la plate-forme, comme abordé au Cours 1. La mémoire spécifiée dans Config.bib doit également être mappée dans la table OEMAddressTable. Mappage de la mémoire physique non contiguë Comme mentionné au Chapitre 2, «Création et déploiement d une image d exécution», vous devez définir une seule région contiguë dans la région de mémoire RAMIMAGE pour le système d exploitation dans la section MEMORY du fichier Config.bib. Le système utilise cette définition pour charger l image du noyau et tous les éventuels modules que vous avez spécifiés dans les sections MODULES et FILES. Vous ne pouvez pas définir plusieurs régions RAMIMAGE, mais la couche OAL peut étendre la région RAMIMAGE et fournir des sections de mémoire non contiguës au moment de l'exécution.
248 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Tableau 5 11 récapitule d'importantes variables et fonctions pour étendre la région de RAM. Tableau 5 11 Variable/Fonction Variables et fonctions pour étendre la région de RAM MainMemoryEndAddress OEMGetExtensionDRAM pnkenumextensiondram Description Cette variable indique la fin de la région de RAM. Le noyau définit initialement cette variable en fonction de la taille réservée pour le système d exploitation dans le fichier Config.bib. La fonction OAL OEMInit peut mettre à jour cette variable si de la mémoire contiguë additionnelle est disponible. La couche OAL peut utiliser cette fonction pour signaler la présence d une région additionnelle de mémoire non contiguë au noyau. OEMGetExtensionDRAM retourne l adresse de début et la longueur de la deuxième région de mémoire. La couche OAL peut utiliser ce pointeur de fonction pour signaler la présence de plusieurs régions de mémoire additionnelles au noyau. Ce mécanisme prend en charge un maximum de 15 régions de mémoire non contiguë distinctes. Si vous implémentez le pointeur de fonction pnkenumextensiondram, alors OEMGetExtensionDRAM n est pas appelé pendant le processus de démarrage Activation du partage des ressources entre les pilotes et la couche OAL Les pilotes de périphériques doivent souvent accéder à des ressources physiques, comme les tampons DMA et les registres mappés sur la mémoire, mais les pilotes ne peuvent pas accéder directement à la mémoire physique car le système ne travaille qu'avec les adresses virtuelles. Pour que pilotes de périphériques puissent accéder à la mémoire physique, les adresses physiques doivent être mappées sur les adresses virtuelles.
Cours 2 : Configuration du mappage de mémoire d un BSP 249 Accès dynamique à la mémoire physique Si un pilote requiert de la mémoire physiquement contiguë, comme dans le cas des tampons requis pour les opérations DMA, le pilote peut allouer des la mémoire physique contiguë à l aide de la fonction AllocPhysMem. Si l allocation réussit, AllocPhysMem retourne un pointeur à l adresse virtuelle qui correspond à l adresse physique spécifiée. Comme le système alloue de la mémoire, il est important de libérer la mémoire plus tard lorsqu il n est plus nécessaire en appelant FreePhysMem. D autre part, si un pilote nécessite l accès non paginé à une région de mémoire physique définie dans Config.bib, vous pouvez utiliser la fonction MmMapIoSpace. MmMapIoSpace retourne une adresse virtuelle non paginée qui est directement mappées sur l adresse physique spécifiée. Cette fonction est généralement utilisée pour accéder aux bases de registre de terminaux. Réservation statique de mémoire physique Occasionnellement, il peut être nécessaire de partager une région commune de mémoire physique entre des pilotes ou entre un pilote et la couche OAL (par exemple entre une IST et une ISR). Tout comme le partage d une région de mémoire pour des arguments de démarrage entre le bootloader et le noyau, vous pouvez réserver une région de mémoire partagée pour la communication de pilotes dans le fichier Config.bib. Une pratique standard est d utiliser la structure DRIVER_GLOBALS définie dans Drv_glob.h, comme mentionné dans le Cours 1. Communication entre les pilotes et la couche OAL Outre l ensemble standard d IOCTL requis par le noyau, les pilotes peuvent communiquer avec la couche OAL par le biais d IOCTL personnalisés implémentés dans OEMIoControl. Les pilotes en mode noyau appellent OEMIoControl indirectement par le biais de KernelIoControl, en passant dans l IOCTL personnalisé. Le noyau n effectue aucun traitement, excepté le passage des paramètres directement par le biais de OEMIoControl. Toutefois, les pilotes en mode utilisateur ne peuvent pas appeler directement les IOCTL personnalisés de la couche OAL par défaut. Les appels de KernelIOControl à partir de processus ou pilotes en mode utilisateur sont passés à OEMIoControl par le biais d un composant en mode noyau (Oalioctl.dll), qui maintient une liste de code IOCTL OAL accessible par l utilisateur. L appel est rejeté si le code IOCTL requis n est pas listé dans ce module, mais vous pouvez personnaliser cette liste en modifiant le fichier Oalioctl.cpp qui est situé dans le dossier %_WINCEROOT%\Public\Common\Oak\Oalioctl.
250 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Récapitulatif du cours Une bonne connaissance de l architecture de la mémoire de Windows Embedded CE 6.0 est indispensable pour les développeurs CE. Particulièrement pour les développeurs de BSP, il est important de savoir comment CE 6.0 mappe la mémoire physique disponible dans l'espace d adressage de la mémoire virtuelle. L accès à la mémoire à partir de la couche OAL, les modules en mode noyau, et les pilotes et applications en mode utilisateur requièrent une connaissance approfondie des techniques de mappage statique et dynamique qui sont disponibles en mode noyau ou en mode utilisateur. Pour plus d informations sur la communication entre composants en mode noyau ou en mode utilisateur, voir le Chapitre 6, «Développement de pilotes de périphériques».
Cours 3 : Ajout de la prise en charge de la gestion de l alimentation à une couche OAL 251 Cours 3 : Ajout de la prise en charge de la gestion de l alimentation à une couche OAL Comme abordé au Chapitre 3, «Programmation du système», Windows Embedded CE 6.0 fournit un ensemble complet de fonctionnalités de gestion de l alimentation basées sur un composant de gestion de l alimentation que les développeurs OEM peuvent personnaliser pour implémenter les définitions d état de l'alimentation comme approprié pour leurs plates-formes matérielles. En relation avec la couche OAL, l implémentation de fonctionnalités de gestion de l alimentation est une tâche à deux étapes. Vous devez permettre au système d exploitation de contrôler l état de l alimentation des composants matériels et vous devez permettre à la plate-forme matérielle d informer le système d exploitation des éventuels changements de l état de l alimentation. La plupart des terminaux embarqués nécessitent au moins une prise en charge basique de la gestion de l alimentation pour réduire la consommation d énergie et prolonger la durée de vie de la batterie. Après ce cours, vous serez à même de : Décrire comment réduire la consommation du processeur en énergie. Identifier les chemins de transition pour suspendre et reprendre l exécution du système. Durée approximative du cours : 15 minutes. Transitions d états d alimentation Les terminaux embarqués qui ne sont pas constamment en cours d utilisation, comme les assistants numériques personnels (PDA), fonctionnent pendant des périodes de temps étendues en état inactif, permettant ainsi de préserver de l énergie en passant du mode d alimentation maximale au mode d alimentation réduite ou à l'état de suspension. La plupart des processeurs disponibles sur le marché et utilisés dans ce genre de terminaux prennent en charge ces transitions, comme illustré à la Figure 5 9.
252 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Sous tension Démarrage à froid Démarrage à chaud Initialiser le système de fichiers Initialiser la mémoire RAM Alimentation maximale Nouvelle batterie Batterie très faible Interruption Pas de thread à exécuter Événement de mise en éveil Délai d'inactivité Mise hors tension critique Inactif Supension Figure 5 9 Transitions d état de l alimentation Windows Embedded CE peut répondre aux événements liés à l alimentation des manières suivantes : Batterie très faible Le système passe en état de mise hors tension critique (Critical Off) en réponse à une interruption non-masquable (NMI) déclenchée par un comparateur de tension de la carte, afin que l utilisateur puisse remplacer la batterie et continuer. Inactif Le système fait passer le micro-processeur en mode d alimentation réduite si le système n a aucun thread de travail à exécuter et se réveille lorsqu une interruption se produit. Suspendu Le système fait passer le terminal en état de suspension lorsque l utilisateur appuie sur le bouton Arrêt ou en réponse à une expiration de délai d'inactivité et continue de s exécuter en réponse à un événement de réveil, comme lorsque l utilisateur appuie à nouveau sur le bouton d'alimentation. Sur certains terminaux embarqués, l état de suspension correspond à un réel état de mise hors tension, auquel cas le système continue de s'exécuter avec un démarrage à froid.
Cours 3 : Ajout de la prise en charge de la gestion de l alimentation à une couche OAL 253 Réduction de la consommation d énergie en mode Inactif Pour faire passer le terminal en mode d alimentation réduite, Windows Embedded CE se repose sur la fonction OEMIdle, que le noyau appelle lorsque l ordonnanceur n'a aucun thread à exécuter. La fonction OEMIdle est une routine spécifique au matériel qui dépend des fonctionnalités de la plate-forme. Par exemple, si l horloge système utilise un intervalle fixe, la fonction OEMIdle ne peut pas réellement fournir la fonctionnalité d économie d énergie attendue car le système se réveille chaque fois qu une interruption d horloge se produit. D autre part, si le processeur prend en charge les horloges d intervalles programmables, vous pouvez utiliser la variable dwreschedtime du noyau pour spécifier la quantité de temps passée en mode d alimentation réduite. A sa sortie du mode d alimentation réduite, le système doit mettre à jour les variables globales du noyau utilisées par l ordonnanceur. Ceci est particulièrement important pour la variable CurMSec, que le système utilise pour effectuer le suivi du nombre de millisecondes écoulées depuis le dernier démarrage du système. La source du réveil peut être l horloge système ou une autre interruption. Si la source du réveil est l horloge système, la variable CurMSec est déjà mise à jour avant que l exécution ne soit à nouveau passée à la fonction OEMIdle. Dans d autres cas, la variable CurMSec ne contient pas de valeur mise à jour. Pour plus de détail sur l implémentation de OEMIdle, voir le fichier de code source Idle.c, situé dans le dossier %_WINCEROOT%\Platform\Common\Src\Common\Timer\Idle. REMARQUE Variables globales du noyau Pour des informations détaillées sur les variables globales que le noyau exporte pour la planification, voir la section «Kernel Global Variables for Scheduling» de la documentation de Windows Embedded CE 6.0, disponible sur le site Web Microsoft MSDN à l adresse http :// msdn.microsoft.com/en-us/library/aa915099.aspx. Mise hors tension et suspension du système L état d économie d énergie maximale qu un terminal Windows Embedded CE peut prendre en charge est l état de mise hors tension (Power Off) ou de suspension (Suspend). Le système peut demander que le terminal entre dans l état de suspension en appelant GwesPowerOffSystem directement ou SetSystemPowerState. Les deux fonctions appellent finalement la routine OEMPowerOff.
254 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) La routine OEMPowerOff fait partie de la couche OAL et est chargée du passage du micro-processeur en état de suspension. OEMPowerOff doit également mettre la RAM en mode d actualisation automatique si le processeur ne le fait pas automatiquement lorsqu il entre en état de suspension. Vous pouvez également configurer les interruptions pour réveiller le terminal. Dans les terminaux de poche, il s agit généralement de l interruption du bouton d alimentation, mais vous pouvez utiliser n importe quelle source d événement de réveil appropriée pour votre plate-forme cible. Passage à l état de suspension Lors du passage à l état de suspension, Windows Embedded CE exécute la séquence d étapes suivante : 1. GWES notifie la Barre des tâches de l événement de mise hors tension. 2. Le système abandonne l'étalonnage si dans l écran d étalonnage. 3. Le système arrête les files d attente de messages Windows. Après l étape 3, le système passe en mode mono- thread, qui empêche les appels de fonction qui se reposent sur des opérations bloquantes. 4. Le système vérifie si l interface utilisateur de démarrage doit être affichée à la reprise. 5. Le système enregistre la mémoire vidéo dans la RAM. 6. Le système appelle SetSystemPowerState (NULL, POWER_STATE_SUSPEND, POWER_FORCE). 7. Le gestionnaire d alimentation Power Manager : a. Appelle la fonction FileSystemPowerFunction pour mettre hors tension les pilotes apparentés au système de fichiers. b. Appelle PowerOffSystem pour demander au noyau d effectuer la mise hors tension finale. c. Appelle Sleep(0) pour invoquer le planificateur. REMARQUE FileSystemPowerFunction et PowerOffSystem Si l OS design n inclut pas Power Manager ou GWES, l OEM doit explicitement appeler FileSystemPowerFunction et PowerOffSystem. 8. Le noyau : d. Décharge le processus GWES.
Cours 3 : Ajout de la prise en charge de la gestion de l alimentation à une couche OAL 255 e. Décharge Filesys.exe. f. Appelle OEMPowerOff. 9. OEMPowerOff configure les interruptions et met le micro-processeur en état de suspension. Sortie de l état de suspension Lorsqu une interruption pré-configurée réveille le système, l ISR associée s exécute et retourne à la routine OEMPowerOff. Lors du retour de cette fonction, le système exécute la séquence de reprise, qui inclut les étapes suivantes : 1. OEMPowerOff reconfigure les interruptions avec leur état d origine et retourne. 2. Le noyau : g. Appelle InitClock pour réinitialiser l horloge système. h. Lance Filesys.exe avec la notification d alimentation. i. Lance GWES avec la notification d alimentation. j. Réinitialise l interruption KITL si elle était en cours d'utilisation. 3. Power Manager appelle FileSystemPowerFunction KITL avec la notification d alimentation. 4. GWES : k. Restaure la mémoire vidéo à partir de la RAM. l. Met Windows Manager sous tension. m. Définit le contraste de l affichage. n. Affiche l interface utilisateur si nécessaire. o. Notifie la Barre des tâches de la reprise. p. Notifie le sous-système utilisateur. q. Déclenche des applications selon les besoins. REMARQUE Enregistrement de sources de réveil Si la couche OAL prend en charge IOCTL_HAL_ENABLE_WAKE du noyau, les applications peuvent enregistrer les sources de réveil. Pour des informations détaillées, voir la section «IOCTL_HAL_ENABLE_WAKE» de la documentation de Windows Embedded CE 6.0, disponible sur le site Web Microsoft MSDN à l adresse http ://msdn2.microsoft.com/en-us/ library/aa914884.aspx.
256 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) Prise en charge de l état de mise hors tension critique (Critical Off) Sur les plates-formes matérielles équipées d un comparateur de tension qui déclenche NMI, vous pouvez implémenter la prise en charge de l état de mise hors tension critique (Critical Off) pour protéger l utilisateur des éventuelles pertes de données au cas où la batterie deviendrait faible. Sur du matériel x86, le noyau exporte la fonction OEMNMIHandler pour capturer les événements critiques dans le système. Sur les autres systèmes, vous devrez peut-être implémenter une IST personnalisée qui appelle SetSystemPowerState pour mettre le système hors tension de manière fluide avec l aide de Power Manager. L état de mise hors tension critique (Critical Off) correspond généralement à l état de suspension (Suspend) avec l actualisation de la mémoire RAM dynamique activée. REMARQUE Le niveau de batterie atteint zéro Lors de l implémentation de la prise en charge de l état mise hors tension critique (Critical Off), assurez-vous de déclencher le NMI à un point où le système a encore le temps d exécuter toutes les tâches de mise hors tension, comme la mise hors tension des périphériques, l actualisation automatique de la RAM, la définition d une condition de réveil, et la suspension du micro-processeur. Récapitulatif du cours La gestion de l alimentation est une importante fonctionnalité de Windows Embedded CE qui garantit une consommation d énergie efficace sur les terminaux cibles. Les OEM devraient implémenter des fonctionnalités de gestion de l alimentation dans la couche OAL pour permettre les transitions du mode d alimentation vers les modes inactif (Idle) et de suspension (Suspend) et vers l état de mise hors tension critique (Critical Off) pour les périphériques alimentés par batterie. L implémentation de la prise en charge de la gestion de l alimentation nécessite la re-synchronisation des variables du noyau liées à l horloge, la mise hors tension de périphériques, la mise de la RAM en mode d actualisation automatique, la définition de conditions de réveil, et la suspension du micro-processeur. Il n est pas trivial d implémenter ces routines de bas niveau, mais Microsoft fournit suffisamment de code de référence dans les exemples de BSP pour que vous compreniez mieux les détails de l implémentation.
Atelier 5 : Adaptation d un package de support de carte électronique 257 Atelier 5 : Adaptation d un package de support de carte électronique Au cours de cet atelier, vous allez cloner un BSP de référence dans Visual Studio 2005 avec Platform Builder et l utiliser pour générer une image d exécution. En tant que plate-forme sous-jacente, cet atelier utilise Device Emulator car cette plate-forme peut s exécuter sur l ordinateur de développement de Windows Embedded CE. Microsoft a inclut le BSP Device Emulator dans Platform Builder en tant que BSP de référence. REMARQUE Instructions détaillées Pour vous aider à maîtriser les procédures présentées lors de cet atelier, consultez le document «Instructions détaillées pour l Atelier 5», inclus dans la documentation associée à ce manuel. Clonez un BSP 1. Dans Visual Studio 2005, ouvrez le menu Outils, cliquez sur Platform Builder For CE 6.0, puis cliquez sur Clone BSP (Cloner un BSP). 2. Dans la fenêtre Clone Board Support Package (Cloner un package de support de carte électronique), sélectionnez Device Emulator : ARMV4I comme BSP Source dans la liste déroulante. 3. Sous New BSP Information (Informations sur le nouveau BSP), entrez les informations figurant dans le Tableau 5 12 (voir aussi la Figure 5 10) : Tabelle 5.12 Paramètre Détails sur le nouveau BSP Valeur Nom Description Répertoire de plate-forme Fabricant DeviceEmulatorClone Clone du BSP Device Emulator DeviceEmulatorClone Contoso S.A. Version 0.0 4. Activez la case à cocher Open New BSP Catalog File In Catalog Editor (Ouvrir un nouveau fichier de catalogue de BSP dans l éditeur de catalogue) puis cliquez sur Clone (Cloner).
258 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) 5. Vérifiez que Platform Builder clone le BSP Device Emulator, puis cliquez sur OK dans la boîte de dialogue Clone BSP (Cloner un BSP). 6. Vérifiez que Visual Studio ouvre automatiquement le fichier de catalogue DeviceEmulatorClone.pbcxml. Fermez l éditeur de catalogue sans effectuer aucune modification. Figure 5 10 Informations de clonage d un BSP Créez une image d exécution 1. Pour valider votre BSP cloné, créez un nouvel OS design basé sur le BSP DeviceEmulatorClone. Appelez l OS design DeviceEmulatorCloneTest, comme illustré à la Figure 5 11 (voir aussi l Atelier 1 au Chapitre 1 pour des détails sur l accomplissement de cette étape). 2. Choisissez Industrial Device (Terminal industriel) dans Design Templates (Modèles de conception) et Industrial Controller (Contrôleur industriel) dans Design Template Variants (Variantes de modèle de conception). Acceptez les options par défaut lors des étapes suivantes de l assistant. 3. Une fois que Platform Builder a généré le projet DeviceEmulatorCloneTest, vérifiez l OS design en examinant les éléments de catalogue dans l affichage Catalog Items View (Affichage des éléments du catalogue). 4. Vérifiez que la configuration de conception Debug est activée en ouvrant le Gestionnaire de configurations à partir du menu Générer et en vérifiant que la zone de liste Configuration de la solution active affiche DeviceEmulatorClone ARMV4I Debug. 5. Dans le menu Générer, cliquez sur Générer une solution.
Atelier 5 : Adaptation d un package de support de carte électronique 259 6. Une fois la génération effectuée, configurez les options de connectivité afin d utiliser Device Emulator. 7. Ouvrez le menu Target (Cible) et cliquez sur Attach Device (Attacher un terminal) pour télécharger l image d exécution dans Device Emulator et lancer Windows Embedded CE. Notez les messages de débogage dans la fenêtre Sortie de Visual Studio 2005. Attendez que le terminal ait complètement démarré. Figure 5 11 Un nouvel OS design basé sur le BSP DeviceEmulatorClone REMARQUE Adaptation de BSP Device Emulator émule la même plate-forme matérielle pour le BSP de référence et le BSP cloné. Pour cette raison, la nouvelle image d exécution s exécute sur Device Emulator sans adaptation supplémentaire. En pratique, toutefois, le matériel sous-jacent est différent dans la plupart des cas, nécessitant des adaptations de BSP pour le démarrage réussi de CE. Personnalisez le BSP 1. Détachez du terminal cible et fermez Device Emulator. 2. Dans Visual Studio, ouvrez le fichier de code source init.c situé dans le dossier %_PLATFORMROOT%\DeviceEmulatorClone\Src\Oal\Oallib, comme illustré à la Figure 5 12.
260 Chapitre 5 Personnalisation d un package de support de carte électronique (BSP) 3. Recherchez la fonction OAL OEMGetExtensionDRAM et ajoutez la ligne de code suivante pour imprimer un message de débogage dans la fenêtre Sortie de Visual Studio pendant le démarrage du système. BOOL OEMGetExtensionDRAM( LPDWORD lpmemstart, LPDWORD lpmemlen ) {... OALMSG(OAL_FUNC, (L"++OEMGetExtensionDRAM\r\n")); // Message de test pour confirmer que nos modifications font partie de l image dexécution. OALMSG(1,(TEXT("Cette modification fait partie de l image dexécution.\r\n")));... } 4. Regénérez l image d exécution pour inclure les modifications, puis attachez à nouveau au terminal afin de télécharger et démarrer la nouvelle image d exécution dans Device Emulator. Vérifiez que Windows Embedded CE imprime le message de débogage dans la fenêtre Sortie.
Atelier 5 : Adaptation d un package de support de carte électronique 261 Figure 5 12 Personnalisation du BSP DeviceEmulatorClone