TORNADO II / VxWorks

Transcription

1 TORNADO II / VxWorks Eric Zamaï Bureau d étude Méthodologie de Conception et Informatique Industrielle École Nationale Supérieure d Ingénieurs Électriciens de Grenoble Laboratoire d Automatique de Grenoble Ce document doit rester dans la salle 22 janvier

2 Table des matières I Le Système d Exploitation Multi-Tâche Temps Réel Vx- Works 6 1 Présentation 6 2 Les bases de l OS Concepts de base des tâches TCB Les 5 états des tâches sous VxWorks La gestion des files d attente Les 5 principales tâches système L ordonnancement Le How To de la Gestion des tâches sous vxworks Création et activation d une tâche Suppression d une tâche Différer l exécution d une tâche Obtenir des informations sur les tâches Code partagé et réentrance Les 6 outils de communication inter-tâches La mémoire partagée Les sémaphores Les Boîtes aux Lettres ou Queues Les Tubes ou Pipes Les sockets Les signaux Les interruptions matérielles Les WatchDogs ou Temporisations Gestion des périphériques, mécanismes des descripteurs 25 II L environnement de développement TORNADO II 26 4 Les outils de développement L Éditeur Tornado Un gestionnaire de projets Le compilateur L interpréteur de commande (Shell) Le Debugger CrossWind Le navigateur (Browser) WindView Software Logic Analyzer Le simulateur VxWorks

3 5 Architecture de la chaîne Tornado II Création d une disquette de boot Création d un noyau vxworks Création d une application vxworks Configuration et lancement du serveur FTP Configuration et lancement du serveur cible Lancement du shell Téléchargement d une application Utilisation du debugger III Quelques primitives de base du noyau vxworks 43 6 Primitives liées à la gestion des tâches taskspawn( ) taskdelete( ) Primitives liées à l ordonnancement kerneltimeslice( ) taskdelay( ) tasklock( ) taskunlock( ) tasksafe( ) taskunsafe( ) Primitives liées à la communication entre tâches sembcreate( ) semmcreate( ) semgive( ) semtake( ) msgqcreate( ) msgqsend( ) msgqreceive( ) msgqdelete( ) Primitives liées à la gestion des interruptions intconnect( ) IV Apprentissage par la pratique Création d un bootloader Configuration, création et chargement d un noyau adapté Création d une application multi-tâches Mise en œuvre d une synchronisation entre tâches 56 3

4 14 Mise en œuvre d une communication/synchronisation par BAL 58 V Du SART à la mise en œuvre 60 4

5 Introduction générale 5

6 Première partie Le Système d Exploitation Multi-Tâche Temps Réel VxWorks 1 Présentation L architecture générale de l environnement TORNADO/VXWORKS, peut être vue comme une structure à deux niveaux : le système de développement ( host ), et le système cible ( target ). Le premier fournit tous les outils permettant le développement des applications (projet, éditeur, browser, shell, debugger, outil de mise au point, analyse de code, serveur et simulateur), le deuxième offre une architecture matérielle, support du système d exploitation vxworks et de l application multi-tâche temps réel développée par l utilisateur. Ceci peut être représenté par les figures suivantes (cf. figure 1 et 2) : SYSTEME de DEVELOPPEMENT (HOST) Éditeur Projet Shell Browser Debugger Windview Simulateur vxworks Agent cible Serveur cible TORNADO II SYSTEME CIBLE (TARGET) Application VxWorks Agent cible Fig. 1 Interaction système développement / système cible Comme le montrent ces figures, la communication entre le système de développement et le poste cible se fait par l intermédiaire d un serveur cible situé sur le poste de développement (HOST). L entité logicielle située sur le poste cible et qui assure la communication entre le serveur cible et le système d exploitation est appelée l agent cible. Cette architecture séparée est typique des problèmes industriels dans lesquels une séparation développement / cible est requise. En plus de cette architecture à deux niveaux, TORNADO II propose et fournit un simulateur de cibles qui est en fait exécuté sur le système de développement ; on 6

7 Host development tools Host/Target connexion Target development tools Networking Subsystem I/O Subsystem Operating System WIND micro-kernel Scalable Runtime System Fig. 2 Architecture vxworks parlera ici d émulateur du système cible. Ceci permet au programmeur de développer et tester son application à la condition qu il n y ait aucune inter-action avec l environnement (périphériques d entrées / sorties). 2 Les bases de l OS Un Système d Exploitation dit Multi-Tâche Temps Réel doit permettre de gérer des terminaisons externes (cf. vocabulaire SART) et de réagir aux événements extérieurs en garantissant déterminisme et respect des contraintes temporelles. On se référera à la définition donné par le Groupe de réflexion du CNRS sur le temps réel : Peut-être qualifié de temps réel toute application mettant en oeuvre un système informatique dont le fonctionnement est assujetti à l évolution dynamique de l état réel d un environnement (procédé) qui lui est connecté et dont il doit contrôler le comportement. C est donc l asynchronisme de l évolution par rapport au contrôle automatisé qui est la source des difficultés du temps réel. En résumé, nous retiendrons que le temps intervient dans la validité du programme, à savoir en : garantissant une réactivité en un temps adapté aux événements externes, garantissant un fonctionnement continu sans réduction du flot d information traité, garantissant une maîtrise des temps de calculs qui devront être connus et modélisables pour permettre justement l analyse de la réactivité. Compte tenu de cette définition, la programmation multi-tâche temps réel nous offre tous les moyens requis pour organiser des applications (programmes) collaboratives permettant le pilotage de divers éléments à des vitesses différentes, et selon des priorités spécifiques. Un programme sera appelé une tâche, le multi-tâche donnera une impression de parallélisme d exécution, ce parallélisme étant gérer par un chef d orchestre, le noyau temps réel (gestion de l ordonnancement des tâches). 7

8 Des Interruptions Traitement Communication Gestion des tâches Inter-tâches Horloge Système Sémaphores Gestion mémoire Fig. 3 Le noyau WIND 2.1 Concepts de base des tâches TCB Le noyau VxWorks fournit un environnement complet et puissant de gestion transparente des tâches systèmes et utilisateur. A chaque tâche est associé un contexte dans lequel sont mémorisées les informations processeur et ressources système. Ainsi, une commutation de tâche transite tout d abord par une phase de sauvegarde du contexte de la tâche en cours et la restitution de celui de la prochaine à exécuter. Ce contexte est sauvegardé dans ce que l on appelle un Bloc de Contrôle de Tâche (TCB). Il est organisé de la façon suivante : le contexte processeur : valeurs registre processeur (CPU), compteur de programme de la tâche (PC), pointeur de pile (SP), et optionnellement les registres pour le processeur virgule flottante. la pile pour accueillir les variables dynamiques et les paramètres d appel des fonctions, les informations propres à l OS comme par exemple la priorité des tâches, les compteurs de temps (mise en attente, exécution), assignations des entrées / sorties pour les flux standards, informations pour le debug et le suivi de performance Les 5 états des tâches sous VxWorks Comme nous l avons déjà dit, le rôle du noyau est de gérer l état des différentes tâches (système et utilisateur). Ce dernier s appuie sur le modèle état/transition donné dans la figure 4. Une tâche peut ainsi se trouver dans l un des cinq états suivants : Suspendu (suspended) : état d une tâche indisponible pour l exécution (i.e. état initial d une tâche après création). 8

9 Suppression (Inexistante) Création Suspendu Activation Suspension En attente Prête Différée En exécution Fig. 4 Modèle de gestion des états d une tâche Prête (ready) : état d une tâche qui attend de se voir allouer le CPU pour être exécutée. En exécution (executing) : état d une tâche qui est en cours d exécution. Le CPU est donc alloué à cette tâche. En attente (pended) : état d une tâche qui est bloquée en attente d une ressource (sémaphore, message dans une boîte au lettre (queue),...). Différée (delayed) : état d une tâche qui a été ou qui s est endormie pour une durée déterminée. Si l on suit le cycle de vie d une tâche classique, nous pourrions dire que lorsque l on crée cette tâche, elle est suspendue. Après activation elle passe dans l état prête. Elle est alors éligible pour une exécution, soit une allocation du temps CPU. Cette création/activation est pris en charge par vxworks via la primitive (taskspawn()). Ainsi, parmi l ensemble des tâches éligibles, celle qui a le plus haut niveau de priorité passera dans l état en exécution. Bien entendu, et ce quelque soit son état, la tâche peut être supprimée (taskdelete()) et retourner ainsi dans son état initial inexistante La gestion des files d attente Si nous étudions de plus prés ce mécanisme de gestion des tâches, nous pourrions aisément remarquer que le noyau gère en fait leurs TCB respectifs en s appuyant sur le mécanisme de mises en attente (files) de leurs blocs de contrôle (cf. figure 5). Lorsqu une intervention doit être pratiquée au sein d une file (en attente, différée, suspendue,...), le noyau fait appel à l ordonnanceur Les 5 principales tâches système Vous le remarquerez lors du chargement du noyau sur un poste cible via la commande i sous le shell, vxworks active 5 tâches principales en phase de développement : tusrroot() : elle est la première à être exécutée par le noyau afin d initialiser la plupart des services tels que l horloge système, la gestion des entrées/sorties, les 9

10 Fig. 5 Le noyau et la gestion des files d attentes des TCB pilotes de périphériques,... De plus, cette tâche lance les 4 autres tâches systèmes puis s auto-supprime lorsque les initialisations sont terminées. tlogtask() : tâche de gestion d enregistrements utilisée par les modules de vxworks afin d afficher les messages systèmes sans avoir à réaliser d entrées/sorties dans le contexte courant de la tâche. texctask() : permet de réagir aux exceptions matérielles comme des erreurs bus, erreur d adresse, division par 0,... tnettask() : gère le réseau. twdbtask() : gère la communication poste de développement/cible L ordonnancement La difficulté principale lorsqu un noyau doit gérer un contexte dit multi-tâche est de déterminer quand et comment allouer le processeur (CPU) à l une des tâches accrochées dans la file d attente des tâches prêtes. Pour résoudre ce problème délicat, les noyaux multi-tâches sont dotés d un ordonnanceur généralement configurable selon deux techniques : Ordonnancement de type préemptif, Ordonnancement de type tourniquet (round-robin). C est le cas de VxWorks. Quelque soit la technique chosie, à la création d une tâche, une priorité doit lui être 10

