1

Electronique embarquéeLe noyau temps réel µ C OS-II

Richard Grisel – Professeur des Universités –Université de Rouen

Conception des systèmes temps réelLe noyau temps réel µCOS

� Les figures sont extraites de l’ouvrage :� MicrC/OS-II, « The real time kernel », Second Edition par Jean J.

Labrosse CMP Books, ISBN 1-57820-103-9

2

Introduction : Systèmes de faible complexité

Foreground (ISR)/background � � Kernel

Application : Boucle infini qui gère des modulesPas de déterminisme

Quelques définitions

� Sections critiques de code� A traiter de manière indivisible (continue, ne peut pas être

interrompue et donc les interruptions ne sont pas autorisées généralement)

� Ressources� Toute entité utilisée par une tâche

� I/O : imprimante, clavier, afficheur� Mémoire : variables, structures, tableau

� Ressource partagée� Peut être utilisée par plusieurs tâches, nécessite une exclusion

mutuelle (MUTEX, accès exclusif tâche en cours) pour prévenir la corruption des données.

� Multi-tâches

3

Les tâches (Thread)

� Chaque tâche a une priorité, une pile et un jeu de registres du CPU

� Une tâche = Une boucle infinie dans un certain état� Sommeil : en mémoire mais pas dans la gestion des tâches� Prête : Peut s’exécuter mais pas encore en priorité� Exécution : Contrôle du CPU� Attente d’évènement : (Fin d’I/O, attente ressource partagée, etc..)� Interrompue par ISR : L’ISR a pris le contrôle.

Le multi-tâches

4

Tâches et fonctions de uCOS

Le changement de contexte (« Context switch »)

� Changement de tâche = sauvegarde du contexte de la tâche en cours et récupération du contexte de la tâche àexécuter

� Cela ajoute des charges (en temps) à l’application� Plus il y a de registres à sauvegarder, plus le temps de

changement de contexte sera long

5

Le noyau (« Kernel »)

� Gestion des tâches et des communications inter-tâches� Un noyau temps réel simplifie la conception� Le service principal est le changement de contexte� Le noyau prend sur le temps d’exécution (2% à 5% pour

les systèmes bien conçus)� Nécessite espace ROM et RAM, les tâches de la RAM

aussi (pile), ce qui « mange » beaucoup de RAM� Attention au micro-contrôleur « single-chip » (peu de RAM)� Permet les sémaphores, boites aux lettres, queues, gestion

du temps

L’Ordonnanceur (« Scheduler ou dispatcher »)

� Détermine quelle tâche va s ’exécuter� L’exécution est généralement basée sur une priorité� De manière générale la tâche de plus haute priorité va

s’exécuter� Il existe des noyaux préemptifs et des noyaux non

préemptifs� Non Préemptif (ou collaboratif) (voir figure suivante) : les

évènements asynchrones sont gérés par des ISR, la tâche de plus haute priorité prend le contrôle à la fin de l’exécution de la tâche en cours

� Préemptif (majoritairement dont uCOS) : Contrôle toujours donné àla tâche de plus haute priorité

6

Ordonnancement non préemptif

Ordonnancement préemptif

7

Les fonctions réentrantes

� Peut être utilisée par une ou plusieurs tâches sans problème de perte (ou de corruption) de données

� Elles utilisent généralement des variables locales (Registres CPU ou dans la pile) ou protègent les données en cas de variables globales

� Exemple :

� Les paramètres de strcopy sont placées dans la pile de la tâche, donc des appels multiples ne parasiteront pas les pointeurs des autres tâches

� L’exemple suivant montre une fonction non réentrante (Temp est un « integer » global et le noyau est préemptif avec interruptions autorisées)

Tâche priorité basse Tâche priorité haute

8

Définitions (suite)

� L’Ordonnancement « Round-Robin »� Pour les tâches de même priorité un quantum (constante de temps

prédéterminée) est alloué (temps partagé)� Le noyau donne contrôle à la tâche suivante (même prio) si :

� La tâche courante n’a pas besoin de son quantum� La tâche courante s’arrête avant la fin de son quantum� Le quantum arrive à sa fin

� A vérifier pour uCOS� Priorités statiques

� Pas de changement pendant l’exécution, chaque tâche a une priorité définit à la compilation (déterministe)

� Priorités dynamiques� Possibilité de modification à l’exécution, permet d’éviter l’inversion

de priorité, disponible dans uCOS

L’inversion de priorité

9

L’héritage de priorité

Affectation des priorités

� Ce n’est pas une tâche triviale� La technique RMS est classique et part d’un certain

nombre d’hypothèses� Toutes les tâches sont périodiques� Pas de synchronisation entre les tâches (ressources, données)� Le CPU exécute la tâche de plus forte priorité (Préemptif)� L’inégalité RMS

10

Exclusion mutuelle

� Communication facile = partage de ressources communes (données, variables, pointeurs,etc..)

� Nécessite que l’accès soit exclusif� Interdire les interruptions� Faire des instructions « Test and set »� Interdire l’Ordonnancement (attention)� Utiliser des sémaphores

� uCOS fournit deux procédures pour la gestion

« Test and Set »

Algorithme « soft » si pas d’implémentation « hardware » (par exemple famille 68000)

11

Interdire l’Ordonnancement

� Cela revient à devenir non préemptif (dangereux), il vaut mieux utiliser des sémaphores.

Les sémaphores (Edgser Dijkstra, milieu des années 60)

� Le sémaphore permet :� Le contrôle d’accès aux ressources partagées� De signaler l’apparition d’un évènement, et� De permettre à 2 tâches de synchroniser leurs activités

� Le sémaphore est une clé, si il est actuellement utilisé, la tâche requérante est suspendue jusqu’à la relâche du sémaphore par la tâche qui l’utilise.

� Il a deux types :� Binaire (0 ou 1)� Compteur (0 à max, max fonction du nombre de bits)

� Le noyau doit garder la trace des tâches attendant la libération du sémaphore.

12

