Partie 1 – Génération et téléchargement d’un noyau

Par Olivier Bloch, Relations Techniques Développeurs Embarqué et Mobilité

Sur cette page

Résumé
Introduction
L’OS Design
Téléchargement du noyau

Résumé

Suivant l'annonce de la sortie de la dernière version de Windows CE, cet article présente la génération et la mise au point de noyau et d'application Windows CE 6.0. Il présente les nouveaux outils de développement embarqué (intégrés à Visual Studio 2005) en mettant l'accent sur leur prise en main par les développeurs habitués aux outils des générations précédentes.

Haut de page

Introduction

La dernière version de Windows CE vient de sortir et de nouveaux outils sont désormais disponibles pour le développement embarqué. Dans l'optique de rassembler tous les outils en un seul, Platform Builder, l'outil de génération de noyaux Windows CE, est désormais un plug-in de Visual Studio 2005. Bénéficiant ainsi des fonctionnalités d'édition, de compilation, de configuration et de la richesse des outils de débogue et de monitoring de Visual Studio, Platform Builder n'en reste pas moins un outil dédié aux développeurs du monde de l'embarqué, très proches des considérations liées au Hardware et avec des besoins particuliers.

Ayant une expérience de plusieurs années de développement Windows CE (BSPs, drivers et applications industrielles), j'ai beaucoup pratiqué Platform Builder depuis la version 3.0 à la version 5.0, ainsi qu'Embedded Visual C++ et Embedded Visual Basic. Comme beaucoup d'entre vous, du moins je pense ne pas être une exception, je ne me suis que très peu servi de Visual Studio.

Je vous propose dans cet article de partager mes premières expériences de développement embarqué Windows CE 6.0. Développer un noyau, le télécharger sur une cible, ajouter une application, la déboguer, utiliser les traces de débogue, déboguer un driver, mettre mon application à la place du shell de Windows, le tout sur une vraie cible.

Haut de page

L’OS Design

Bon, et bien maintenant que tous les ingrédients sont là, allons-y.

Je lance Visual Studio 2005 (vu que je suis sous Vista, il faut penser à le lancer en mode administrateur : clic droit/Run As Administrator)… Au premier lancement, on me demande si je veux configurer l’IDE de VS pour le mode "Platform Builder". Un bon point, vu que j’ai bien l’intention de me servir de VS 2005 principalement pour faire des builds Windows CE ! Après m’être assuré que cette configuration était réversible (on ne sait jamais, je ferais peut-être du développement pour PC un de ces jours ;-).

Première impression, on est bien dans Visual Studio. Quelques éléments me rappellent Platform Builder 5, et après un petit tour dans le clicodrome, je retrouve les éléments suivants :

• le menu Target me permettant d’accéder aux fameux Remote Tools dont nous reparlerons plus tard,

• le menu Tools|Platform Builder 6.0 donnant accès à des outils tels que le BSP cloner.

• Il y a aussi un onglet Catalog Items qui me rappelle le catalogue de PB 5 à côté de l’onglet Solution Explorer que les utilisateurs de Visual Studio connaissent bien.

Créons un nouveau projet… Menu File|New Project. L’assistant me propose plusieurs types de projets, dont le type "Platform Builder For CE 6.0" :

Je nomme mon projet et lance l’assistant...

Jusque là, pas de problème, on est dans un monde connu. On sélectionne le BSP sur lequel on veut s’appuyer. Je vous rappelle que je n’ai pas eu à installer quoique ce soit. Mon BSP est présent dans la liste : Platform Builder 6 a parcouru son arborescence et est tombé au sein du BSP de l’eBox, sur le fichier .pbcxml remplaçant le fichier .cec qui décrivait précédemment les composants d’un BSP dans le catalogue de PB.

Ensuite on sélectionne un Template de Design. Je pars sur le "Custom Device" pour pouvoir passer en revue les composants mis à disposition dans le catalogue. J’y retrouve les mêmes que dans PB 5, et remarque quelques nouveautés : je vous laisse les découvrir !

Une fois l’assistant terminé, je vais aller personnaliser cette configuration. La présentation du catalogue et des composants sélectionnés dans le projet PB a changé. Dans PB 5, on avait une fenêtre présentant le catalogue au complet et un onglet dans lequel on avait la liste des composants sélectionnés dans le projet courant ; il fallait faire du drag & drop pour ajouter de nouveaux composants à la configuration. Désormais on a un onglet unique présentant le catalogue : les composants sélectionnés sont repérés par des cases à cocher. On peut identifier les composants que l’on a ajouté soi-même (une coche dans la case), ceux que PB a ajoutés pour des raisons de dépendances (la case est pleine et verte), et les composants qui ne peuvent pas être ajoutés (une croix rouge). Cette vue peut être filtrée pour n’afficher que les composants sélectionnés, et l’on peut aussi très rapidement rechercher un composant. D’ailleurs je m’aperçois que le driver audio de mon BSP ne peut être inclus… Je fais un clic droit et demande à PB la raison de cette interdiction. Il m’indique que je dois ajouter le support Waveform Audio à mon design. Je m’exécute en recherchant ledit composant à l’aide de l’utilitaire de recherche présent en haut du catalogue et en le rajoutant.

Je vais lancer la génération de mon noyau pour pouvoir le tester. Au passage, je vais lancer mon chrono, histoire de voir combien de temps ce build complet prendra. J’en profite pour vous parler de ce processus de génération de noyau.