11 associée (0 pour la plus forte, 255 pour la plus faible). Cette priorité peut être changée à loisir en cours d exécution via la primitive système taskpriorityset(). Préemption : dans la littérature, on retrouvera souvent l expression de preemptive priority scheduling. Dans ce cas, l ordonnanceur alloue le processeur à la tâche prête qui à la plus forte priorité. Par exemple, si une tâche de plus forte priorité que la tâche courante passe dans l état prête, le contexte de la tâche courante est sauvegardé et l ordonnanceur alloue le processeur à la tâche de plus forte priorité. Bien entendu, ceci ne vaut que par l utilisation de la primitive taskpriorityset(). En effet, si la priorité des tâches n est pas changée au cours de l application, une seule tâche, et toujours la même monopolisera le CPU. Une simulation graphique du preemptive priority scheduling est donnée dans la figure 6. Dans cet exemple, Priorité Fin de tâche T3 Préemption T2 T2 T1 T1 Temps Fig. 6 Simulation par ordonnancement préémptif la tâche T1 est préemptée par une tâche T2 de priorité supérieure qui à son tour est préemptée par T3. Lorsque T3 se termine normalement, la tâche T2 peut poursuivre alors son exécution jusqu à sa fin normale. Enfin, la tâche T1 peut s achever. Tourniquet : dans la littérature, on retrouvera souvent l expression de round-robin scheduling. Ici, l ordonnancement consiste à répartir de manière parfaitement égalitaire le temps processeur à chacune des tâches ayant bien entendu la même priorité. Il est nécessaire d attirer l attention sur le fait que si les tâches ont la même priorité et que le mécanisme de round-robin n est pas activé, seule l une des tâches bénéficiera du CPU, et ce jusqu à ce qu elle soit mise en attente ou préemptée par une tâche plus prioritaire... L activation de ce fonctionnement particulier de l ordonnanceur se fait via l appel à la primitive système kerneltimeslice(). Chaque tâche d un même groupe de priorité est exécutée alternativement pendant un intervalle de temps donné ( time-slice ) dont la durée est déterminée en nombre de tops horloges ( ticks la valeur d un ticks se déduit de la configuration du noyau). A la fin de ce temps d allocation, la tâche est remise en fin de file d attente d exécution. Bien entendu, ce principe ne vaut que si un compteur de temps est associé à chaque tâche, ce qui, je vous rassure, est le cas. 11

12 D ailleurs, une petite question au passage... Lorsqu une tâche est en cours d exécution, elle détient donc le seul processeur... Comment le noyau peut-il alors compter le temps pour donner la main à une autre tâche à la fin du time-slice affecté à la tâche en cours d exécution? Une simulation de ce principe de fonctionnement est donnée dans la figure 7. Dans Priorité Fin de tâche Préemption T4 T1 T2 T3 T1 T2 T2 T1 Temps Fig. 7 Simulation par ordonnancement de type tourniquet cet exemple, les tâches T1, T2 et T3 ont la même priorité. Elles se partagent donc le CPU de manière égalitaire jusqu à ce qu une tâche de plus haute priorité T4 s exécute complètement. A la fin normale d exécution de T4, l ordonnanceur réalloue le temps CPU restant affecté à la tâche T2. Dans certains cas, il pourra être utile de désactiver l ordonnanceur afin d interrompre l exécution d une tâche. On utilisera alors la primitive tasklock(). Pour repasser en mode de fonctionnement normal, et donc réactiver l ordonnanceur, on lancera la primitive taskunlock(). Ce mécanisme, certes un peu violant, sera parfois utilisé pour résoudre des problèmes d exclusion mutuelle. On privilégiera cependant le recours aux sémaphores Le How To de la Gestion des tâches sous vxworks L ensemble des primitives de bases assurant la gestion des tâches sont regroupées dans la bibliothèque tasklib. Afin d en disposer, il suffit d inclure le fichier tasklib.h. Remarque : les synoptiques des primitives données dans la suite de ce document sont regroupées dans la partie III. Ils peuvent également être consultés directement via l aide en ligne sous Tornado II (cf. manual topics ) Création et activation d une tâche La création et l activation d une tâche sont décomposées par vxworks en quatre phases : (1) allocation mémoire pour la pile et le TCB, 12

13 (2) initialisation de la pile via les arguments passés par la tâche, (3) initialisation du TCB (pointeur de programme et pointeur de pile), (4) accrochage de la tâche dans la file des tâches prêtes. Ces quatres phases sont réalisées au travers d une seule primitive taskspawn(). En retour, taskspawn fournit le numéro d identification de la tâche : taskid = taskspawn(nom(chaîne ascii), priorité(0 255), options(coprocesseur virgule flottante, pas d init de la pile,...), taille pile, adresse du code à exécuter, arg1,..., arg10); Notons que le temps de changement de contexte est inférieur à quelques µ-secondes. Un exemple de création de tâche est donné dans la figure 8. #include "vxworks" #include "tasklib.h"... int tid1; void mafonction(void) for(;;) printf("bonjour"); } } STATUS programme_demarrage(void)... tid1 = taskspawn("ttache 1 blabla", 100, 0, 2000, (FUNCPTR) mafonction, 0,0,0,0,0,0,0,0,0,0);... } void fin_programme(void)... /* suppression des tâches */ taskdelete(tid1);... } Fig. 8 Exemple de création d une tâche Remarque : le nom de la tâche (chaîne ascii) peut être quelconque, il ne sert que pour la phase de mise au point. Il est cependant fortement conseillé de le faire précéder du préfixe t afin d éviter les confusions avec d autres variables. La création d une tâche via la primitive taskspawn() autorise une grande souplesse de paramétrage via les options. Il suffit de spécifier un OU logique entre les différentes options suivantes : VX FP TASK : exécution avec le coprocesseur virgule flottante, 13

14 VX NO STACK FILL : pas d initialisation de la pile, VX PRIVATE ENV : exécution de la tâche avec environnement privé, VX UNBREAKABLE : désactivation des points d arrêts pour une tâche, VX DEALLOC STATE : désallocation de la pile et du TCB lorsque la tâche se termine (option par défaut). Si l on souhaite obtenir des informations sur la tâche, comme par exemple son existence, son nom, son identificateur, etc..., vxworks fournit les primitives suivantes : taskidverify() vérifie l existence d une tâche spécifiée par son identificateur, taskname() donne le nom de la tâche associé à un identificateur, tasknametold() recherche l identificateur d une tâche spécifiée par son nom, taskidself() fournit l identificateur de la tâche appelante, taskpriorityget() donne la priorité de la tâche, taskoptionsget() indique les options de la tâche, taskpriorityset() fixe une nouvelle priorité de la tâche, taskoptionsset() fixe les nouvelles options. Dans le cas où l on souhaite contrôler les phases d initialisation et d activation à la main (peu recommandé cependant...), les primitives taskinit() et taskactivate() sont disponibles Suppression d une tâche La suppression d une tâche peut être pratiquée dynamiquement par la tâche elle même (exit()) ou par une autre tâche (taskdelete()). Il est important de noter qu il ne faut pas supprimer une tâche à un moment inopportun, comme par exemple lorsqu elle détient une ressource. Dans ce cas, si la tâche est détruite, la ressource restera bloquée définitivement, et deviendra donc à jamais indisponible à toute autre tâche. Pour se protéger de toute suppression intempestive, la primitive tasksafe() pourra être utilisée. La protection durera jusqu à l appel de la primitive taskunsafe(). Remarque : les sémaphores d exclusion mutuelle intègrent une option de protection contre les suppressions intempestives de tâches Différer l exécution d une tâche Le délais est le moyen privilégier pour mettre en œuvre des applications à déclenchement périodiques comme les scrutations, ou encore la génération de pulse par exemple. Pour ce faire, nous utiliserons la primitive taskdelay() qui diffère la suite de l exécution d une tâche pendant une durée spécifiée en nombre de tops d horloge (TICKS). L état de la tâche passe alors de l état en exécution à différée. La fonction sysclkrateget() retourne la valeur de l horloge système en nombre de tops par seconde (par défaut 60). ce nombre peut être modifié par la primitive sysclkrateset(). Ces deux primitives sont contenues dans la bibliothèque syslib. On inclura alors le header syslib.h. Un exemple est donné dans la figure 9. Remarque : Une dérive temporelle peut être observée lors de l utilisation de taskdelay(). L appel à taskdelay() a également pour effet de placer la tâche appelante en fin de 14

15 #include "vxworks" #include "syslib.h"... int tid1; void mafonction(void) for(;;) /* boucle de scrutation toutes les 0,5 secondes */ taskdelay(sysclkrateget() / 2); } } Fig. 9 Exemple de création d une tâche file d attente des tâches prêtes de même priorité. On peut ainsi céder volontairement par programmation le processeur à une autre tâche de même priorité. Il suffit d appeler cette primitive en lui passant une valeur nulle, soit taskdelay(no WAIT) Obtenir des informations sur les tâches En direct (sous le shell, ou sous le browser fourni par Tornado), il est possible d obtenir un certain nombre d informations sur l état des tâches. Cependant, il faut noter que la pertinence des informations obtenues n est valable qu à l instant t d observation!!! taskidlistget() : renvoie un tableau de tous les identificateurs de tâches actives, taskinfoget() : copie partielle du TCB, taskregsget() : renvoie les registres d une tâche, taskregsset() : fixe les valeurs des registres d une tâche, taskissuspended() : permet de vérifier si une tâche est suspendue ou non, taskisready() : permet de vérifier si une tâche est prête à être exécutée ou non. 2.2 Code partagé et réentrance Pour des raisons simples de conception et d optimisation de code, il peut être parfois avantageux qu une seule et même fonction soit appelée par plusieurs tâches. C est ce que l on nomme couramment un code partagé. Cependant, pour que cette mise en œuvre puisse fonctionner correctement, il faut à tout pris résoudre les classiques problèmes de conflits ; ces derniers peuvent effectivement se produire lorsqu il y a modification de variables globales statiques, et donc risque évident d interférence entre les différents appels à partir de contextes de tâches différents. Sous vxworks, la plupart des primitives vérifient le principe de réentrance, en particulier nous citerons l ensemble des primitives qui gèrent les entrées/sorties. Notons cependant que toutes les primitives pour lesquelles il existe une primitive de même nom suffixée de r sont censées être réentrantes. Les techniques employées par vxworks pour mettre en œuvre le principe de réentrance sont les suivantes. On remarquera que cela a bien entendu un coût. les variables dynamiques sont passées en paramètre par la pile associée à la tâche, 15

16 les variables globales et statiques sont protégées quant à elles par des sémaphores d exclusion mutuelle, des variables spécifiques sont associées à la tâche ce qui permet de sauvegarder dans le contexte de la tâche les variables globales et statiques. Bien évidemment, cette solution entraîne un coût temporel non négligeable en commutation de contexte. 2.3 Les 6 outils de communication inter-tâches Quelque soit le système à concevoir, si ce dernier doit se décomposer en tâche devant s exécuter en parallèle, des besoins de communication apparaîtront, que ce soit pour partager des données, se synchroniser, via un réseau de communication ou non, etc... De plus, il sera souvent nécessaire de pouvoir spécifier qu une donnée est accessible en lecture/écriture, ou bien uniquement en lecture. Dans ce cadre, VxWorks fournit un ensemble de mécanismes efficaces pour mettre en œuvre la communication entre tâches (exemple de communication par boîtes aux lettres ou queue, cf. figure 10). Ces mécanismes se décomposent en 6 catégories Equipement Equipement Tâche ISR Tâche Fig. 10 Services de communication inter-tâches La mémoire partagée C est la manière la plus classique et la plus simple de mettre en œuvre une communication entre 2 tâches. On parlera par exemple de variables globales, de tampons (buffers), ou encore de pointeurs. La gestion des accès concurrents en lecture ou en écriture est assurée par d autres mécanismes comme la désactivation (lockkey = intlock() et intun- Lock(lockKey)) pour une ISR (Interrupt Service Routine), la préemption (tasklock() et taskunlock()) ou les sémaphores (souvent la meilleure et la plus simple des solutions) 16

