PICos & PICos18 : Internals Ce qui suit à pour objectif de présenter l'architecture interne de PICOS, afin de permettre aux développeurs de mieux comprendre les interractions entre le noyau et les applications, pour faciler le débuggage, et enfin pour favoriser la participation au développement de nouvelles fonctionnalités de ce noyau. En effet, ce noyau ne répond pour le moment qu'à une partie de l'ensemble des normes OSEK. Il est amené à évoluer au fil du temps, tout comme cette rubrique...

Dans le début des années 90, des constructeurs automobiles européens cherchent à définir un noyau temps-réel pour systèmes embarqués. Des constructeurs allemands comme BMW, Bosch, Opel et Siemens créent alors la norme OSEK (Offene Systeme und deren Schnittstellen fur die Elektronik im Kraftfahrzeug). De leur côté, les sociétés françaises comme PSA et Renault développent un système similaire batisé VDX (Vehicle Distributed eXecutive).
Finalement les projets finirent par fusionner pour ne devenir qu'une seule norme : la norme OSEK / VDX.

Afin de développer le noyau PICOS18 conformément à cette norme, je me suis basé sur les 2 documents suivants :

La norme OSEK / VDX 2.1 révision 1

Le livre de Joseph LEMIEUX des éditions CMPbooks. Ce livre détaille la réalisation d'un jeux de cartes sur le noyau OsekWorks de la société WindRiver.

La norme OSEK / VDX repose sur 4 sous-ensembles :

• OS (Operating System)
• COM (COMmunication)
• NM (Network Management)
• OIL (OSEK Implementation Language)

... et bientôt sur 3 sous-ensembles supplémentaires :

• ORTI (OSEK/VDX Real-Time Interface)
• OSEK-Time (OSEK/VDX Time-Triggered Operating System)
• OSEK-FTC (OSEK/VDX Fault Tolerant Communication)

Les versions actuelles de PICos & PICos18 ne respectent que la norme OS de OSEK.
L'objectif premier est donc de répondre parfaitment à cette norme, puis d'intégrer les moyens de communications définis par COM et enfin ajouter à PICOS des services réseaux conformément à la norme NM.

Le noyau PICos présente les performances suivantes :

Ces performances sont suffisantes pour le développements d'applications sur PIC. Le noyau, les services et la pile logicielle ne monopolisent que la première banque de RAM. Le noyau et les services prennent moins de 5 Ko de mémoire de code.

Le nombre de tâches gérables par le scheduler est de 16, ce qui n'est pas une grande limitation en soit. Créer une application avec plus de 16 tâches synchronisées et dialogant entre elles n'est pas une chose aisée ! Découper une application en 20 ou 30 tâches distinctes n'est pas forcément une bonne idée, et il vaut mieux concentrer les actions similaires au sein de même tâche (affichage sur LCD, gestion des communication, traitement du signal,..).

