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