17 pour une tâche classique. Remarque : il faut cependant signaler que les cas de désactivation des interruptions et des préemptions posent des problèmes majeurs dans le cas où le temps de réponse est une contrainte importante. En effet, les temps de latence (blocage / déblocage) empêchent l exécution des autres tâches, même celles de priorités plus élevées Les sémaphores Ce mécanisme permet aussi bien de satisfaire à des besoins d exclusion mutuelle qu à des besoins de synchronisation entre processus. Trois versions du sémaphore sont utilisables. Sémaphores binaires : ce sémaphore est parfaitement dédié pour résoudre les problèmes liés à la synchronisation et au partage de ressources. Il peut en fait être considéré comme un indicateur (événement) à deux états : disponible (full) ou indisponible (empty). Concevoir une tâche qui doit être en attente d un tel sémaphore revient simplement à appeler la primitive semtake(). Ceci a pour effet de bloquer la tâche jusqu à ce que le sémaphore soit disponible. La tâche qui donne l événement, ou le sémaphore, fait appel à la primitive semgive(), ce qui rend le sémaphore dispo- Tâche qui génère l événement de synchronisation SemGive() Sémaphore SemTake() Tâche en attente de l événement de synchronisation Fig. 11 Principe de fonctionnement du sémaphore binaire nible et débloque ainsi la tâche qui est en attente (cf. figure 11). D un point de vue comportement, lorsqu une tâche demande à prendre un sémaphore par semtake() le résultat dépend de l état du sémaphore à l instant de l appel. S il est disponible il passe dans l état pris et la tâche continue son exécution. S il est non disponible 17

18 (pris par une autre tâche), la tâche est mise en attente par le noyau dans la liste correspondante et ce jusqu à ce que le sémaphore soit libéré ou qu un temps d attente a été spécifié. Lorsqu une tâche libère un sémaphore via la primitive semgive() le résultat dépend là aussi de l état du sémaphore. S il est disponible, la libération n a strictement aucun effet. En revanche s il est pris et qu aucune tâche n est en attente dessus, il devient libre. Effectivement, ce type de sémaphores peut être rendu par une autre tâche que celle qui le détient. S il est pris et qu il existe au moins une tâche en attente, la première tâche de la liste d attente est débloquée et le sémaphore reste pris. En guise d exemple (cf. figure 12) d utilisation du sémaphore pour la synchronisavoid initialisation(void) #include "semlib.h" /* déclarations */ SEM_ID sem_binaire;. sem_binaire = sembcreate(sem_q_fifo, SEM_EMPTY);.. } void tache_maitre(void) #include "semlib.h". semgive(sem_binaire);.. } void tache_esclave(void) #include "semlib.h". semtake(sem_binaire, WAIT_FOREVER);.. } Fig. 12 Exemple d un sémaphore binaire tion, nous allons ici représenter une condition de synchronisation sur laquelle une tâche est en attente. Initialement mis dans un état indisponible, une tâche ou une routine d interruption signale l occurrence de l événement en libérant simplement le sémaphore (semgive()). Certains pourraient se poser la question judicieuse suivante : comment synchroniser la libération de plusieurs tâches en attente du même événement? Et bien soyez rassurés, ceci est tout à fait possible en utilisant la primitive semflush(). Bien entendu, étant donné les caractéristiques de ce sémaphore, rien n empêche son utilisation pour résoudre des problèmes d exclusion mutuelle. Dans ce cas, ce sémaphore est utilisé pour garder la ressource de manière exclusive. Il est initialement crée en l état libre. Pour accéder à une ressource, une tâche doit tout d abord prendre la sémaphore, elle réalise ensuite tranquillement son travail, puis relâche consciencieusement le sémaphore quand elle a achevé son travail. Un exemple est donné dans la figure 13. Mais attention à votre programmation car ce type de sémaphore peut être rendu par n importe qu elle tâche. Sémaphores d exclusion mutuelle : ce sémaphore (cf. figure 14) pourrait facilement 18

19 void initialisation(void) #include "semlib.h" /* déclarations */ SEM_ID sem_exclu_mut;. sem_exclu_mut = sembcreate(sem_q_fifo, SEM_FULL);.. } void tache1(void) #include "semlib.h". semtake(sem_exclu_mut, WAIT_FOREVER); /* début zone critique accessible par une seule tâche à la fois */.. /* fin zone critique accessible par une seule tâche à la fois */ semgive(sem_exclu_mut); } void tache2(void) #include "semlib.h". semtake(sem_exclu_mut, WAIT_FOREVER); /* début zone critique accessible par une seule tâche à la fois */.. /* fin zone critique accessible par une seule tâche à la fois */ semgive(sem_exclu_mut); } Fig. 13 Exemple d exclusion mutuelle par sémaphore binaire se confondre au sémaphore binaire. Mais ce serait une erreur. En effet, plusieurs points fondamentaux les distingues : il ne peut être utilisé que pour mettre en œuvre une exclusion mutuelle, il ne peut être libéré que par la tâche qui l a pris!!! il ne pas être libéré dans une routine d interruption, contrairement au sémaphore binaire, le principe de synchronisation multiple par semflush() est interdit. La force de ce sémaphore est qu il permet de s affranchir des problèmes d inversion de priorité par héritage de priorité. Il offre ainsi une protection efficace contre la destruction intempestive de la tâche le détenant et de plus, il autorise un accès récursif à une ressource. Sur le plan comportemental, à la différence du sémaphore binaire, le sémaphore d exclusion mutuelle peut être pris plus d une fois par semtake() sans provoquer le blocage de la tâche propriétaire. D autre part, seule la tâche propriétaire peut libérer le sémaphore d exclusion mutuelle par semgive(). Bien entendu, celui-ci doit être libéré autant de fois qu il a été pris pour être à nouveau disponible. La puissance d un sémaphore d exclusion mutuelle : ce sémaphore peut effectivement être qualifié de puissant au sens où il apporte des solutions aux problèmes suivants : Inversion de priorité : une tâche de plus haute priorité est en attente d un sémaphore détenu par une tâche de priorité plus faible. Ce scénario est un comble, certes, mais peut se produire (cf. figure 15). Dans cet exemple, la tâche T3 s exécute et prend le sémaphore disponible. Elle est ensuite préemptée par la tâche T1 19

20 SemTake() Sémaphore SemTake() SemGive() SemGive() Fig. 14 Principe du sémaphore d exclusion mutuelle Priorité? T1 T1 Préemption Prise sémaphore T3 T3 T2 T2 T3 Libération sémaphore Temps Fig. 15 Problème classique priorité/sémaphore de priorité plus élevée qui réclame, elle aussi, le sémaphore. Ce dernier étant indisponible, T1 est donc mise en attente, et l exécution revient à T3. Si de surcroît une tâche T2 de priorité intermédiaire s exécute, elle empêche T3 de rendre son sémaphore, et ce, pendant un temps indéfini! Le sémaphore d exclusion mutuelle permet de résoudre ce problème délicat via l option SEM INVERSION SAFE qui autorise l exécution d un algorithme d héritage de priorité. Il assure ainsi qu une tâche qui détient un sémaphore s exécutera à la priorité de la tâche de plus forte priorité en attente de ce sémaphore, et ce, jusqu à ce qu elle rende le sémaphore. Dans l exemple de la figure 16, la tâche T3 prend la priorité de la tâche T1 jusqu à ce qu elle relâche le sémaphore. Dés lors, la tâche T1 peut s exécuter. Héritage de priorité : comment se protéger d une suppression lorsqu on détient un sémaphore? Lorsqu une région est définie critique grâce à la protection d un sémaphore, il est nécessaire de protéger la tâche propriétaire de ce sémaphore d une éventuelle suppression (taskdelete()). Si tel n est pas le cas, les données pourraient rapidement devenir incohérentes, et surtout, le sémaphore rester indéfiniment inaccessible! Comme nous avons pu le voir précédemment, nous 20

21 Priorité? Libération sémaphore T1 T3 T1 Préemption Prise sémaphore héritage de priorité T2 T3 Temps Fig. 16 Principe de l héritage de priorité pouvons aisément régler ce problème via les primitives tasksafe() et taskun- Safe(). Mais on peut se douter qu une autre solution est offerte via les options du sémaphore d exclusion mutuelle. C est effectivement le cas avec l option SEM DELETE SAFE. Notons que cette méthode est beaucoup plus judicieuse puisqu elle ne fait pas appel au noyau. Récursivité : les sémaphores d exclusion mutuelle peuvent être pris de manière récursive par une tâche. Ceci est fort utile lorsqu on a affaire à des procédures qui s inter-appellent ou s appelle de manière récursive tout en ayant besoin de protéger une même ressource. Sur le plan comportemental, ce sémaphore est associé à un compteur qui s incrémente à chaque prise et se décrémente à chaque libération. Avant de pouvoir être utilisé par une autre tâche, le sémaphore devra bien entendu avoir été relâché autant de fois qu il a été pris. Sémaphores à compteur : les sémaphores à compteur permettent eux aussi de gérer synchronisation et exclusion mutuelle. Ils amènent cependant un aspect supplémentaire avec l enregistrement du nombre de fois qu ils ont été relâchés. En effet, à chaque libération le compteur est incrémenté, et décrémenté à chaque prise. Lorsque le compteur est égal à 0, toute tâche qui tente de le prendre se voit bloquée en attente de ce sémaphore. Ce sémaphore est de ce fait fort utile pour protéger l accès à plusieurs exemplaires du même type de ressource. Mise en œuvre des sémaphores : VxWorks fournit une interface complète de services liés à la manipulation des sémaphores. Les primitives sont réparties par classes (Binaire, Exclusion Mutuelle,...) de bibliothèques semblib (primitives liées aux sémaphores binaires), semmlib (primitives liées aux sémaphores d exclusion mutuelle) et semclib (primitives liées aux sémaphores à compteur). Pour bénéficier de ces primitives dans vos tâches, le header semlib.h devra être inclus dans l entête de votre programme. Création d un sémaphore binaire : la primitive sembcreate(option, état initial) alloue et initialise un sémaphore binaire. Option = SEM Q PRIORITY ou SEM Q FIFO précisent si la mise en liste d attente des tâches lors d une demande de sémaphore est organisée en fonction de la priorité de la tâche ou bien de type First In / First Out. 21