Les sémaphores (suite)

� Trois opérations :� INITIALIZE (ou CREATE), WAIT (ou PEND), SIGNAL (ou POST)� La valeur initiale est donnée à l’initialisation, la liste des tâches en

attente est vide� Une tâche veut le sémaphore (WAIT), si il est libre sa valeur passe

à 0 et la tâche continue, sinon la tâche entre en liste d’attente (avec gestion d’un « timeout »). Une tâche libère le sémaphore par un SIGNAL, si il n’y a pas de tâche en attente le sémaphore est simplement incrémenté, sinon le sémaphore garde sa valeur et :

� Tâche de plus forte priorité (uCOS)� Première tâche en attente (FIFO)

Les sémaphores (suite)

Demande du sémaphore

Libération du sémaphore

13

Les sémaphores (Exemple de l’imprimante)

Les sémaphores (Encapsulation)

14

Les sémaphores (type compteur)

� Cas d’un « pool » de buffer qui est limité à 10� Une tâche obtient un buffer du gestionnaire par BufReq(),

et le libère par BufRel()� Le gestionnaire satisfait aux 10 premières demandes, la

prochaine tâche faisant la demande sera suspendue. Cette gestion est là aussi encapsulée dans le gestionnaire.

� Il ne faut pas forcément utilisé un sémaphore pour un accès à une variable partagée (une interdiction des interruptions peut suffire)

15

Le blocage (« Deadlock » )

� T1 a un accès exclusif à R1, et T2 à R2, si T1 a besoin de R2 et T2 de R1, aucune des tâches ne peut continuer.

� Le meilleur moyen d’éviter le blocage :� Acquérir toutes les ressources avant de démarrer� Acquérir les ressources dans le même ordre et,� Les libérer dans l’ordre inverse

� La majorité des noyaux permettent de définir un « timeout »sur les sémaphores (évite aussi le blocage), il faut dans ce cas un code d’erreur pour éviter à la tâche de croire qu’elle a obtenu la ressource.

Les sémaphores et la synchronisation

� Une tâche peut se synchroniser avec une ISR (ou une autre tâche) avec un sémaphore. C’est dans ce cas un drapeau (et non une clé) qui signale un évènement. Il est initialisé à 0. Ce type de synchronisation s’appelle rendez-vous unilatéral. Par exemple, une tâche peut lancer une opération d’I/O et attendre le sémaphore. Quand l’opération d’I/O est terminée, une ISR (ou une autre tâche) fait un signal sur le sémaphore (incrémentation), et la tâche peut reprendre. Si le noyau supporte les sémaphores compteur, il accumule les évènements non traités. Plus d’une tâche peut être en attente d’évènement, le noyau dans ce cas signale :� À la tâche de plus haute priorité en attente� A la première tâche en attente de l’évènement

16

Sémaphore et synchronisation (rendez-vous bilatéral)

� Synchronisation de deux tâches (pas d’ISR qui ne peut pas attendre un sémaphore)

Les drapeaux d’évènements

� Pour synchroniser une tâche avec des évènements multiples. Une tâche peut être synchronisée quand un des évènements est arrivé(fonction OU, synchronisation disjonctive) ou quand tous sont arrivés (fonction ET, synchronisation conjonctive).

17

Drapeaux d’évènements (Implantation)

� Les évènements sont généralement groupés (1 bit par évènement, groupés par 8,16 ou 32). Les tâches ou les ISR peuvent positionner ou reseter un évènement. L’évaluation de la tâche qui doit lancée est faite quand un nouvel ensemble d’évènements arrive (opération SET).

Les noyaux (uCOS par ex.) fournissent les fonctions SET, CLEAR et WAIT pour les drapeaux d’évènements.

Communication inter-tâches

� Tâche ou ISR, peuvent avoir besoin de communiquer avec une autre tâche (par données globales ou messages). � Données globales : nécessitent accès exclusif à la variable. Si une ISR est

impliquée, il faut interdire les interruptions. Si deux tâches partagent des données, elles peuvent interdire puis autoriser les interruptions (accès exclusif) ou utiliser un sémaphore (voir précédemment). Une tâche peut uniquement communiquer des informations à une ISR via des variables globales, la tâche n’est pas mise au courant du changement par l’ISR sauf si l’ISR signale à la tâche par un sémaphore ou que la tâche effectue une scrutation périodique de la variable. Pour corriger ce problème on utilise soit une boîte aux lettres de messages (mailbox) soit une queue de message.

� Boîte aux lettres :� Typiquement une variable pointeur, une tâche ou une ISR peut déposer un message

(le pointeur) dans la boîte aux lettres. L’émetteur et le récepteur doivent s’accorder sur ce que pointe le pointeur. Une liste d’attente est associée à chaque boite aux lettres (une tâche qui attend un message alors que la boite est vide sera mise sur liste d’attente, avec timeout). Le message déposé on y accède par priorité ou FIFO

18

Boite aux lettres

� Le noyau fournit les services suivants :� Initialisation d contenu de la boite (avec ou sans message)� Dépôt d’un message (POST)� Attente d’un message (PEND)� Réception d’un message de la boite (ACCEPT)

� Une boite aux lettres peut simuler un sémaphore, un message présent indique que la ressource est libre, absent que la ressource est utilisée.

Ticks d’attente (Timeout)

Queue de message

� Envoi d’un ou plusieurs messages (tableau de boites aux lettres). En FIFO (mais uCOS permet aussi en LIFO). Avec fonctionnement équivalent aux boites aux lettres.� Initialisation� POST� PEND� ACCEPT

La tâche attendra indéfiniment

19

Les interruptions (Rappels)

� L’interruption est l’unité de base de communication entre le matériel et l’OS

� C’est un mécanisme matériel qui informe le CPU d’un évènement asynchrone, pour traitement « immédiat »

� Pas besoin de « polling »

� Une routine utilisateur (ISR) peut être installée pour traiter l’interruption

Les interruptions (Rappels)

20

Les interruptions (Rappels)