Il faut tout d’abord rappeler le principe général de l’outil. Lorsque l’on sélectionne un composant dans l’IDE, des variables d’environnement sont mises en place (on peut les consulter en lançant la fenêtre de commande depuis le menu Build|Open Release Directory in Build Window et en tapant la commande SET). Le processus de build va s’appuyer sur ces variables d’environnement pour générer les modules voulus. Le schéma ci-contre montre l’enchaînement des appels.

Dans un premier temps, le batch principal (blddemo.bat) va appeler CEbuild.bat qui est chargé de compiler l’intégralité des modules sélectionnés et de faire l’édition de lien. Dans un second temps, c’est Buildrel.bat qui va rassembler dans un même répertoire, appelé "Release Directory", l’ensemble des binaires générés, ainsi que les fichiers de ressources et de configuration (base de registre, système de fichier, base de données). Enfin, Makeimg.exe utilise ces fichiers de configurations pour constituer l’image à proprement parlé (un fichier binaire unique).

Dans la première étape, cebuild.bat effectue les opérations suivantes :

• Pour chaque projet référencé dans la variable d’environnement _DEPTREES, cebuild.bat va appeler build.exe et générer les binaires dans WINCE600\PUBLIC\nom_du_projet

• Pour chaque projet référencé dans la variable d’environnement _DEPTREES, cebuild.bat va appeler sysgen.bat pour générer les modules des projets dans %_PROJECTROOT%\OAK\MISC

• Ensuite, cebuild.bat lance build.exe dans le répertoire %_PLATFORMROOT%\%_TGTPLAT% pour compiler tous les composants du BSP

Vous trouverez les détails de chacune de ces étapes dans l’aide MSDN de Windows Embedded CE 6.0.

Ma génération s’est terminée en 10 minutes (je suis sur une bonne machine), mais je n’aurai pas à repasser par toutes les étapes de génération à condition de ne pas modifier l’OS Design (c’est le nom du projet dans Platform Builder) en rajoutant ou supprimant un composant.

Haut de page

Téléchargement du noyau

Je vais maintenant télécharger le noyau sur la cible pour voir si tout fonctionne correctement, mais avant, voici un petit point sur les bootloader.

Une cible Windows CE, comme pour la plupart des systèmes d’exploitation, embarque un bootloader qui a pour rôle d’initialiser la carte électronique et de charger le noyau en RAM avant de l’exécuter. Pendant la phase de mise au point, il est très pratique de mettre en œuvre un bootloader particulier permettant de télécharger le noyau depuis une station de travail via un lien Ethernet (eboot) ou série (sboot), l’Ethernet étant bien plus rapide évidemment. Ceci facilite grandement le processus de développement. Eboot (ou sboot) pourra être flashé en Flash ou sur un disque. Il est alors exécuté au démarrage de la cible. Mais il est aussi possible, lorsqu’on ne peut pas placer eBoot en ROM (si l’on ne dispose que d’une mémoire flash et d’aucun outil pour flasher le noyau par exemple) sur une cible de type x86, d’installer DOS et d’utiliser une application nommée loadcepc.exe qui chargera eboot ou sboot en RAM pour l’exécuter. Ces bootloaders de debug sont en grande partie génériques d’une cible à l’autre et le code source est fourni dans l’installation de Platform Builder. Pour la partie propre au hardware, le code source sera inclus dans le Board Support Package fourni par le fabriquant en même temps que les drivers et la couche d’abstraction du hardware.

Eboot, que l’on utilise le plus fréquemment, est un réel bootloader initialisant la carte électronique, puis la carte Ethernet embarquée afin d’établir un lien avec l’outil Platform Builder. Pour ce faire, eboot va broadcaster une trame (BOOTME) sur le réseau. Platform Builder se met à l’écoute de cette trame et référence la cible comme étant disponible pour la connexion.

Ma cible eBox 2300 embarque un CPU x86 Vortex, j’ai un DOS installé et Loadcepc qui s’exécute au démarrage. Je choisi le lien Ethernet.

Du coté de Visual Studio, dans le menu Target|Connectivity Options je configure le lien Ethernet. On notera qu’en termes de moyens de connexion, on retrouve l’Ethernet, le lien série, le lien avec un émulateur, et on a désormais à disposition le lien USB. Je n’aurais pas l’occasion de le tester ici, mais ce sera pour la prochaine fois !

J’ai oublié de parler des traces de debug qui sont émises par eboot sur le lien série. Ces traces sont lisibles sur un terminal et informent du fonctionnement du loader. Ensuite, lorsque le noyau démarrera, il enverra à son tour des traces sur ce lien. Nous verrons plus loin comment utiliser ces traces en rendant plus ou moins loquaces les processus que l’on veut tracer.

Je lance donc eboot via Loadcepc.exe et détecte la cible sur le réseau (cf. copie d’écran ci-dessus).

Une fois cette configuration effectuée, je relance la cible et depuis le menu Target, je lance la commande Attach Device. Le téléchargement du noyau se fait (quelques secondes pour mon noyau compilé en debug et qui fait presque 17 Mo).

Arrivé là, j’ai envie de dire : "Et voilou, Windows Embedded CE 6 tourne sur ma la cible !". Mais les choses sérieuses et amusantes ne font que commencer !

Haut de page