22 État initial = SEM FULL (disponible) ou SEM EMPTY (pris). Création d un sémaphore d exclusion mutuelle : la primitive semmcreate(options) alloue et initialise un sémaphore d exclusion mutuelle. SEM Q PRIORITY ou SEM Q FIFO précisent si la mise en liste d attente des tâches lors d une demande de sémaphore est organisée en fonction de la priorité de la tâche ou bien de type First In / First Out, SEM DELETE SAFE protège de l effacement, SEM INVERSION SAFE protège de l inversion de priorité et doit être utilisée avec l option SEM Q PRIORITY grâce à un ou logique. On écrira donc : SEM INVERSION SAFE SEM Q PRIORITY. Création d un sémaphore à compteur : la primitive semccreate(options, état initial du compteur) alloue et initialise un sémaphore à compteur. Les options sont SEM Q PRIORITY ou SEM Q FIFO. Prise d un sémaphore : ceci est mis en œuvre par la primitive semtake(id du sémaphore, temps d attente). Les temps d attente peuvent être WAIT FOREVER (attente infinie jusqu à obtention), NO WAIT (pas d attente) ou encore le nombre de tops d horloge désiré. En cas de sortie sur time-out, semtake() renvoie la valeur ERROR, sinon OK. Libération d un sémaphore : ceci est réalisé via la primitive semgive(id du sémaphore). Si une libération pour synchronisation multiple de toutes les tâches qui sont en attente du même sémaphore est requise, la primitive semflush(id du sémaphore) sera utilisée. Suppression d un sémaphore : semdelete(id du sémaphore) Les Boîtes aux Lettres ou Queues Comme nous l avons vu précédemment, les sémaphores sont très efficaces pour mettre en œuvre synchronisation et gestion d accès aux ressources (données, périphériques,...). Cependant, si nous souhaitons mettre en œuvre non seulement une synchronisation mais également un passage d information liée à cette synchronisation (i.e. flot de donnée et flot de contrôle en SART), il existe un moyen plus simple et plus efficace que le recours à un sémaphore et une mémoire partagée. C est le cas des Boîtes Aux Lettres (BAL) appelées généralement queues. Ce mécanisme offre ainsi non seulement une gestion implicite d un tampon pour le passage de messages, et les mécanismes de synchronisation et d exclusion mutuelle. Les boîtes aux lettres permettent ainsi une mise en file d attente d un nombre variable de messages de longueur variable. Elles peuvent être utilisées aussi bien par des tâches que par des routines d interruption. Il faut noter qu une boîte aux lettres n est pas uniquement dédiée à une seule tâche ; plusieurs tâches peuvent en effet accéder à la même boîte aux lettres que ce soit en écriture ou bien en lecture. D un point de vue comportemental, une communication bidirectionnelle entre deux tâche requiert deux boîtes aux lettres (cf. figure 17). La gestion des boîtes aux lettres est supportée par les primitives de la bibliothèque msgqlib. Pour en bénéficier il faut inclure le header msgqlib.h dans l entête de vos 22

23 Tâche 1 Tâche 2 Fig. 17 Communication bidirectionnelle entre deux tâches programmes. Création d une boîte aux lettres : il faut utiliser la primitive msgqcreate(nombre max de messages, longueur maximale du message, options) qui alloue et initialise une liste d attente. En retour, msgqcreate() renvoie l identificateur de la boîte. Deux options sont disponibles, MSG Q PRIORITY (précise si la mise en attente des tâches en attente d un message est gérée en fonction de la priorité de la tâche) ou MSG Q FIFO (précise si la mise en attente des tâches en attente d un message est du type First In / First Out). Envoi d un message : lorsqu une tâche doit émettre un message, elle utilisera la primitive msgqsend(id de la boîte, adresse du message, longueur du message, temps d attente, priorité). Si aucune tâche n est en attente sur cette boîte aux lettres, le message est ajouté en fin de liste. S il existe déjà une ou plusieurs tâches en attente, le message est immédiatement délivré à la première tâche en attente. Si la file d attente est pleine, le temps d attente permet de préciser combien de temps la tâche qui émet pourra rester bloquée en attente. Temps d attente = WAIT FOREVER ou NO WAIT ou nombre de tops d horloge (TICKS). Priorité = MSG PRI NORMAL (placé en fin de liste d attente) ou MSG- PRI URGENT (placé en début de liste d attente). Réception d un message : lorsqu une tâche reçoit un message, elle le fait grâce à la primitive msgqreceive(id de la boîte, adresse du buffer de réception, longueur du buffer, temps d attente). Si des messages sont déjà disponibles dans la liste, le premier est retiré et fourni à la tâche appelante. Si aucun message est disponible, la tâche appelante se bloque, et elle est ajoutée dans la liste des tâches en attente sur cette boîte aux lettres. Cette liste de tâches en attente peut être organisée en FIFO ou en fonction de la priorité des tâches, selon ce qui a été spécifié lors de la création de la BAL. Ici aussi, le temps d attente peut être WAIT FOREVER ou NO WAIT ou encore le nombre de top d horloge souhaité. Suppression d un message : on utilisera la primitive msgqdelete(msgid) Les Tubes ou Pipes En cours de rédaction. 23

24 2.3.5 Les sockets En cours de rédaction Les signaux En cours de rédaction. 2.4 Les interruptions matérielles La gestion des interruptions matérielles sous un système d exploitation multi-tâches temps réel est le point primordial. Pourquoi? Et bien pour simplement réagir aux stimuli ou événements extérieurs issus des équipements périphériques. Pour répondre le plus rapidement possible aux événements extérieurs, on les associe à des interruptions. Ces interruptions ont pour effet de déclencher une ISR (Interrupt Service Routine) qui lance à son tour l ISR utilisateur. Sous vxworks, les ISR s exécutent dans un contexte particulier en dehors de celui des tâches afin d éviter toute commutation de contexte (perte de temps). Afin d associer une ISR utilisateur (routine C), on utilisera la primitive intconnect(offset du vecteur d IT, adresse de la routine C, arguments). Lors de l occurrence d une interruption, une fonction construite à partir des paramètres fournis à la fonction intconnect() sauvegarde les registres nécessaires, initialise la pile pour le passage des arguments et appelle la fonction C connectée. Au retour de cette fonction, les registres et la pile sont restaurés (cf. figure 18). Rappelons qu une ISR est prioritaire sur toutes les tâches. De ce fait, aucune tâche ne peut s exécuter tant que l ISR n est pas terminée. Cette dernière ne doit évidement pas réaliser d allocation dynamique, pas d appels à des fonctions d entrées/sorties, etc... Enfin, remarquons que la communication entre une ISR utilisateur et une tâche n est pas interdite à condition d utiliser les libérations de sémaphores binaires, ou de passages non bloquants de messages par boîtes aux lettres ou pipes (tubes). 2.5 Les WatchDogs ou Temporisations Une temporisation (en anglais watchdog timer) est un mécanisme permettant de déclencher l exécution d une fonction à l expiration d un délai fixé. Cette fonction s exécute dans le cadre de la routine d exécution de l horloge système. Pour accéder aux watchdog timers, il faut inclure dans les entêtes des programmes le header wdlib.h. Création d une temporisation : wdcreate() alloue et initialise une structure en mémoire pour le temporisateur. En retour, elle fournit un identificateur de temporisation. Déclenchement d une temporisation : wdstart(id tempo, délai en tops d horloge, routine à appeler, paramètres) lance une temporisation qui est placée dans une file d attente horloge. Remarques : comme pour toute procédure d interruption, il faut veiller ici aussi à ce que la routine d interruption ne soit pas bloquante (prise de sémaphore, appel aux primitives d entrées/sorties telle que printf(), etc...). A tout moment, il est possible de modifier le délai ou bien la routine associée en ré-appelant la primitive wdstart() avec bien entendu le même identificateur (id). La temporisation lancée peut être interrompue (et non supprimée!) à n importe quel moment en appelant la 24

25 Fig. 18 Comportement d une interruption matérielle primitive wdcancel(id de la tempo à interrompre). Enfin, il est utile de préciser qu une temporisation ne s exécute qu une seule fois. Ainsi, si une application requiert un lancement de temporisation périodique, il suffira de ré-appeler wdstart() à la fin du délai. Suppression d une temporisation : on appellera alors la primitive wddelete(id de la temporisation à supprimer). Elle dés-alloue le temporisateur puis retire la temporisation de la liste d attente horloge. 3 Gestion des périphériques, mécanismes des descripteurs en cours de construction. 25

26 Deuxième partie L environnement de développement TORNADO II 4 Les outils de développement L environnement de développement Tornado intègre en un seul outil de travail tous les éléments nécessaires, de la programmation à la mise au point des applications vxworks. Cet environnement offre ainsi aux concepteurs, d organiser ses projets, de les écrire, de SYSTEME de DEVELOPPEMENT (HOST) Éditeur Projet Shell Browser Debugger Windview Simulateur vxworks Agent cible Serveur cible TORNADO II SYSTEME CIBLE (TARGET) Application VxWorks Agent cible Fig. 19 Interaction système développement / système cible les compiler, de les télécharger et enfin de les mettre au point sur la cible. 4.1 L Éditeur Tornado L éditeur fournit dans Tornado II fournit (cf. figure 20) : toutes les fonctionnalités standards de manipulation de textes, une coloration des éléments de syntaxes C et C++, un debugger en ligne permettant de tracer de l exécution du code, des liens dynamiques entre les erreurs de compilation et les avertissements du compilateur. 26

27 GESTIONNAIRE PROJET EDITEUR Fig. 20 Environnement de développement Tornado II 4.2 Un gestionnaire de projets Cet outil permet d organiser, de configurer et de construire des applications vxworks (cf. figure 20). Il s appuie sur une interface graphique conviviale de configuration. 4.3 Le compilateur Tornado inclut un compilateur GNU pour des programmes écrits en C et C++. Il s appuie sur les outils classiques : cpp, pré processeur C, gcc, compilateur C / C++, Fig. 21 Construction d un programme 27

28 make, l outil de construction des programmes, ld, le lieur, as, l assembleur, et pour finir, divers utilitaires binaires. Par exemple, comme le montre la figure 21, la construction de l application Banque de France.out se réalise simplement à l aide de la souris en cliquant sur le projet Banque de France avec le bouton droit. Un menu déroulant apparaît vous donnant la possibilité entre autre de construire votre programme : Build Banque de France.out. D autres possibilités vous sont offertes comme par exemple la commande Dependencies qui permet d établir la liste des fichiers nécessaires à la compilation de votre projet (i.e. fichiers inclus). 4.4 L interpréteur de commande (Shell) Le shell de Tornado (WindSh, cf. figure 22) est un programme résident sur l hôte (il s exécute donc sur l hôte) qui fournit un accès direct par communication réseau au noyau vxworks (sur la cible). Il peut interpréter la plupart des primitives du langage C (voire même C++). Il permet au programmeur d effectuer des tests, de lire ou écrire sur Raccourci shell Fig. 22 Interpréteur de commande la cible afin par exemple d exercer un contrôle total sur la cible. Puisqu il s exécute sur l hôte, il affecte très peu le fonctionnement de la cible. Via ce shell, introduire des points d arrêts dans les programmes, l exécuter pas à pas, désassembler le code, vérifier l état de la pile ou encore visualiser l état des tâches en cours est affaire courante. Comme nous le verrons par la suite, Tornado met également à disposition une interface graphique de mise au point des programmes qui s appuie bien 28

29 entendu sur ce shell. Cette dernière sera bien entendu privilégiée pour des raisons évidentes de confort d utilisation. Pour avoir accès à l ensemble des commandes offertes par le shell, taper help à partir de l invité de commande (prompt). Remarque : il est important de noter que le shell peut rediriger les entrées / sorties standards vers celles de la cible. 4.5 Le Debugger CrossWind CrossWind est une version étendue de GDB. L extension la plus visible concerne bien entendu l interface graphique (cf. figure 23) qui permet désormais d accéder simplement Traceur état des tâches Code source mixte Inspection des données Témoin debugger actif Fig. 23 Le debugger CrossWind et convivialement aux activités les plus communes de la mise au point : Création et mise au point de tâches sur le système cible, Attacher le debugger à des tâches déjà crées et activées via le shell ou directement par votre application, Utiliser des breakpoints à n importe quel niveau de l application, voire même au niveau du système, Visualiser le code source de l application, l assembleur voire même les deux (mixte), Inspecter des données, etc... 29