� Le RTOS utilise une table d’interruptions où chaque entrée correspond à un gestionnaire d’interruptions différent.

� La majorité des CPU supportent les interruptions imbriquées

� Le RTOS désactive les interruptions avant une section de code critique et les réactive à la fin de la section.

� Si une IT survient pendant une désactivation, sa période d’attente représente une spécification importante pour le RTOS (latence des interruptions)

Les Interruptions

� Latence des interruptions� Plus longtemps les interruptions sont interdites, plus forte est la latence des

interruptions, la latence est donnée par l’expression suivante :� Temps maximum pendant d’interdiction des interruptions + Temps nécessaire pour

exécuter la première instruction de l’ISR

� Réponse des interruptions� Temps écoulé entre la réception de la demande d’IT et le début de l’ISR� Pour un système classique, le temps de réponse est donné par :

� Latence d’interruption + Temps de sauvegarde du contexte

� Pour un noyau non préemptif, il est donné par la même formule� Pour un noyau préemptif, une fonction spéciale doit être appelée pour signifier

qu’une ISR démarre (trace des interruptions). Pour uCOS cette fonction est OSIntEnter(), le temps de réponse est alors donné par :

� Temps de latence + Temps de sauvegarde du contexte + Temps d’exécution de la fonction spéciale

� Il faut tenir compte du cas le + défavorable (si le temps de réponse est de 50 µs dans 99% des cas et 200 dans le pire, alors il faut prendre en compte 200).

21

Interruptions (temps de récupération)

� C’est le temps nécessaire pour le processeur pour revenir au programme interrompu (ou à la tâche de plus haute priorité pour un noyau préemptif)

� Pour un système classique :� Temps de restauration du contexte CPU + temps d’exécution de l’instruction de

retour d’interruption

� Pour un système non préemptif, c’est la même chose� Pour un système préemptif, une fonction est appelée à la fin de l’interruption

(OSIntExit() pour µCOS) et elle permet de voir si une tâche de plus forte prioritéest prête. Si c’est le cas cette tâche est lancée, dans ce cas la tâche interrompue est relancée quand elle devient la tâche de plus forte priorité.� Temps de détermination de la tâche prioritaire + Temps de restauration du contexte

CPU de cette tâche + Temps d’exécution de l’instruction de retour d’interruption

Les interruptions (temps pour un système classique)

22

Les interruptions (temps pour un noyau non préemptif)

Les interruptions (temps pour un noyau préemptif)

A : Pas de tâche de priorité supérieureB : Tâche avec priorité + grande que celle interrompue

23

Les interruptions non masquables

� Rien ne limite a priori le temps de traitement d’une interruption. Quelquefois une interruption doit être servie le plus vite possible, et ne peut pas attendre la latence imposée par le noyau. Il faut utiliser dans ce cas la NMI. Elle doit être réservée à des cas limites (par exemple sauvegarde en baisse de tension). Les temps de latence, de réponse et de restauration sont minimaux.

� Temps de latence d’une NMI = Temps d’exécution de la plus longue instruction + Temps de démarrage de la routine NMI

� Temps de réponse = Temps de latence + Temps de sauvegarde du contexte� Temps de restauration = Temps de restauration du contexte CPU + Temps d’exécution

de l’instruction de retour d’interruption� Généralement le contexte sauvegardé est minimal.� Les services du noyau ne sont pas utilisables en NMI, pour passer des paramètres il faut

utiliser des variables globales avec instruction unique de lecture ou d’écriture. � On peut aussi utiliser un circuit externe pour interdire les interruptions non masquables

(port d’I/O avec fonction logique « gatée » par la NMI).

NMI, exemple de passage de message

� Supposons qu’une NMI doit signaler à une tâche quand elle s’est exécutée 40 fois. Pour une NMI toutes les 150 µs, cela fait un signal toutes les 6 ms. On ne peut pas utiliser le noyau mais on peut passer par le schéma ci-dessous. La NMI génère une interruption « hardware » ISR via un port de sortie

� NMI ayant la plus haute priorité (et pas de chaînage des IT en NMI), l’ISR n’est pas reconnue avant la fin de la NMI. A la fin de la NMI, l’ISR va remettre à zéro l’interruption « hardware » et poster un message dans un sémaphore. Tant que la tâche répond au sémaphore dans les 6 ms, l’échéance est respectée.

24

Traitement des interruptions

� Une ISR débute par la sauvegarde des registres du CPU

� Ensuite l’ISR définie par l’utilisateur est exécutée.

� Après le retour de l’ISR, les registres CPU sont restaurés

� Opérations typiques d’une ISR :� Lire et écrire la mémoire affectée aux registres I/O� Communiquer des informations à une tâche

� Écriture en mémoire partagée� Ecriture de messages (queue)� Donner un sémaphore binaire

� La tâche de retour d’ISR est la + prioritaire

Traitement des interruptions (la pile)

� La majorité des architectures disposent d’une pile spéciale dédiée aux interruptions� La pile IT est assignée lors du démarrage du système� La pile doit être dimensionnée pour le cas d’imbrication le plus

critique

� Les architectures x86, R6000, CPU-32, MC68060, MC68000 et MC68010 traitent les interruptions dans la pile des tâches� La pile de chaque tâche doit avoir assez d’espace supplémentaire

pour traiter le cas d’imbrication des interruptions le plus critique

25

Traitement des interruptions (Problèmes de conception)

� Généralement les interruptions sont écrites en assembleur :

� Elles peuvent faire des appels « C »� Pour un système RT, le temps d’attente d’une IT doit être le

plus court possible afin d’assurer un temps de réponse du système minimal

� Une ISR ne peut pas :� Se bloquer, être en attente d’un sémaphore ou de recevoir des

messages, dans une queue de messages� Appeler des routines d’allocation dynamique de la mémoire qui

utilisent des sémaphores (malloc())� Appeler des routines I/O de système (par ex. printf sauf en debug)

Traitement des interruptions (Restrictions des ISR)

