Ordonnancement temps réel sur
système embarqué

• I. Prise en main de l'environnement de développement
  • I.1Les étapes d'une chaîne de compilation - déploiement
  • I.2 Le mode target master
  • I.3 Le mode target slave et protocle de communication
• II L'ordonnancement RMS du système RTEMS
  • II.1 Mapping RMS -> RTEMS 
  • II.2 Exercice de base RMS (application directe du motif)
  • II.3 Développement en environnement croisé
• III. Configuration d'un lot de tâches et traitement d'erreur.
• IV. Gestion de l'inversion de priorité

Ce TP illustre le processus de développement d'une application temps réel embarquée.
Nous allons écrire et tester des programmes en utilisant le système RTEMS embarqué sur une plate-forme Spif développée au département INFRES de l'ENST.

I. Prise en main de l'environnement de développement

1. Compilation du code pour MPC860 et édition de liens entre RTEMS et l'application. (sur xuri) cf consigne sur la page de description de la plateforme xuri)
   
2. Préparation de l'image binaire pour le déploiement.(sur xuri)
   
3. Connection à la cible si disponible (il faudra vérifier la disponibilité de la cible).
   
4. Chargement et lancement. (mode slave ou master pour la cible)
   
5. Récupération de la sortie dans un fichier texte
6. Réinitialisation de la plateforme pour libérer la carte

Mode cible en mode Esclave

Mode cible en Maître

II L'ordonnancement RMS du système RTEMS

II.1 Mapping RMS -> RTEMS 