30 4.6 Le navigateur (Browser) Fig. 24 Le navigateur Le navigateur de Tornado permet de surveiller l état de la cible (cf. figure 24). Il fournit pour cela : Un résumé des tâches actives, Pour une tâche spécifiée, l état des registres utilisés, son niveau de priorité, ainsi que d autres attributs, Un graphe comparatif du pourcentage d utilisation du CPU pour chacune des tâches systèmes et application utilisateur, Pour chacune des tâche, la taille de pile consommée, La partition de la mémoire, La structure des tous les modules téléchargés sur la cible comme par exemple les applications de l utilisateur, Les éléments caractéristiques du systèmes d exploitations comme les sémaphores, les boites aux lettres, les watchdogs, les vecteurs d interruption, etc... Il faut également noter que la périodicité de mise à jour des données du navigateur est entièrement paramétrable. 4.7 WindView Software Logic Analyzer WindView est un outil d analyse graphique (cf. figure 25) dynamique des changements de contexte et des événements qui les provoquent (sémaphores, interruptions, etc.). Cet outil est très utile pour debugger une application multi-tâche étant donné son fort pouvoir d abstraction. La vie des tâches y est en effet visualisée simplement sous la forme de chronogrammes de l état des tâches système et utilisateur. La richesse des symboles utilisés (sémaphores, IT, timers, watchdogs, etc...) vous sera précieuse (n hésitez pas à activer la légende via le bouton droit de la souris). 30

31 Lanceur rapide de WindView Tableau de bord du traceur Traceur 4.8 Le simulateur VxWorks Fig. 25 WindView Le simulateur simule le système d exploitation vxworks au sein de l environnement de développement Tornado II. Il ne nécessite aucun matériel cible, hormis le PC de développement bien entendu. Il fournit ainsi un environnement indépendant pour les développeurs afin de leur permettre de valider certaines parties de leur application ; en fait celles qui ne manipulent pas d entrées / sorties matérielles. Remarque : après quelques essais du simulateur, nous avons pu remarquer quelques dysfonctionnements par rapport au comportement normal d une cible réelle. L usage de ce simulateur doit à notre avis se limiter à l apprentissage des notions de base de vxworks... 5 Architecture de la chaîne Tornado II Avant tout démarrage de Tornado II, il est conseillé de créer, via l explorateur de Windows par exemple, votre répertoire de travail vxworks qui accueillera l ensemble de vos projets vxworks. Ensuite, vous pouvez lancer l environnement Tornado II : Démarrer Programme Tornado2 Tornado. 5.1 Création d une disquette de boot Tornado permet pour chaque BSP (Board Support Package) acquis de construire un bootloader. Ce boot est composé d une configuration minimale de vxworks (équivalent en fait à une disquette système que vous avez l habitude de créer sous DOS ou Windows) et d un mécanisme de chargement du noyau complet. Bien entendu, puisque ce second 31

32 mécanisme doit venir télécharger le reste du noyau par le réseau, il est nécessaire de configurer et de construire un nouveau boot minimal adapté à votre environnement de développement (adresses du target, de l hôte, type de la carte de communication installée sur le target). Cette configuration passe par une modification des paramètres du fichier config.h de votre BSP. Ce fichier se trouve donc dans le répertoire : C:\tornado\target\config\bspname\ où bspname est égal dans notre cas à pc486. Cependant, et ce afin de préserver l intégrité de ce répertoire, il est vivement conseillé dans créer une copie et de travailler dans cette dernière : C:\tornado\target\config\pc486-b127\ (ce que nous avons déjà fait comme vous pourrez le remarquer). Une fois ce répertoire copié dans pc486-b127, vous pouvez modifier le fichier config.h à votre convenance. Votre intervention portera notamment sur les lignes define DE- FAULT BOOT LINE correspondant à votre architecture, ici un CPU i80486, sur le type de carte réseau que vous avez installée dans votre target, ici une 3COM EtherLink III (cf. figure 26). Pour plus d information, vous vous reporterez au Description of Boot Parameters and Help Manuals Contents VxWorks Reference Manual Libraries boot- Lib. Fig. 26 Modification des paramètres de boot dans config.h Une fois cette configuration réalisée, vous êtes désormais en mesure de pouvoir construire une disquette de boot système via Tornado II. Pour cela, sélectionnez Build Build Boot ROM dans le menu principal (cf. figure 27). Ici, comme le montre la figure 27, vous serez ensuite amenés à sélectionner d une part le BSP (ici pc486-b127) puis le format du boot (compressé, non compressé ou résident). Dans le cadre de nos bureaux d études, vous 32

33 Fig. 27 Construction d une disquette de boot vxworks sélectionnerez un boot non compressé. Après appui sur OK, Tornado construit le boot vx- Works. Si tout se passe bien, un message done est affiché dans la fenêtre de construction. Ceci caractérise le fait que le fichier contenant le bootloader a été crée dans le répertoire du BSP. Dés lors, vous devez ouvrir une fenêtre DOS (Démarrer Programmes Accessoires Invite de commandes), vous déplacer dans le répertoire C:\tornado\target\config\pc486-b127\ et lancer la commande mkboot a: bootrom uncmp (ne pas oublier d insérer une disquette vierge et formatée dans le lecteur!). Cette commande fournie par Tornado permet de copier le fichier bootrom uncmp à l adresse du secteur de boot de la disquette. C est à cette adresse que le calculateur cible est censé poser sa tête de lecture au démarrage. A la fin de la création de la disquette de boot, vous vérifierez que les fichiers sont contigus. Si tel n est pas le cas, recommencez l opération mkboot. 5.2 Création d un noyau vxworks Au démarrage, Tornado vous propose de créer, ou de retrouver un projet (cf. figure 28). Plaçons nous ici dans l hypothèse d un premier démarrage de Tornado dans le but de créer une application téléchargeable sur une cible de type PC

34 Fig. 28 Fenêtre d accueil au démarrage de Tornado Il s agira tout d abord de créer une image bootable du noyau vxworks (Create a bootable VxWorks image (custom configured)) adaptée à l architecture cible PC486. Après validation de ce choix, la fenêtre représentée dans la figure 29 apparaît. Il s agit ici de donner un nom au noyau que vous allez créer (par exemple kernel, origi- Fig. 29 Création d une image bootable nal non?), de définir le nom du répertoire qui va accueillir l ensemble des données relatives au noyau, puis de spécifier le nom de votre espace de travail (très utile pour personnaliser votre fenêtrage sous Tornado). Une fois l ensemble des données correctement spécifiées, une validation (NEXT) vous fera basculer dans la fenêtre centrale donnée figure 29. Il s agit ici de sélectionner l architecture matérielle cible de votre cas d étude. Vous sélectionnerez donc A BSP (Board Support Package) puis dans l ascenseur à droite le nom du BSP souhaité (ici par exemple pc486-b127). Notons que ces BSP sont achetés en sus de l offre Tornado II. Après installation, ils figurent généralement dans le répertoire C:\Tornado\target\config\. Pour des raisons évidentes de préservation des données 34

35 de ces répertoires, il est fortement conseillé de dupliquer le répertoire (BSP) concerné (ici PC486 devenu PC486-b127). Au sein de ce répertoire, plusieurs fichiers de configura- Fig. 30 Espace de travail tion de l architecture cible sont proposés. Il faudra veiller à redéfinir l architecture cible exacte en spécifiant par exemple la bonne carte de communication Ethernet TCP/IP dans config.h, les adresses hôte et cible,... Une fois la sélection du BSP faite, une validation par (NEXT) vous conduira à la fenêtre de droite de la figure 29. Cette fenêtre est tout simplement un récapitulatif des données concernant la création de l image bootable du noyau vxworks que vous allez créer. Si l ensemble des informations vous parait correct, vous pouvez confirmer la création du projet de création du noyau par (FINISH). Une nouvelle fenêtre apparaît alors à l écran, il s agit de votre espace de travail (cf figure 30). Cette fenêtre vous propose trois vues (cf. onglets en bas de fenêtre) de votre projet : Files (fichiers du projet), vxworks (paramètres du noyau) et Build (configuration et sélection Fig. 31 Paramétrage du noyau des BSP pour la construction des programmes). Dans le cadre de la création d une image bootable de vxworks, nous devons nous intéresser plus particulièrement au paramètrage 35

36 du noyau tel que le montre la figure 31. De nombreux paramètres sont réglables comme par exemple la mémoire, les périphériques (floppy, hard disk,...), le réseau, les bibliothèques standards C, ainsi que les outils de développement. Dans le cadre de l exemple de la figure 31, nous intégrons au noyau l outil de mise au point windview. Après validation par (OK), un retour sur l onglet Files est requis afin de réaliser enfin la compilation du noyau. Pour cela, il suffit de positionner le curseur de la sourie sur le dossier kernel, de cliquer sur le bouton droit afin de faire apparaître le menu déroulant montré dans la figure 32. Dans ce menu, le choix de l option ReBuild All(vxWorks) permet de lancer la Fig. 32 Compilation du noyau compilation du noyau. Le résultat de cette compilation apparaît alors dans une nouvelle fenêtre. Si tout s est bien passé, vous pouvez allez désormais vérifier que dans le répertoire..\kernel\default\ vous disposez du noyau téléchargeable nommé vxworks. Vous êtes maintenant en mesure de pouvoir passer à l étape suivante, la création de votre première application vxworks. 5.3 Création d une application vxworks La création d une application utilisateur vxworks reprend strictement les mêmes principes que la création d un noyau tel que nous avons pu le voir dans la paragraphe précédent. Seul l option ToolChain diffère de l option BSP pour la création d un noyau. Cette option permet de sélectionner la chaîne de développement en rapport avec le BSP souhaité (ici, I8086gnu par exemple) L ensemble de la démarche est représenté dans la figure 33. Une fois la dernière étape franchie, un nouveau dossier portant le nom de votre application doit apparaître dans votre projet (cf. onglet Files). L étape suivante consiste à créer dans ce dossier un fichier C ou C++. Pour ce faire, et à partir de la barre de menu principale, il suffit de cliquer sur File New. La fenêtre donnée dans la figure 34 apparaît alors. Bien entendu, plusieurs fichiers peuvent constituer les sources de votre application. La génération de l exécutable de votre application s obtient par click 36