� Une ISR doit être maintenue la plus courte possible :� Les IT de niveau inférieur sont en attente� Les tâches sont en attente� Le déboguage est difficile

� Il faut éviter les opérations en virgule flottante dans les ISR� Elles sont lentes (voire très lentes) et amènent un « stack »

relativement lourd� Il faut sauvegarder les regsitres liés au FPU

26

Interruptions dans µ COS

� Pseudo-code de l’ISR� MonISR :

� Sauvegarder si nécessaire les registres du CPU� Appeler OSIntEnter()� Exécuter le code de l’ISR utilisateur� Appeler OSIntExit()� Restaurer dans l’ordre les registres précédemment sauvegardés

OSIntEnter() :Désactive les interruptions (accès exclusif à la variable globale OSIntNesting)Incrémente la variable globale OSIntNesting qui mémorise les imbricationsRéactive les interruptions

OSIntExit() :Décrémente la variable globale OSIntNestingSi OSIntNesting arrive à 0, détermine la tâche prête à partir qui va prendre le contrôle du CPU

Les interruptions (le « Clock tick »)

� C’est une interruption périodique. C’est le battement de cœur du système. Il est généralement compris entre 10 et 200 ms. Tous les noyaux permettent aux tâches d’être retardées d’un ou plusieurs « clock ticks ». Les trois figures suivantes montrent une tâche qui demande un délai de 1 tick. Les rectangles noires indiquent le temps d’exécution pour chaque opération exécutée. Le temps pour chacune des opérations est censée reflété un traitement typique (if/then/else/switch et ?), le temps de l’ISR (tick ISR, alloué à la gestion des ticks par le noyau) a été exagéré pour montrer qu’il est lui aussi sujet aux variations de temps d’exécution.

Cas 1 : Toutes les tâches de priorité plus haute s’exécutent ainsi que l’ISRavant la tâche. On constate un flottement dans l’exécution de la tâche.

27

Les interruptions (le « clock tick »)

� Cas 2 où l’ISR et les autres tâches durent un peu moins d’un tick, cela fat que la tâche qui vient de se décaler d’un tick s’exécute immédiatement. Doit se gérer en mettant +1 au délai demandé sous réserve que les autres temps soient constants.

Les interruptions (le « clock tick »)

� Cas 3 : Les autres tâches et l’ISR s’étendent au-delà d’un tick, dans ce cas la tâche s’exécute un tick plus tard et manque son échéance. Cela peut être acceptable mais dans la majorité des cas cela ne l’est pas .

28

Solutions aux problèmes de « ticks »

� Augmenter la vitesse d’horloge du processeur� Augmenter le temps entre chaque « tick »� Modifier les priorités� Ne pas utiliser la virgule flottante (virgule fixe pour les calculs)� Prendre un compilateur avec optimisation� Prendre un microprocesseur plus rapide dans la même famille.

Spécifications mémoire

� Pour un système classique, les besoins en mémoire dépendent du code de l’application. Pour un noyau multi-tâches c’est un petit peu différent. Pour commencer un noyau nécessite de la ROM (extra code). Cette taille dépend de beaucoup de facteurs (entre 1 et 100 Koctets). Pour un noyau sur processeur 8-bits avec ordonnancement, changement de contexte, gestion des sémaphores, des délais, et des « timeouts », cela nécessite environ 1Ko à 3Ko de code. La totalité du code est donnée par la formule suivante :� Code de l’application + Code du noyau

� Chaque tâche étant indépendante, elle doit avoir sa propre zone de stockage (RAM). Cela doit être estimé le + précisément possible pour chaque tâche (pas forcément évident d’ailleurs : variables, interruptions en chaîne, etc..). Une pile séparée peut éventuellement être utilisée pour gérer tous les codes d’interruption ce qui allège l’espace alloué à chaque tâche. Le noyau a besoin lui aussi de RAM (données, variables, structures, queues, etc..). La taille de la RAM est donnée (pour un noyau sans gestion séparée des interruptions) :� Espace pour le code de l’application + espace pour le noyau + SOMME (pile des

tâches + MAX (interruptions en chaîne))� Si le noyau supporte une pile séparée pour les interruptions :

� Espace pour le code de l’application + espace pour le noyau + SOMME (pile des tâches)+ MAX (interruptions en chaîne)

29

Avantages et inconvénients