Enfin le temps de latence permet de belles performances pour des applications critiques. En effet le temps de latence du scheduler (temps prie par le noyau afin de déterminer la prochaine tâche active, puis de l'activer pour finalement arriver dans la tâche) est meilleure que celui de QNX sur un 386EX à 33 MHz !!

Toutes les informations concernant les tâches de l'application sont contenues sur une seule ligne de donnée en RAM. Cette zone de la RAM réservée au noyau est appelée la zone de description de tâches en RAM.

Sur la partie de droite, on retourve 8 octets (1 octet par tâche), dont 3 sont non nuls. L'application comporte donc 3 tâches. Ces tâches sont en fait classées de gauche à droite, de la plus prioritaire à la moins prioritaire. Sur 8 bits, les 4 bits de poids forts représentent l'ID de la tâche, tandis que les points faibles représentent l'état de la tâche.
Dans cet exemple issu du tutorial, nous pouvons en déduire que :

• la tâche la moins prioritaire est la tâche 2 et son état est SUSPENDED (valeur nulle)
• la tâche la plus prioritaire est la tâche 1 et son état est READY (bit 0 actif) et RUNNING (bit 1 actif)
• une tâche de priorité intermédiaire existe avec l'ID 3 et son état est READY (bit 0 actif) et WAITED (bit 2 actif)

Sur la partie de gauche, on retouve encore 8 octets (1 octet par tâche), dont 3 sont non nuls. A chaque octet correspond la tâche décrite par le même octet dans la zone de droite. Sur 8 bits, les 3 bits de poids forts indiquent la priorité de la tâche, et les 5 bits restants représentent l'adresse du pointeur de pile hardware (STKPTR) de la tâche.

Au vu de l'image ci-dessus, nous pouvons dire que :

• la tâche 2 possède une priorité de 2 (la plus prioritaire), et STKPTR = 5
• la tâche 1 possède une priorité de 4 (la moins prioritaire), et STKPTR = 1
• la tâche 3 possède une priorité de 3 (de priorité intermédiaire), et STKPTR = 9

Remarque :
La zone du descripteur de tâche en RAM contient donc 2octets de description par tâche. Or ces octets sont rangés en mémoire de la tâche la plus prioritaire à la moins prioritaire. Or la norme OSEK ne précaunise pas de pouvoir manipuler la priorité des tâches en fonctionnement. Il ne devrait alors pas être nécessaire de garder en mémoire la priorité de chaque tâche ! Toutefois la norme OSEK stipule l'emploi d'un méchanisme de CEILING PROTOCOL dans le cas d'accès aux ressources (entrée en région critique), ce qui conduit à des modifications temporaire des priorités...

Afin de pouvoir construire la zone de description des tâches en RAM (construction effectuée par le noyau), il faut nécessairement déclarer et paramétrer les tâches de l'application dans une zone de code : c'est la zone de description des tâches en ROM (fichier taskdesc.c).

/***************************************************** 
 * ------------- TASK DESCRIPTOR  SECTION ------------ 
 ****************************************************/ 
#pragma  romdata DESC=0x50 


/***************************************************** 
 * -------------------  Led_ON task ------------------ 
 ****************************************************/  
rom_desc_tsk rom_desc_led_ON = 
{ 0x04,      /* prioinit from 0 to 7 */
  0x04,      /* stacksize  in word [32 bits] */
  0x1000,    /* adr_tsk in 16 bits */ 
  0x00,      /* state at init phase  */ 
  0x01,      /* id_tsk from 1 to 8 */ 
  0x0100     /* ctx_tsk in 16 bits */ 
};

Cet exemple est issu du tutorial. Il déclare une tâche Led_ON dont l'ID est 1. C'est la déclaration de la tâche la moins prioritaire vue précédemment.
Nous pouvons remarquer que les informations concordent avec celles de la zone de description en RAM :

• priorité de 4
• taille de la pile de 4 (3 appels de fonctions imbriqués + 1 pour les appels systèmes)
• point d'entrée de la tâche (en ROM)
• état de la tâche à l'init (si vous souhaitez que la tâche démarre à READY, RUNNING, WAITED,...)
• ID de la tâche
• adresse de la zone de RAM de la tâche (pour assurer la sauvegarde de contexte lors de permutation de tâche)

En parcourant cette structure pour chaque tâche, le noyau place l'adresse du point d'entrée de la tâche directement dans la zone de la pile hardware affectée à la tâche. Pour passer du noyau à la prochaine tâche, le noyau place donc le pointeur de pile sur la valeur STKPTR mémorisée dans la zone de descrition de tâches en RAM, puis appel l'instruction RETURN.

Le noyau PICOS18 est découpé en plusieurs blocs :

• Le coeur du noyau (Init + Scheduler + Task Manager) qui a la responsabilité de gérer les tâches de l'application et donc de déterminer la prochaine tâche active en fonction de l'état et la priorité de chaque tâche.
  
• Le gestionnaire d'alarmes et de compteurs (Alarm Manager). Proche du coeur du noyau, il répond à l'interruption du TIMER0 afin de mettre à jour pérodiquement les alarmes et compteurs associées aux tâches.
• Les Hook routines sont proches du coeur du noyau et permettent à l'utilisateur de dérouter le déroulement normale du noyau de façon à prendre temporairement le contrôle du système.
• Le gestionnaire de tâches (Process Manager) est un service du noyau dont le rôle est d'offrir à l'application les fonctions nécessaires à la gestion des états (changer l'état d'une tâche, chaîner des tâches, activer une tâche,...).
• Le gestionnaire d'évènement (Event Manager) est un service du noyau dont le rôle est d'offrir à l'application les fonctions nécessaires à la gestion des évènements d'une tâche (mise en attente sur un évènement, effacer un évènement,...).
• Le gestionnaire d'interruption (INT Manager) est un service du noyau dont le rôle est d'offrir à l'application les fonctions nécessaires à l'activation et la désactivation des interruptions du systèmes.

Concernant le coeur du noyau :

Tout le code relatif au coeur du noyau est rassemblé dans le fichier kernel.asm.

Comme nous l'avons vu précédemment, la déclaration des tâches se fait dans une zone de description des tâches en ROM (fichier taskdesc.c). La première effectuée par le noyau lors de la phase d'INIT est donc de parser cette zone en vu d'établir la liste des tâches de l'application.

Ensuite le SCHEDULER entre en action afin de déterminer la prochaine tâche à exécuter. L'algorithme du SCHEDULER est simple : la prochaine tâche à exécuter est la tâche prête la plus prioritaire. Il n'y a aucun algorithme de vieillissement des tâches qui consisterait à prendre en compte le temps de fonctionnement des tâches dans leurs gestions.

Enfin l'action du coeur du noyau se termine par la mise en oeuvre du TASK MANAGER. Celui-ci n'a rien à voir avec le PROCESS MANAGER. Son action se borne à restituer ou sauvegarder le contexte et la zone de pile de chaque tâche. Ceci se fait au moment du basculement d'une tâche ou bien lors du saut dans une nouvelle tâche.

A suivre ...

A suivre ...

A suivre ...

A suivre ...

A suivre ...

A suivre ...