37 Fig. 33 Création d une application utilisateur droit sur le dossier du workspace contenant votre application puis sélection de ReBuild All(nom appli.out). Si aucune erreur est détectée à ce niveau, vous détenez désormais un exécutable téléchargeable sur la cible. Remarque : une fois votre application crée, il est conseillé de vérifier les propriétés du compilateur à partir de votre espace de travail au niveau de l onglet Build. Vous ouvrirez pour cela l arborescence correspondant à votre projet, et cliquerez sur ce dernier à l aide du bouton droit de la souris. Un menu déroulant apparaîtra à partir duquel vous sélectionnerez l item Properties. Dans l onglet C/C++ compiler de la nouvelle fenêtre affichée, rajoutez si besoin les options -IC:/Tornado/target/config/all et -IC:/Tornado/target/config/pc486-b Configuration et lancement du serveur FTP Avant de pouvoir lancer le serveur cible, il est nécessaire de booter la machine cible de façon à installer vxworks sur cette machine, à partir du noyau crée sur le poste de développement (cf. paragraphes précédents). Ceci présuppose d établir une liaison de communication entre l hôte et la cible en lançant un serveur FTP sur la machine hôte (FTP est le protocole le plus simple d utilisation pour transférer des fichiers par le réseau). Dans ce but, Tornado II est livré avec un FTP (cf. figure 35). Pour y accéder : Démarrer Programme Tornado2 FTPServer. 37

38 Fig. 34 Création d un nouveau fichier C Fig. 35 Configuration du serveur FTP de Tornado 5.5 Configuration et lancement du serveur cible Avant de lancer le serveur cible, il faut le configurer. Pour se faire, sélectionner dans le menu principal Tools Target Server Configure (cf. figure 36). Tel que le montre cette figure, une nouvelle fenêtre apparaît alors. Vous devez tout d abord spécifier le nom de la configuration afin de la sauvegarder et ainsi la rappeler plus tard sans passer à nouveau par une configuration. Dans le cadre du bureau d étude, vous nommerez votre configuration comme suit : pc486-b127-xx (avec XX le numéro du poste). Cochez ensuite Add description to menu Target Server Properties : Back End. Sélectionnez alors dans Available Back Ends l item wdbrpc. A présent, sélectionnez dans l item Target Server Properties l option Target- ServerFileSystem. Cochez ensuite les cases Enable File System et Read/Write puis spécifiez le répertoire de votre projet (dans le cadre de notre bureau d étude Z:\ProjvxWorks ). Il ne vous reste plus désormais qu à définir le Target Name/IP Address : xxx (dans le cadre des bureaux d étude, l adresse IP est écrite sur la disquette de boot vxworks fournie). Il ne vous reste plus qu à cliquer sur Launch pour lancer le serveur cible. Vérifiez alors qu une cible rouge apparaît dans la barre d outil système qui se situe 38

39 Cible rouge Fig. 36 Configuration du serveur cible en bas et à gauche de votre écran (cf. figure 36). 5.6 Lancement du shell Une fois le serveur cible lancé, tous les autres outils Tornado peuvent être utilisés de manière notamment à télécharger et à analyser réellement le comportement de votre application. Cependant, il est tout d abord nécessaire de sélectionner le serveur cible qui a précédemment été lancé (cf. (1) figure 37). Il suffit ensuite de cliquer sur le bouton ( I) pour lancer et exécuter le shell (cf. (2) figure 37). 5.7 Téléchargement d une application Le téléchargement d une application ne peut bien entendu se faire qu à la condition d avoir compiler préalablement votre application (Build All). Après quoi, le téléchargement est possible. Pour cela, il suffit dans le Workspace de cliquer avec le bouton droit de la souris sur (nom de votre application) Files et sélectionner Download (nom de votre application).out. L opération de chargement commence alors (cf. figure 38). Une fois votre application chargée sur la cible, vous pouvez l exécuter en tapant sous le prompt du shell le nom de l exécutable. 5.8 Utilisation du debugger Pour lancer une phase de debuggage, il va de soit qu un Shell doit tout d abord être lancé sur la cible, et que votre application y soit également exécutée. Après quoi, la 39