� Un noya temps réel (RTS) permet une conception rapide et efficace et qui peut s’étendre. Des fonctions peuvent être rajoutées sans changement majeur au logiciel. Par exemple, si l’on ne rajoute que des fonctions de très faible priorité, cela aura peu d’incidence sur la réponse du système aux tâches de priorité élevée. Le code est séparée en tâches et les ressources sont gérées de manière uniforme (sémaphores, queues, boites aux lettres, etc..). Il faut bien entendu supporter un coût lié (plus de ROM/RAM, coût du noyau, de 2 à 4% en plus sur la charge du CPU. Il y a à l’heure actuelle plus de 150 fournisseurs de RTOS. Les coûts varient de 70 USD à plus de 30 000 USD. Il y a aussi des politiques de « royalties » par système vendu (entre 5 et 500 USD). Il faut aussi prendre en compte le coût de maintenance, qui peut aller jusqu’à 15% du coût de développement par an. Il existe aussi des RTOS gratuits (dont un RT-linux). Le tableau de la page suivante résume les différentes caractéristiques des systèmes temps-réel (classique, non préemptif, préemptif).

30

La structure du noyau µCOS

� Accès aux sections critiques� Qu’est ce qu’une tâche?� Comment µCOS gère-t-il les tâches?� Comment les tâches sont elles ordonnancées?� Comment µCOS détermine-t-il le %CPU alloué à une

application ?� Comment écrire les ISR?� Comment µCOS gère-t-il les ticks?� Comment initialiser µCOS et lancer le multi-tâches?

Constantes de configuration dans le fichier OS_CFG.H

� Ce chapitre décrit aussi les services d’applications suivants :

On peut noter que OSSchedLock() et OSSchedUnlock() peuvent être inhibés en mettant à 0 le bit OS-SCHED_LOCK_EN du fichier OS_CFG.H. Tous les autres services sont partie intégrantes du système d’exploitation.

31

Structure des fichiers de µCOS

Plus d’une centaine de processeurs (du 8051 au 80x86 e passant par la famille ARM), 1 émulateur 80x86 sur PC.

Les sections critiques, OS_ENTER_CRITICAL() et OS_EXIT_CRITICAL()

� Les processeurs disposent d’instructions d’interdiction des interruptions. Soit le compilateur C les inclut directement, ou au moyen d’instructions en assembleur mélangées au code C, ou par des extensions de langage. Pour cacher la méthode d’implantation, microCOS définit deux macros , comme elles dépendent du processeur, elles sont dans la partie spécifique au processeur (fichier OS_CPU.H). Elles sont toujours utilisées ensemble, comme montré sur l’exemple de code suivant :� .� OS_ENTER_CRITICAL();� /* section de code critique */;� OS-EXIT_CRITICAL();� .

� Vous pouvez aussi les utiliser pour écrire des portions de code critique (mais attention par exemple à OSTimeDly() qui bloquera le processeur si les interruptions sont inhibées quand on l’appelle). Ce problème arrive quand on suspend la tâche jusqu’à expiration du temps, mais comme les interruptions sont inhibées, on ne sert pas le tick, mais aussi tous les appels PEND sont sujets à ce problème. Il faut don éviter d’appeler un service OS avec les interruptions inhibées. Il y a trois manières différentes d’implémenter les sections critiques (définition par la constante OS_CRITIQUAL_METHOD du OS_CPU.H)

32

OS_CRITICAL_METHOD == 1

� La manière la plus simple est d’invoquer les instructions du processeur pour interdire et autoriser les interruptions. Cependant si on appelle une fonction microCOS avec les interruptions interdites, au retour de la fonction microCOSles interruptions seront autorisées. Ce qui n’est pas forcément ce qui aurait été souhaité.

OS_CRITICAL_METHOD == 2

� La deuxième manière est de sauvegarder l’état d’interdiction des interruptions dans la pile puis d’interdire les interruptions (OS_ENTER_CRITICAL()). OS_EXIT_CRITICAL() est dans ce cas implémenté en restaurant l’état d’interruption à partir de la pile. Dans ce cas l’état est préservé même après l’appel d’une fonction (service) de microCOS. Attention au fait que l’on augmente la latence de l’interruption. Le pseudo code est dans ce cas le suivant (assemblage « in-line » possible):� #define OS_ENTER_CRITICAL()\

� Asm(« PUSH PSW »)\� Asm (« DI »)

� #define OS_EXIT_CRITICAL()\� Asm(« POP PSW »)

� Attention à la gestion des modifications du « stack pointer » par le compilateur.

33

OS_CRITICAL_METHOD == 3� Certains compilateurs permettent des extensions pour l’obtention du

registre d’état du processeur (PSW) et donc de le sauvegarder dans une variable C locale. � void Some_uCOS_Service(arguments)� {OS_CPU_SR cpu_sr;� cpu_sr=get_processor(PSW);� disable_interrupts();� /* Section critique*/� set_processor_psw(cpu_sr);

� OS_CPU_SR est un type de donnée déclaré dans OS_CPU.H, get_processor_psw() doit être fournie par le compilateur, ainsi que disable_interrupts() et set_processor_psw(). Comme on ne connaît pas les fonctions du compilateur, les macros encapsulent les fonctionnalités :� #define OS_ENTER_CRITICAL()\

� cpu_sr=get_processor_psw()\� Disable_interrupts();

� #define OS_EXIT_CRITICAL()� set_processor_psw(cpu_sr);

Les tâches

� Une tâche est une boucle infinie ( on peut aussi utiliser un while(1). Un paramètre est passée la première fois qu’une tâche s’exécute. C’est un pointeur sur un void, ce qui permet de passer à peu près n’importe quoi (adresse de variable, structure, d’une autre fonction;, etc..).

�Par exemple si l’on a 4 ports série, on utilise la même tâche pour chacun d’eux mais le pointeur d’entrée définit la structure des paramètres du port série (vitesse,adresse I/O, vecteur d’interruption, etc..). �Une tâche peut se « détruire » (du point de vue de l’OS, pas du code qui reste en mémoire) par OSTaskDel().

34

Les tâches

� MicroCOS peut gérer jusqu’à 64 tâches (2 tâches sont réservées au système). Chaque tâche doit se voir assigner une priorité unique. En fait on peut avoir 56 tâches effectivement si l’on tient compte des restrictions liées à l’OS, qui se réserve les 4 niveaux les plus bas et les 4 niveaux les plus hauts. Le niveau de priorité va de 0 àOS_LOWEST_PRIO-2 compris. Plus le nombre associé à la priorité est faible, plus la priorité est forte. MicroCOS exécute toujours la tâche de plus forte priorité prête. Le niveau de priorité sert aussi d’identificateur de tâche (pour quelques services de l’OS comme OSTaskChangePrio() et OSTaskDel()). Pour qu’une tâche soit gérée par l’OS, il faut la créer en passant des paramètres à une des deux fonctions OSTaskCreate() ou OSTaskCreateExt() qui est une version étendue de la première avec des fonctionnalités supplémentaires (voir dans la gestion des tâches). Il y a toujours une tâche présente, la tâche IDLE, si aucune tâche ne s’exécute.

Les états d’une tâche

35

Les appels (tâche)

� OSStart() lance le démarrage du multi-tâches, il doit être appelé une seule fois au démarrage et démarrera la tâche de plus haute prioritécréée à l’initialisation.

� OSTimeDly() ou OSTimeDlyHMSM() retarde la tâche pendant un certain temps (elle devient WAITING jusqu’à ce que ce temps expire). La tâche retardée est remise prête à l’exécution par OSTimeTick() (Fonction interne qui n’a pas à être appelée).

� OSFlagPend(), OSSemPend(), OSMutexPend(), OSMboxPend() ou OSQPend() mettent la tâche en attente d’un évènement (WAITING), la tâche de plus haute priorité suivante passe en exécution. La tâche redevient READY quand l’évènement (par une autre tâche ou une ISR) arrive ou qu’un « timeout » survient.

� OS_TaskIdle() est la tâche exécutée par l’OS quand toutes les autres tâches sont en attente (délai ou évènement).

Le Bloc de contrôle de tâche (OS_TCB)

� Une tâche créée se voit affectée un bloc de contrôle. C’est une structure de donnée qui maintient l’état de la tâche en cas de préemption. Le TCB permet aussi de récupérer l’état de la tâche quand elle redevient active. C’est une zone en RAM dont la structure est donnée sur le transparent suivant.

� Le TCB contient :� La priorité de la tâche� Son état� Un pointeur vers la pile� D’autres données concernant la tâche (voir ci-après)

� Le TCB occupe 45 octets pour une architecture 80x86 (large model)

36

Structure TCBVersion 251

Quelques changements pour la version 252

Spécifications dans le TCB

37

Spécifications TCB (suite)

Spécifications TCB (suite)

38

TCB (suite)

� Le nombre maximum de tâches est spécifié par OS_MAX_TASKS dans OS_CFG.H. Il détermine aussi le ombre de TCBs alloués pour l’application. On peut réduire la RAM allouée aux TCB en fixant le nombre de tâches effectivement aux tâches de l’application. L’OS alloue un extra TCB pour la tâche IDLE et un autre pour la tâchestatistique (si OS_TASK_STAT est à 1). A l’initialisation tous les TCB sont liés selon une liste comme indiqué sur la figure ci-dessous. Quand une tâche est créée, l’OS_TCB est prend la valeur de OSTCBFreeListqui pointe ensuite sur la liste suivante.

Initialisation du TCB

� La fonction OS_TCB_Init() initialise le TCB quand une tâche est créée (par OSTaskCreate() ou OSTaskCreateExt()). Cette fonction reçoit 7 paramètres :� prio est la priorité de la tâche� ptos est le pointeur sur le sommet de la pile (après construction de

la pile par OSTaskStkInit() ), il est stocké dans le champ .OSTCBStkPtr

� pbos est le pointeur sur le bas de la pile (.OSTCBStkBottom)� id est l’identificateur de la tâche (.OSTCBId)� stk_size est la taille totale de la pile (.OSTCBStkSize)� pext est la valeur à mettre dans .OSTCBExtPtr� opt, options est stocké dans .OSTCBOpt

� T

39

OSTCBInit()

#if OS_CRITICAL_METHOD==3OS_CPU_SR cpu_sr;

#endif

>0

>0

#if OS_EVENT_EN >0ptcb -> OS_TCBEventPtr=(OS_EVENT *)0;

#endif

#if OS_VERSION >204 OSTCBInitHook(); #endif;

OSTaskCreateHook();

40

La liste « Ready »

� Chaque tâche a une priorité entre 0 et OS_LOWEST_PRIO. OS_LOWEST_PRIO est affecté à la tâche IDLE. OS_MAX_TASKS et OS_LOWETS_PRIO ne sont pas reliés, il peut y avoir seulement 10 tâches avec possibilités de 32 priorités (si OS_LOWEST_PRIO vaut 32). Chaque tâche prête à s ’exécuter est placé dans une liste constituée de 2 variables (OSRDyGrp et OSRdyTbl[]). Les priorités sont groupées par 8 dans OSRDyGrp , chaque bit dans un groupe indique si une des tâches du groupe est prête. Quand une tâche est prête elle positionne son bit associé dans la table OSRdyTbl[].

� Pour une tâche de priorité prio,son groupe est identifié par un décalage de 3 bits de prio, son numéro dans le groupe par un masque des 3 bits de poids faible.

� Pour déterminer quelle tâche doit être exécutée, l’Ordonnanceur détermine quel est le bit positionné dans la table OSRdyTbl[].

41

Quelle tâche à exécuter?

Tâche statistique de l’OS

� La tâche OS_TaskStat() est créée si OS_TASK_STAT_EN est à 1. Elle s’exécute toutes les seconde et calcule le % d’usage du CPU. Cette valeur est placée dans OSCPUUsage (8 bits, résolution 1%). Pour l’utiliser il faut appeler OSStatInit() à partir de de la première tâche créée à l’initialisation. Il y a seulement 3 tâches au démarrage dans ce cas (TaskStart(), OS_TaskIdle() priorité la + faible et OS_TaskStat() priorité la + faible -1 par construction)

42

Initialisation de la tâche statistique

Les interruptions

� Les ISR doivent être écrites en langage assembleur. Cependant si le compilateur C supporte l’écriture « on-line » de l’assembleur (directive asm par exemple) alors on peut écrire directement le code de l’ISRdans un fichier source. Le pseudo-code d’une ISR est donné ci-dessous :

� Le retour est plutôt généralement fait normalement plutôt que par le RTI (RTS, le C ne connaît pas le RTI), pour éviter les problèmes de pile (Cas des fonctions « naked » pour certains compilateurs).

(Doit réinitialiser la cause)

43

Service des interruptions (2 cas)

Signal vers une tâche

Temps de réponse de la tâche de Haute Priorité

Interrupt Recovery

Une tâche est devenue + prioritaire

Pas de changement de priorité

Les interruptions

� On arrive là à la limite du logiciel et on devient très dépendant du matériel. C’est un point à traiter avec particulièrement d’attention quant à l’exécution par l’OS car le fonctionnement diffère d’un processeur à l’autre ( Pile différente pour les IT, chaînage possible ou pas, choix des vecteurs, etc…)

44

Les « Clock tick »

� microCOS requiert une source périodique pour prendre en compte les délais et les « timeout » (entre 10 et 100 Hz). Soit on dédie un « timer » à cette opération, soit on utilise une interruption générée par une alimentation (50/60Hz). Les interruptions de « tick » doivent être autorisées après le démarrage du multi-tâches (i.e. après OSStart() et pas après OSInit()). Le service de tick est démarré par l’appel de OSTimeTick à partir d’une ISR (gérée comme une ISR normale). Le pseudo-code de l’ISR de tick est donné ci-après (fournie avec le port si il existe).

(Faire un raz de l’IT si nécessaire)

Gestion des tâches

� Une tâche doit avoir l’une des deux structures suivantes :

OS_PRIO_SELF est le niveau de priorité de la tâche elle-même (SELF) et donc son indicateur

45

Création de la tâche

� OSTaskCreate(void *task, void *pdata,OS_STK *ptos, INT8U prio)� task est le pointeur sur le code de la tâche (nom de la fonction)� pdata est un pointeur sur un paramètre à passer à la tâche� ptos est un pointeur sur le sommet de la pile allouée à la tâche (voir

OS_STK)� prio est la priorité donnée à la tâche� OSTaskCreateExt(void *task, void *pdata,OS_STK *ptos, INT8U

prio, INT16U id, OS_STK *pbos, INT32U STK_SIZE, void *pext, INT16U opt)

� Idem que ci-dessus pour les 4 premiers paramètres +� id est l’identificateur de tâche (pas encore utilisé)� pbos : pointeur vers la base de la pile affectée à la tâche� STK_SIZE : taille de la pile à affecter (en octets)� pext : pointeur vers la zone de mémoire contenant les extensions

utilisateurs du TCB de la tâche � opt : options de la tâche

Pile de la tâche

� Chaque tâche doit avoir un espace réservé dans la mémoire. Cet espace doit être déclaré de type OS_STK (emplacements mémoire contigus). L’allocation peut être statique (à la compilation) ou dynamique (à l’exécution).

� Déclaration statique� Static OS_STK MyTaskStack[stack_size], ou� OS_STK MyTaskStack[stack_size]

� Déclaration dynamique� Peut utiliser la fonction C malloc(), mais attention à la fragmentation

� R

46

Pile (fragmentation)

� L’exemple ci-dessous montre un espace de 3Ko, si 3 tâches s’alloue chacune 1Ko (A,B et C) et que l’on libère ensuite A et C (free()) après destruction des tâches, on a bien 2Ko de libre mais pas contigus et donc une demande de création avec 2Ko n’est pas possible.

Pile (paramètre du pointeur sur les données)

� microCOS supporte les processeurs avec pile fonctionnant du haut vers le bas (1) et du bas vers le haut (0) (OS_STK_GROWTH dans OS_CPU.H). Quand il vaut 0 il faut passer l’adresse de l’emplacement mémoire le plus bas. Quand il vaut 1 il faut passer l’adresse de l’emplacement mémoire le plus haut. Ceci affecte la portabilité, on peut éventuellement passer cela en macro #if sur OS_STK_GROWTH pour supporter les 2.

OS_STK_GROWTH=0

OS_STK_GROWTH=1 (Intel)

47

Suspension d’une tâche - OSTaskSuspend()Reprise d’une tâche – OSTaskResume()

� OSTaskSuspend() suspend la tâche effectivement (numéro donné en paramètre, OS_PRIO_SELF pour la tâche elle-même). Si la tâche suspendue attend aussi un délai, il faudra que la suspension soit enlevée et le délai expirépour que la tâche reparte.

� OSTaskResume() fait redémarrer la tâche

Suppression d’une tâche

� La suppression d’une tâche contient deux étapes :� Effacer la tâche dans la queue des tâches et dans toutes les queues

d’attente (plus de lancement par l’Ordonnanceur)� Désaffectation du TCB et de la pile de la tâche (libération d’espace

mémoire)� Supprimer une tâche signifie la rendre inactive (« Dormant »)� Le code que la tâche a exécuté n’est pas supprimé, l’Ordonnanceur ne

la planifie plus en exécution� La routine µCOS de suppression d’une tâche de priorité prio est :

OSTaskDel(INT8U prio)� La routine µCOS appelée par une tâche pour demander à une autre

tâche de se supprimer elle-même est OSTaskDelReq(INT8U prio), elle rend la suppression plus sécuritaire

� Il y a des cas où la suppression d’une tâche peut être catastrophique (certains OS fournissent des sécurités pour empêcher la destruction d’une tâche quand elle est dans une zone critique, taskSafe() dans VxWOrks par ex.)

48

Suppression d’une tâche

� Il est en général très difficile de savoir si une destruction de tâche est sécuritaire ou pas. Si on supprime une tâche qui a un accès exclusif à une ressource partagée, celle-ci ne sera jamais relâchée. Par conséquent une tâche ne doit pas effacer n’imorte quelle autre tâche si ce n’est elle-même.

� Les seules ressources automatiquement récupérées par le RTOS sont le TCB et la pile de la tâche.

� Les tâches sont responsables de leur propre nettoyage :� Libérer la mémoire� Libérer les ressources partagées� Fermer les fichiers ouverts

Retarder une tâche

� Un RTOS permet qu’une tâche soit retardée d’un nombre spécifique de « ticks » d’horloge système

� C’est une opération utile pour une fonction périodique ou pour la surveillance cyclique d’une ressource matérielle.

� Suspension : OSTaskSuspend(INT8U prio)� Reprise : OSTaskResume(INT8 prio)� Retarder une tâche d’un nombre de ticks :

OSTimeDly(ticks)� Retarder une tâche pour une durée de Heures: Minutes;

Secondes: Millisecondes OSTimeDlyHMSM(H,M,S,M)

49

Le Port d’émulation sur PC pour MicroCOS

� Ce port permet d’émuler le fonctionnement du RTOS sur une fenêtre de commande windows.

Timer multimédia du PC

Threads windows (100 ticks/s)

Port WIN32 (Linux - Win32)

L’environnement de travail (Visual C)

� Visual C donne l’environnement de développement � INCLUDE� LIB� VSINSTALLDIR� PATH (donne les chemins d’accès aux exécutables, notamment

vsvars32.bat)

� L’ensemble SDK adapté à l’OS (XP, 2000, etc..) est nécessaire pour la gestion des fonctions Windows, ce qui permet la gestion des fonctions classiques (printf, etc….)

50

L’environnement de travail (Utilisateur)

� Le répertoire utilisateur (généralement ucos_v252\SOFTWARE\uCOS-II\Work\User) contient les fichiers includes.h (qui doit être indiqué dans le fichier à compiler) et oscfg.h de l’environnement uCOS ainsi qu’un « makefile » permettant la liaison avec les différents répertoires de l’environnement uCOS.

� Exemple de makefile (fichier pdf)� La commande nmake permet la compilation et la création de

l’exécutable.� Le répertoire général de uCOS (par exemple

ucos_v252\SOFTWARE\uCOS-II\SOURCE)� Le répertoire du port cible (par exemple

ucos_v252\SOFTWARE\uCOS-II\Ports\80x86\WIN32\VC\src)

Environnement de travail (suite)

Répertoire de travail Répertoire du port Répertoire des sources uCOS-II

Includes.h

OS_cfg.h

Makefile

Oscpu.h

Os_cpu_c.c

pc.c

pc.h

OS_CORE.COS_FLAG.COS_MBOX.COS_MEM.COS_MUTEX.COS_Q.COS_SEM.COS_TASK.COS_TIME.CuCOS_II.CuCOS_II.H

Test.C

51

Un exemple avec la gestion de deux tâches

� But : Créer deux tâches concurrentes (Tache 1 et Tache 2)� La pile associée à chaque tâche fera 1024 octets� L’organigramme général est le suivant (Fichier PDF) :

Déclarations générales de l’environnement(Include, variables, piles statiques, fonctions)

Main()Initialisation OSInit()Création de la tâche initiale (1) OSTaskCreate()Démarrage du multi-tâches (OSStart()

Tache 1()Message initialLancement de la tâche statistique OSStatInit()Création de la tâche 2Délai de remise en service OSDly()

Tache 2()MessageDélai de remise en service OSDly()Arret général (kbhit())

Fenêtre de visualisation de l’exemple

52

Port WIN32 – Gestion des interruptions

� Initialisation de l’ISR : PC_IntVectSet(n_IT, Votre_ISR)� n_IT : numéro d’interruption (0 à 7)� Votre_ISR : Fonction d’interruption

� Le répertoire utils (du port WIN32 – 80x86) contient un générateur d’IRQ (irQgenerator.c et irQgenerator.exe) qui peut être utilisé en fonction ou en exécutable (sous réserve que uCOS soit démarré). Dans ce cas la commande :� Prompt_DOS:> irQgenerator 4 (génère une interruption de niveau 4

qui est émulée au niveau de uCOS).

uCOS-II – Gestion des sémaphores

� OS_EVENT *Nom_semaphore;� Nom_semaphore=OSSemCreate(N); (N=valeur initiale, 0

pour bloquage initial, 1 normal, N pour type compteur)� OSSemAccept(Nom_semaphore);

� Obtention du sémaphore (IRQ avant POST)

� OSSemPost(Nom_semaphore);� Libération du sémaphore

� OSSemPend(Nom_semaphore):� Attente pour une tâche (sauf IRQ) du sémaphore

53

La gestion des « mailbox »

� La gestion initiale des queues (et des mailboxes) dans uCSO-II présentait un inconvénient quant au passage des valeurs (par pointeur plutôt que par valeur). Cet inconvénient a été corrigé (par J. Chevalier – EcolePolytechnique de Montréal) et nécessite quelques modifications de fichier (voir la note à ce sujet dans les TP).

Procédures (modifiées par rapport uCOS original)

� OSMboxCreate(void *start, INT32U dsize)� Start = adresse pour le stockage du message (unique)

� OSMboxPost (OS_EVENT *pevent, void *start)� pevent = pointeur sur la mbox créée, start=adresse de la donnée

envoyée, la valeur de retour est un code d’erreur INT8U

� OSMboxPend(OS_EVENT *pevent, void *start, INT16U timeout)� pevent = pointeur sur la mbox créée, start=adresse de la donnée à

recevoir, la valeur de retour est un code d’erreur INT8U, timeout permet de sortir du pend selon un timeout (si 0 pas de timeout).

54

Mailbox (exemples)

err=OSMboxPost(Mbox, &dat); // la déclaration de variable est (msg dat;)

OSInit();…..Mbox = OSMboxCreate(&Mbx,sizeof(msg)); ….OSStart();

err=OSMboxPend(Mbox, &in, 0); // (msg in;)

DéclarationOS_EVENT *Mbox; // Boite aux lettres (1 seule lettre) for Tasks #4 and #6msg* Mbx; // msg est la structure à passer, type de base ou struct

La gestion des queues (FIFO – LIFO)

� La gestion initiale des queues (et des mailboxes) dans uCSO-II présentait un inconvénient quant au passage des valeurs (par pointeur plutôt que par valeur). Cet inconvénient a été corrigé (par J. Chevalier – EcolePolytechnique de Montréal) et nécessite quelques modifications de fichier (voir la note à ce sujet dans les TP).

55

Structure du bloc de contrôle

OS_EVENT *MsgQueue; /* Bloc de conrole*/void *MsgQueueTbl[256]; // Table de données

MsgQueue = OSQCreate(&MsgQueueTbl[0], 256,sizeof(donnees))

typedef struct {unsigned short value;unsigned char device;

}msg;Msg donnees;

Char donnees;

Le buffer tournant

Messe=« Calcul d’une valeur »;err=OSQPost(MsgQueue, (void *)&messe); //Dépose d’une valeur

In: type de valeur défini pour la FIFO;err = OSQPend(MsgQueue, (void *)&in, 0); // Récupération de la valeur pointée par (OSQOut)//