1. Vous pouvez consulter une documentation sur le fonctionnement du gestionnaire RMS de RTEMS en cliquant ici.
2. Nous donnons ci-dessous le design pattern permettant d'implémenter une tâche RMS sour RTEMS à partir de l'API RTEMS (en utilisant les procédures rtems_rate_monotonic_create et rtems_rate_monotonic_period) :
   

   Voici ce qu'il se passe lors des appels successifs à rtems_rate_monotonic_period  en supposant que la tâche courante est la seule à s'exécuter :
   

   Appel 1 à t0 (comportement spécifique d'initialisation) : le service d'attente est initialisé de sorte à réveiller la tâche appelant la fonction au prochain instant correspond à une date de la forme  t0 +k*T, k entier. Appel 2 : Suite à l'exécution de la tâche dans sa première période si la tâche ne consomme pas son WCET mais C1 unités de temps , alors la tâche est bloquée pendant T - C1, Appel 3 : Si on consomme C2, la tâche est bloquée pendant T - C2, Appel 4 : Si on réalise l'appel au service d'attente de la prochaine activation à une date supérieure à t0+ 4T, alors l'appel demade un réveil pour une activation dépassée et la fonction retourne une erreur (code TIMEOUT).

   Initialisation du descripteur de RMS pour la tâche courante Implantation du comportement périodique via une boucle exécutant la séquence d'action suivante : le traitement à répéter (la fonction de la tâche) Passage dans l'état bloqué jusqu'à l'activation suivant

   #define T 10 ... rtems_rate_monotonic_create (nom, &valeur); init=rtems_rate_monotonic_period(valeur, T); while (1) { Etat = rtems_rate_monotonic_period(valeur, T); if (Etat == RTEMS_TIMEOUT) break ; /***** Ici se trouve le code a executer : on va consommer successivement C1, C2, C3 unites de temps pendant la periode *****/ } /***** Echéance dépassée *****/

   
   
   
3. La fonction de mise en attente rtems_rate_monotonic_period(valeur, T) possède une procédure de signalement du cas de défaillance temporelle suivant:
   
   Si la tâche courante n'a pas terminé l'exécution du traitement périodique au sein de la période en cours, alors la fonction retourne un code d'erreur spécifique.
   
   En interne, cette détection se fait à travers un timer devant expirer à la date T. Cependant, si la tâche termine son traitement avant l'échéance, alors  ce timer est automatiquement désactivé par RTEMS.
   
   Ainsi, l'expiration du timer  indique que la tâche n'a pas réussi à respecter son echéance. Cette information sert à déterminer le code de retour de la fonction  
   
   
4. Le détail des services utilisés dans le pattern se trouve aux pages suivantes (avec exemples en code C) :
   cliquez ici. et ici. (c'est la doc. pour compléter task.c !),

5. La documentation générale sur les fonctions de tasking de RTEMS est accessible en appuyant ici.

II.2 Exercice de base RMS (application directe du motif)

Nous vous conseillons dans un premier temps de vous limiter à un lot à trois tâches (avec par exemple les paramètres suivants : T1 = 500, T2 = 800, T3 = 1000 avec WCET1 = 50, WCET2 = 100, WCET3 = 200.

Dans init.c, on trouve successivement :

• Promotion de la tâche main à une priorité importante pour empêcher sa préemption par les tâches qu'elle crée lors de l'initialisation du lot de tâche RMS-RTEMS :

  rtems_task_set_priority(RTEMS_SELF, 10, &the_priority);
  

• création des tâches périodiques dans un intervalle de priorités inférieures à celle de  main

   status = rtems_task_create(...)

• Question :
  Sachant que plus une tâche est prioritaire, plus son indice de priroité est faible sous RTEMS, dîtes en quoi l'attribution de priorités faite dans le code est correcte.

II.3 Production et déploiement pour spif/xuri.

A Faire :

Nous allons maintenant utiliser cette machine xuri.enst.fr pour exécuter l'exemple de base sur la machine cible, la carte Spif.
C'est sur xuri que l'on va :

1. Récupérer les fichiers contenus dans exo1.tar ,
2. Compléter les fichiers sources init.c et task.c pour mettre en oeuvre le design pattern implémentant les tâches périodiques RMS. Vous pourrez instancier les structures Periods[] et Task_computation[] pour des lots de tâches de 1 à 9 tâches (cf déclaration des tableaux)
   
3. Utiliser les outils de développement croisé pour créer l'exécutable, le télécharger puis l'exécuter sur la cible,

Un corrigé de cet exercice se trouve ici : exo1-corr.tar

III. Configuration d'un lot de tâches et traitement d'erreur.

IV. Gestion de l'inversion de priorité

Nous considérons trois tâches TA1, TA2 et TA3 telles que deux d'entre elles accèdent à une section critique protégée par un sémarphore appelé SM1. Pour faciliter l'observation du phénomène d'inversion, la section critique couvre l'intégralité du traitement périodique. Les paramètres des tâches sont les suivants.

Détaillez le scénario menant à l'inversion de priorités (pour quelles tâches ? A quel moment peut s'en apercevoir (tenir compte des services founis par RTEMS) ?

(Indice: l'inversion de priorité concerne les tâches TA1 et TA3)

Question 1:

Utilisez la correction du premier exercice comme point de départ.

Intégrez le sémaphore permettant de protéger les sections critiques dans TA1 et TA3.

Remarques :

• Le comportement des tâches peut être spécialisé en testant l'indice Task_num au sein de la boucle représentant le corps de la tâche RMS-RTEMS
  
• Rappel la documentation sur les sémaphores se trouve au chapitre 9 du "User Guide Rtems 4.7" ici.

• Attention :
  • vérifier la présence de SEMAPHORE dans la liste des MANAGERS spécifiés dans le Makefile.
  • Vous pouvez initialiser vos sémaphore par les options suivantes dans cet exercice (rappel : pas de gestion des priorité pour le sémaphore) :

      RTEMS_DEFAULT_ATTRIBUTES, RTEMS_NO_PRIORITY,
    

Question 2:

Pour éviter ce dysfonctionnement, il faut configurer le sémaphore pour qu'il supporte une forme d'héritage de priorité. On modifie alors l'attribut du sémaphore SM1 pour le mettre à RTEMS_INHERIT_PRIORITY. Quel scénario d'exécution doit être observé ?

Faire cette modification

Remarques :

• Si vous souhaiter superposer les options de configuration A, B et C lors de l'initialisation d'un sémaphore, alors vous devez utiliser l'expression A | B | C pour le paramétre attribute_set.

• ATTENTION lisez la spécification des options RTEMS pour comprendre le scénario d'exécution effectivement instancié.