40 1 2 Fig. 37 Sélection du serveur cible et exécution du shell démarche consiste à lancer le debbuger matérialisé par le bouton d accès rapide représentant une fourmis (cf. (1) de la figure 39). De sorte que cette fourmis puisse observer les mouvements de votre code multi-tâche, il est nécessaire de lui indiquer la tâche quelle doit surveiller. Pour cela, utilisez le menu déroulant Debug de la barre de menu principale. Cliquez alors sur l item Attach... tel que montré dans le point (2) de la figure 39. Une nouvelle fenêtre s ouvre indiquant l ensemble des tâches connues du noyau. Vous n avez plus qu à cliquer sur celle abritant le code que vous voulez debbuger (cf. point (3) de la figure 39). Une fois cette action réalisée, une nouvelle fenêtre apparaît vous donnant accès à la vue du code désassemblé de votre tâche. A présent, plusieurs possibilités sont offertes pour évaluer votre code. Par exemple, vous pouvez demander une visualisation mixte de votre code source. Pour cela, cliquez dans votre fenêtre code source, puis déroulez le menu View de la barre de menue principale. Cliquez alors sur l item Mixed source and disassembly. Comme le montre la figure 40, votre fenêtre code source apparaît désormais avec votre code source C ou C++, et sa traduction littérale en assembleur. A partir de cette fenêtre, et ce quelque soit la vue demandée, vous pouvez à loisir placer des BreakPoints en cliquant sur une des lignes de votre code avec le bouton droit de votre souris. Une fenêtre apparaît alors à l écran vous donnant accès à plusieurs item, dont le point d arrêt (Toggle BreakPoint). De la même façon, vous pouvez également surveiller l état des variables de votre code en positionnant votre souris dessus et en activant le menu déroulant. Dans ce cas, sélectionnez l item Add to Watch (cf. figure 41 pour visualiser la valeur de votre variable. De nombreuses autres possibilités vous sont offertes comme par exemple la visualisation des registres internes du processeur. Pour cela, utilisez les boutons d accès rapides tels que montrés dans la figure

41 Fig. 38 Téléchargement d une application sur la cible Fig. 39 Activation du debugger et principe d attachement 41

42 Curseur actif dans la fenêtre source Fig. 40 Visualisation mixte C/assembleur Variables Watch Registres Fig. 41 Suivi de l état des variables, accès aux registres, etc... 42

43 Troisième partie Quelques primitives de base du noyau vxworks 6 Primitives liées à la gestion des tâches 6.1 taskspawn( ) This routine creates and activates a new task with a specified priority and options and returns a system-assigned ID.The only resource allocated to a spawned task is a stack of a specified size stacksize, which is allocated from the system memory partition. Stack size should be an even integer. A task control block (TCB) is carved from the stack, as well as any memory required by the task name. SYNOPSIS : int taskspawn ( char name, / name of new task (stored at pstackbase) / int priority, / priority of new task / int options, / task option word / int stacksize, / size (bytes) of stack needed plus name / FUNCPTR entrypt, / entry point of new task / int arg1, / 1st of 10 req d task args to pass to func / int arg2, int arg3, int arg4, int arg5, int arg6, int arg7, int arg8, int arg9, int arg10 ) RETURNS : The task ID, or ERROR if memory is insufficient or the task cannot be created. ERRNO : S intlib NOT ISR CALLABLE, S objlib OBJ ID ERROR, S smobjlib NOT INITIALIZED, S memlib NOT ENOUGH MEMORY, S memlib BLOCK ERROR. LIBRAIRIE : tasklib (tasklib.h) 43

44 6.2 taskdelete( ) This routine causes a specified task to cease to exist and deallocates the stack and WIND TCB memory resources. SYNOPSIS : STATUS taskdelete ( int tid / task ID of task to delete / ) RETURNS : OK, or ERROR if the task cannot be deleted. ERRNO : S intlib NOT ISR CALLABLE, S objlib OBJ DELETED, S objlib OBJ UNAVAILABLE, S objlib OBJ ID ERROR. LIBRAIRIE : tasklib (tasklib.h) 7 Primitives liées à l ordonnancement 7.1 kerneltimeslice( ) This routine enables round-robin selection among tasks of same priority and sets the system time-slice to ticks. Round-robin scheduling is disabled by default. A time-slice of zero ticks disables round-robin scheduling. SYNOPSIS : STATUS kerneltimeslice ( int ticks /* time-slice in ticks or 0 to disable round-robin */ ) RETURNS : OK, always. LIBRAIRIE : kernellib (kernellib.h) 7.2 taskdelay( ) This routine causes the calling task to relinquish the CPU for the duration specified (in ticks). This is commonly referred to as manual rescheduling, but it is also useful when waiting for some external condition that does not have an interrupt associated with it. SYNOPSIS : STATUS taskdelay ( int ticks / number of ticks to delay task / ) 44

45 RETURNS : OK, or ERROR if called from interrupt level or if the calling task receives a signal that is not blocked or ignored. ERRNO : S intlib NOT ISR CALLABLE, EINTR, LIBRAIRIE : tasklib (tasklib.h) 7.3 tasklock( ) This routine disables task context switching. The task that calls this routine will be the only task that is allowed to execute, unless the task explicitly gives up the CPU by making itself no longer ready. Typically this call is paired with taskunlock( ); together they surround a critical section of code. These preemption locks are implemented with a counting variable that allows nested preemption locks. Preemption will not be unlocked until taskunlock( ) has been called as many times as tasklock( ). This routine does not lock out interrupts; use intlock( ) to lock out interrupts. A tasklock( ) is preferable to intlock( ) as a means of mutual exclusion, because interrupt lock-outs add interrupt latency to the system. A semtake( ) is preferable to tasklock( ) as a means of mutual exclusion, because preemption lock-outs add preemptive latency to the system. The tasklock( ) routine is not callable from interrupt service routines. SYNOPSIS : STATUS tasklock (void) RETURNS : OK or ERROR. ERRNO : S objlib OBJ ID ERROR, S intlib NOT ISR CALLABLE. LIBRAIRIE : tasklib (tasklib.h) 7.4 taskunlock( ) This routine decrements the preemption lock count. Typically this call is paired with tasklock( ) and concludes a critical section of code. Preemption will not be unlocked until taskunlock( ) has been called as many times as tasklock( ). When the lock count is decremented to zero, any tasks that were eligible to preempt the current task will execute. The taskunlock( ) routine is not callable from interrupt service routines. SYNOPSIS : STATUS taskunlock (void) RETURNS : OK or ERROR. ERRNO : S intlib NOT ISR CALLABLE. LIBRAIRIE : tasklib (tasklib.h) 45

46 7.5 tasksafe( ) This routine protects the calling task from deletion. Tasks that attempt to delete a protected task will block until the task is made unsafe, using taskunsafe( ). When a task becomes unsafe, the deleter will be unblocked and allowed to delete the task. The tasksafe( ) primitive utilizes a count to keep track of nested calls for task protection. When nesting occurs, the task becomes unsafe only after the outermost taskunsafe( ) is executed. SYNOPSIS : STATUS tasksafe (void) RETURNS : OK. LIBRAIRIE : tasklib (tasklib.h) 7.6 taskunsafe( ) This routine removes the calling task s protection from deletion. Tasks that attempt to delete a protected task will block until the task is unsafe. When a task becomes unsafe, the deleter will be unblocked and allowed to delete the task. The taskunsafe( ) primitive utilizes a count to keep track of nested calls for task protection. When nesting occurs, the task becomes unsafe only after the outermost taskunsafe( ) is executed. SYNOPSIS : STATUS taskunsafe (void) RETURNS : OK. LIBRAIRIE : tasklib (tasklib.h) 8 Primitives liées à la communication entre tâches 8.1 sembcreate( ) This routine allocates and initializes a binary semaphore. The semaphore is initialized to the initialstate of either SEM FULL (1) or SEM EMPTY (0). The options parameter specifies the queuing style for blocked tasks. Tasks can be queued on a priority basis or a first-in-first-out basis. These options are SEM Q PRIORITY (0x1) and SEM Q FIFO (0x0), respectively. SYNOPSIS : SEM ID sembcreate ( int options, / semaphore options / SEM B STATE initialstate / initial semaphore state / ) 46

47 RETURNS : The semaphore ID, or NULL if memory cannot be allocated. LIBRAIRIE : semblib (semlib.h) 8.2 semmcreate( ) This routine allocates and initializes a mutual-exclusion semaphore. The semaphore state is initialized to full. Semaphore options include the following: SEM Q PRIORITY (0x1) Queue pended tasks on the basis of their priority. SEM Q FIFO (0x0) Queue pended tasks on a first-in-first-out basis. SEM DELETE SAFE (0x4) Protect a task that owns the semaphore from unexpected deletion. This option enables an implicit tasksafe( ) for each semtake( ), and an implicit taskunsafe( ) for each semgive( ). SEM INVERSION SAFE (0x8) Protect the system from priority inversion. With this option, the task owning the semaphore will execute at the highest priority of the tasks pended on the semaphore, if it is higher than its current priority. This option must be accompanied by the SEM Q PRIORITY queuing mode. SYNOPSIS : SEM ID semmcreate ( int options / mutex semaphore options / ) RETURNS : The semaphore ID, or NULL if memory cannot be allocated. LIBRAIRIE : semmlib (semlib.h) 8.3 semgive( ) This routine performs the give operation on a specified semaphore. Depending on the type of semaphore, the state of the semaphore and of the pending tasks may be affected. SYNOPSIS : STATUS semgive ( SEM ID semid / semaphore ID to give / ) RETURNS : OK, or ERROR if the semaphore ID is invalid. ERRNO : S intlib NOT ISR CALLABLE, S objlib OBJ ID ERROR, S semlib INVALID OPERATION. LIBRAIRIE : semmlib (semlib.h) 47

48 8.4 semtake( ) This routine performs the take operation on a specified semaphore. Depending on the type of semaphore, the state of the semaphore and the calling task may be affected. A timeout in ticks may be specified. If a task times out, semtake( ) will return ERROR. Timeouts of WAIT FOREVER (-1) and NO WAIT (0) indicate to wait indefinitely or not to wait at all. When semtake( ) returns due to timeout, it sets the errno to S objlib OBJ TIMEOUT (defined in objlib.h). The semtake( ) routine is not callable from interrupt service routines. SYNOPSIS : STATUS semtake ( SEM ID semid, / semaphore ID to take / int timeout / timeout in ticks / ) RETURNS : OK, or ERROR if the semaphore ID is invalid or the task timed out. ERRNO : S intlib NOT ISR CALLABLE, S objlib OBJ ID ERROR, S objlib OBJ UNAVAILABLE. LIBRAIRIE : semmlib (semlib.h) 8.5 msgqcreate( ) The routine returns a message queue ID used to identify the created message queue in all subsequent calls to routines in this library. The queue can be created with the following options: MSG Q FIFO (0x00) queue pended tasks in FIFO order, MSG Q PRIORITY (0x01) queue pended tasks in priority order. SYNOPSIS : MSG Q ID msgqcreate ( int maxmsgs, / max messages that can be queued / int maxmsglength, / max bytes in a message / int options / message queue options / ) RETURNS : MSG Q ID, or NULL if error. ERRNO : S memlib NOT ENOUGH MEMORY, S intlib NOT ISR CALLABLE. LIBRAIRIE : msgqlib, msgqsmlib (msgqlib.h) 8.6 msgqsend( ) This routine sends the message in buffer of length nbytes to the message queue msg- QId. If any tasks are already waiting to receive messages on the queue, the message will immediately be delivered to the first waiting task. If no task is waiting to receive messages, 48

49 the message is saved in the message queue. The timeout parameter specifies the number of ticks to wait for free space if the message queue is full. The timeout parameter can also have the following special values: NO WAIT (0) return immediately, even if the message has not been sent. WAIT FOREVER (-1) never time out. The priority parameter specifies the priority of the message being sent. The possible values are: MSG PRI NORMAL (0) normal priority; add the message to the tail of the list of queued messages. MSG PRI URGENT (1) urgent priority; add the message to the head of the list of queued messages. USE BY INTERRUPT SERVICE ROUTINES This routine can be called by interrupt service routines as well as by tasks. This is one of the primary means of communication between an interrupt service routine and a task. When called from an interrupt service routine, timeout must be NO WAIT. SYNOPSIS : STATUS msgqsend ( MSG Q ID msgqid, / message queue on which to send / char * buffer, / message to send / UINT nbytes, / length of message / int timeout, / ticks to wait / int priority / MSG PRI NORMAL or MSG PRI URGENT / ) RETURNS : OK or ERROR. ERRNO : S distlib NOT INITIALIZED, S objlib OBJ ID ERROR, S objlib OBJ DE- LETED, S objlib OBJ UNAVAILABLE, S objlib OBJ TIMEOUT, S msgqlib INVA- LID MSG LENGTH, S msgqlib NON ZERO TIMEOUT AT INT LEVEL. LIBRAIRIE : msgqlib, msgqsmlib (msgqlib.h) 8.7 msgqreceive( ) This routine receives a message from the message queue msgqid. The received message is copied into the specified buffer, which is maxnbytes in length. If the message is longer than maxnbytes, the remainder of the message is discarded (no error indication is returned). The timeout parameter specifies the number of ticks to wait for a message to be sent to the queue, if no message is available when msgqreceive( ) is called. The timeout parameter can also have the following special values: NO WAIT (0) return immediately, even if the message has not been sent. WAIT FOREVER (-1) never time out. 49

50 WARNING : This routine must not be called by interrupt service routines. SYNOPSIS : int msgqreceive ( MSG Q ID msgqid, / message queue from which to receive / char * buffer, / buffer to receive message / UINT maxnbytes, / length of buffer / int timeout / ticks to wait / ) RETURNS : The number of bytes copied to buffer, or ERROR. ERRNO : S distlib NOT INITIALIZED, S smobjlib NOT INITIALIZED, S objlib- OBJ ID ERROR, S objlib OBJ DELETED, S objlib OBJ UNAVAILABLE, S objlib- OBJ TIMEOUT, S msgqlib INVALID MSG LENGTH. LIBRAIRIE : msgqlib, msgqsmlib (msgqlib.h) 8.8 msgqdelete( ) This routine deletes a message queue. Any task blocked on either a msgqsend( ) or msgqreceive( ) will be unblocked and receive an error from the call with errno set to S objlib OBJECT DELETED. The msgqid parameter will no longer be a valid message queue ID. SYNOPSIS : STATUS msgqdelete ( MSG Q ID msgqid / message queue to delete / ) RETURNS : OK or ERROR. ERRNO : S objlib OBJ ID ERROR, S intlib NOT ISR CALLABLE. LIBRAIRIE : msgqlib, msgqsmlib (msgqlib.h) 9 Primitives liées à la gestion des interruptions 9.1 intconnect( ) This routine connects a specified C routine to a specified interrupt vector. The address of routine is generally stored at vector so that routine is called with parameter when the interrupt occurs. The routine is invoked in supervisor mode at interrupt level. A proper C environment is established, the necessary registers saved, and the stack set up. 50

51 The routine can be any normal C code, except that it must not invoke certain operating system functions that may block or perform I/O operations. This routine generally simply calls inthandlercreate( ) and intvecset( ). The address of the handler returned by inthandlercreate( ) is what actually goes in the interrupt vector. This routine takes an interrupt vector as a parameter, which is the byte offset into the vector table. Macros are provided to convert between interrupt vectors and interrupt numbers, see intarchlib. SYNOPSIS : STATUS intconnect ( VOIDFUNCPTR * vector, / interrupt vector to attach to / VOIDFUNCPTR routine, / routine to be called / int parameter / parameter to be passed to routine / ) RETURNS : OK, or ERROR if the interrupt handler cannot be built. LIBRAIRIE : intarchlib (intlib.h) NOTES : The Intel x86 architecture provides two mechanisms to interrupting program execution: interrupts (asynchronous, external), exceptions (synchronous, generated when the processor detects a predefined condition, such as divide error or overflow). The handler of interrupts and exceptions are accessed through an entry in the interrupt descriptor table (IDT). The first 32 entries are predefined or reserved by Intel, these include the divide error, debug, NMI, breakpoint, and other exceptions (see in ivi86.h). The remaining 224 entries are user defined. VxWorks, by default maps the 16 ISA interrupts (0-15) as interrupt numbers (0x20-0x2f). To get from an ISA bus interrupt to a vxworks interrupt number, add 0x20 to the interrupt level. These interrupts are mapped through the Programmable Interrupt Controllers. The target.txt file explains this: All ISA interrupts are external to the CPU and are routed through the ISA interrupt prioritization hardware. This hardware is comprised of two 82C59 PICs. There are 16 ISA interrupts and interrupt priority levels numbered 0 through 15. The interrupt numbers and levels do not necessarily map one to one numerically. Each interrupt request (IRQ) is assigned a priority level by the hardware. The levels adhere to the standard ISA assignments: 51

52 IRQN umber IRQLevel The supported ISA interrupt levels are defined in pc.h as follows: define PIT0 INT LVL 0x00 / timer interrupt / define KBD INT LVL 0x01 / keyboard / define COM2 INT LVL 0x03 / serial port 2 / define COM1 INT LVL 0x04 / serial port 1 / define ELT0 INT LVL 0x05 / PCMCIA / define FEI1 INT LVL 0x05 / PCI / define FD INT LVL 0x06 / floppy / define LPT INT LVL 0x07 / Parallel port / define RTC INT LVL 0x08 / real time clock / define ATA1 INT LVL 0x09 / 9 for PCIC. 5 for TCIC / define ELT1 INT LVL 0x09 / PCMCIA / define FEI3 INT LVL 0x09 / PCI / define PCIC INT LVL 0x0a / PCMCIA / define TCIC INT LVL 0x0a / PCMCIA / define FEI0 INT LVL 0x0b / PCI / define FEI2 INT LVL 0x0c / PCI / define IDE INT LVL 0x0e / hard disk / define ATA0 INT LVL 0x0e / hard disk / The following procedure can be used to find out how a given entry in the IDT is initialized: 1. calculate vector = 8 * (INT NUM IRQ0 + ISA level) for example, level 0 (timer interrupt): 8 * (0x20 + 0) = 0x intvecget (0x100) On my system this returns: 0x3f4fd4 3. To find out what this will do: l 0x3f4fd4 CALL intent PUSH EAX 52

53 ... In this example, this is an initialized vector, the above code is the start of the intconnect stub. The same procedure can be used to find the status of other, non-isa interrupt numbers: intvecget (0x180) /* for level 16, software interrupt */ On my system this returns: 0x166b44 l 0x166b44 CALL excintstub... In this example, this is an uninitialized vector, the excintstub() function being the uninitialized interrupt handler. 53

54 Quatrième partie Apprentissage par la pratique 10 Création d un bootloader Vous disposez d une architecture cible classique de type PC-486 équipée d une carte réseau de type 3COM EtherlinkIII. Le driver dédié à cette carte est mis à disposition par la chaîne de développement Tornado II. Dans le cadre de ce premier TP, il vous est tout d abord demandé d imaginer une solution afin d installer votre futur noyau vxworks sur la cible. Une fois la solution discutée avec votre enseignant, vous serez chargés de la mettre en œuvre. Pour ce faire, ouvrez le fichier config.h que vous aurez préalablement rapatrié sur votre compte. Examinez-le et décrivez en quelques lignes son utilité. Après quoi, vous serez chargés de localiser précisément les lignes de ce fichiers que vous aurez à modifier. Proposez alors ces modifications ; pour cela vous vous appuierez sur la description de l architecture réseau de la salle fournie dans la documentation technique liée à ce BE. Faites alors valider ces modifications par l enseignant. Ce dernier vous donnera alors l autorisation de copier ce fichier dans le répertoire C:\tornado\target\config\pc486-b127\. Reportez vous alors à la page 31. Expliquez le principe de fonctionnement de la commande mkboot. Une fois la procédure de création du bootloader réalisée sur la disquette, testez la sur la cible. Que constatez-vous? Expliquez. 11 Configuration, création et chargement d un noyau adapté Votre disquette de boot étant désormais prête, reportez vous à la page 33 de ce document ainsi qu à la page 3 de la documentation technique mise à votre disposition afin de créer votre noyau complet. Une fois l opération terminée (une fenêtre Tornado - Workspace:bdf apparaît à l écran) ouvrez l Explorateur de Windows, et déplacez vous dans le répertoire Z:\Prj vxworks\kernel\default\, repérez alors le fichier vxworks. qui contient votre noyau. Relevez alors sa taille. Revenez alors sous l environnement Tornado, et via le workspace et plus précisément dans la feuille référencée par l onglet VxWorks analysez la structure interne de votre noyau. Proposez alors des modifications afin d optimiser la taille et voire même les performances de votre noyau. Faites valider vos propositions par l enseignant. Revenez alors dans l onglet Files du Workspace, puis re-compilez votre noyau. Vous vérifierez alors la nouvelle taille de votre noyau avant de le tester sur la cible PC Création d une application multi-tâches Conformément à ce qui vous est proposé page 36 de ce document et page 6 de la documentation technique, créez tout d abord votre premier module application dans votre Workspace BdF. Vous nommerez ce module Exercices. Une fois ce dernier mis en place, créez y un nouveau fichier que vous nommerez multi task.c (Attention à bien spécifier l extension.c pour faire appel au compilateur c et non C + ). Ensuite, au sein de ce fichier 54

55 C, il vous est demandé de mettre en œuvre le cahier des charges suivant dont la solution est livrée plus bas : le cahier des charges impose ici de créer deux tâches. La fonction mère (activité de niveau A0X SART) sera lancée via l interpréteur de commande (le shell). Start Fonction de lancement A0X Infos écran Création + activation Compter 1 Compter 2 A0X1 A0X2 Fig. 42 Exemple de création de tâches sous vxworks Cette fonction mère aura la charge de créer et activer ses tâches filles (A0X1, AOX2). Ces dernières devront afficher à l écran respectivement l état de deux compteurs. Solution : include vxworks.h include tasklib.h include stdio.h include kernellib.h include syslib.h int cpt1, cpt2, tid1, tid2; void compter 1() printf( \33[2J ); \ equivalent du clearscreen \ for(;;) cpt1++; printf( \33[1;1f ); \ equivalent du gotoxy(1,1) \ printf( Compteur 1 = %i, cpt1); } } void compter 2() for(;;) cpt2++; printf( \33[1;40f ); printf( Compteur 2 = %i, cpt2); } 55

56 } void Fonction de lancement() cpt1 = 0; cpt2 = 0; tid1 = taskspawn( tâche 1, 100, 0, 2000, (FUNCPTR)compter 1, 0,0,0,0,0,0,0,0,0,0); tid2 = taskspawn( tâche 2, 100, 0, 2000, (FUNCPTR)compter 2, 0,0,0,0,0,0,0,0,0,0); } Questions : 1. Recopiez ce code, commentez-le et prévoyez le résultat. 2. Testez le programme. Après avoir constaté le dysfonctionnement, lancez sous le shell la commande taskdelete(tid1). Que constatez-vous? Expliquez. 3. Proposez donc maintenant une solution pour régler automatiquement ce problème d allocation du CPU. Faites valider par l enseignant, testez. 4. A l exécution, le texte est désormais tronqué au bout d un certain temps. Pourquoi? 5. Vérifiez vos hypothèses en utilisant WindView. Commentez. 6. Proposez une solution pour que le texte soit affiché complètement à chaque exécution des tâches. Justifiez. 7. Vérifiez le comportement du programme en utilisant WindView. Commentez. 8. Réglez le temps d allocation CPU à 1 seconde par tâches. Contrôlez à la main vos compteurs. 13 Mise en œuvre d une synchronisation entre tâches Afin d illustrer la synchronisation entre tâches, nous nous proposons de résoudre le problème suivant : une première tâche doit saisir un nombre réel issu du clavier. Une deuxième tâche doit afficher ce nombre élevé au carré. Vous proposerez également une solution pour arrêter proprement le programme. Solution : dans cette solution, nous avons décidé de globaliser la donnée échangée entre les deux bulles SART. La synchronisation entre les deux tâches est assurée par deux sémaphores binaires. Solution : include <vxworks.h> include <stdio.h> include <stdlib.h> include <math.h> include tasklib.h include semlib.h 56

57 Données clavier Elever au carré Infos écran Diag. de contexte A0 Création + activation Données clavier Lire nombre Var Fin_calcul Calculer Infos écran A01 Démarre calcul A02 Fig. 43 Conception SART du problème include kernellib.h int tid1, tid2; / Identificateurs des taches / double var ; SEM ID demarre calcul, fin calcul; / Identificateurs des semaphores / / Prototypes des fonctions / void Elever au carre (void); void Lire nombre (void); void Calculer (void); void Elever au carre(void) tid1 = taskspawn( t1,100,0,2000,(funcptr)lire nombre,0,0,0,0,0,0,0,0,0,0); tid2 = taskspawn( t2,100,0,2000,(funcptr)calculer,0,0,0,0,0,0,0,0,0,0); demarre calcul = sembcreate(sem Q FIFO,SEM EMPTY); fin calcul = sembcreate(sem Q FIFO,SEM EMPTY); } void Lire nombre(void) for(;;) printf( \n Entrer un nombre reel : ); scanf( %lg,&var); semgive(demarre calcul); semtake(fin calcul,wait FOREVER); } } 57

58 Questions : void Calculer(void) for(;;) semtake(demarre calcul,wait FOREVER); printf( \t\t\t Son carre vaut : %lg,var*var); semgive(fin calcul); } } 1. Recopiez ce code, commentez-le et testez-le. 2. Lancez WindView. Imprimez le graphe obtenu et commentez le. 3. Dans un contexte ou d autres tâches auraient accès en écriture à la donnée var, quelle solution proposeriez vous afin d éviter d éventuels conflits. 14 Mise en œuvre d une communication/synchronisation par BAL Nous nous proposons ici de reprendre le même cahier des charges donné dans le paragraphe précédent. Cependant, nous vous proposons de donner une autre solution de mise en œuvre basée cette fois sur le mécanisme de boîtes aux lettres (queue). Solution : include <vxworks.h> include <stdio.h> include <stdlib.h> include <math.h> include tasklib.h include semlib.h include msgqlib.h include kernellib.h int tid1, tid2; / Identificateurs des taches / SEM ID fin calcul; / Identificateurs des semaphores / MSG Q ID Bal Demarre calcul; / declaration de la BAL / / Prototypes des fonctions / void Elever au carre (void); void Lire nombre (void); void Calculer (void); void Elever au carre(void) tid1 = taskspawn( t1,100,0,2000,(funcptr)lire nombre,0,0,0,0,0,0,0,0,0,0); 58

59 } tid2 = taskspawn( t2,100,0,2000,(funcptr)calculer,0,0,0,0,0,0,0,0,0,0); Bal Demarre calcul = msgqcreate(1, 10, MSG Q FIFO); fin calcul = sembcreate(sem Q FIFO,SEM EMPTY); Questions : void Lire nombre(void) double var1; for(;;) printf( \n Entrer un nombre reel (0 pour arreter) : ); scanf( %lg,&var1); msgqsend(bal Demarre calcul, (char *) &var1, sizeof(var1), WAIT FOREVER, MSG PRI NORMAL); semtake(fin calcul,wait FOREVER); } } void Calculer(void) double var2; for(;;) msgqreceive(bal Demarre calcul,(char *) &var2, sizeof(var2), WAIT FOREVER); printf( \t\t\t Son carre vaut : %lg,var2*var2); semgive(fin calcul); } } 1. Recopiez ce code, commentez-le et testez-le. 2. Lancez WindView. Imprimez le graphe obtenu et commentez le. Suite à cette série de quatre exercices découverte de la programmation multi-tâche temps réel sous l environnement Tornado II, vous êtes désormais prêts pour vous lancer dans la mise en œuvre d applications plus complexes. A toutes fins utiles, la dernière partie de ce document vous propose une technique simple de traduction systématique du langage SART sous vxworks. Pour davantage de précisions, nous vous convions à consulter le manuel de référence vxworks. 59

60 Cinquième partie Du SART à la mise en œuvre Tâche fils 1 A0X1 Start Tâche père Infos écran A0X Création + activation Tâche fils 2 Tâche fils 3 A0X2 A0X3 Si les trois activités SART A0X1, A0X2 et AOX3 doivent être exécutées en parallèle, alors elles devront être considérées et programmées en tant que tâches. Leur création et activation sera assurée par le père ici appelée Tâche père : tid1 = taskspawn("tâche fils 1", 100, 0, 2000, tachefils, 0,0,0,0,0,0,0,0,0,0); tid2 = taskspawn("tâche fils 2", 100, 0, 2000, tachefils, 0,0,0,0,0,0,0,0,0,0); tid3 = taskspawn("tâche fils 3", 100, 0, 2000, tachefils, 0,0,0,0,0,0,0,0,0,0); Tâche 1 Synchro Tâche 2 Une synchronisation entre deux tâches s appuiera sur un sémaphore binaire : void tache_1(void) #include "semlib.h". semgive(sem_binaire);.. } void tache_2(void) #include "semlib.h". semtake(sem_binaire, WAIT_FOREVER);.. } Tâche 1 Données Synchro Tâche 2 La transmission d information sera traduite sous vxworks par une boîte aux lettres : void tache_1(void) #include "semlib.h" int donnee1. MsgQSend(Bal_Synchro, (char *) &donnee1, sizeof(donnee1), WAIT_FOREVER, MSG_PRI_NORMAL);.. } void tache_2(void) #include "semlib.h" int donnee2. msgqreceive(bal_synchro,(char *) &donnee2, sizeof(donnee2), WAIT_FOREVER);.. } Fig. 44 Passage SART / VxWorks 60