Toute la vérité sur RTOS. Article # 8. Nucleus SE: conception interne et déploiement

Cet article poursuit l'examen de Nucleus SE.

Les services

Nucleus SE fournit un ensemble d'outils que l'on peut attendre de n'importe quel RTOS.
Premièrement, Nucleus SE contient un planificateur assez simple, cependant, grâce aux quatre options disponibles, il offre une flexibilité. Le planificateur prend en charge les algorithmes Run to Completion, Round Robin, Carousel, Time Slice et Priority.

L'API Nucleus SE comprend environ 50 appels d'utilitaires qui permettent aux développeurs d'accéder à la gestion des tâches, aux sections de mémoire, aux signaux, aux groupes d'indicateurs d'événements, aux sémaphores, aux boîtes aux lettres, aux files d'attente, aux pipelines, à l'heure système, aux temporisateurs d'application et aux diagnostics.

Outre la planification simple des tâches, Nucleus SE (facultatif) prend en charge la pause des tâches. Cette fonction peut être «propre» (par exemple, à la suite d'un appel d'API de service de suspension défini explicitement), elle peut être une fonction «veille» (lorsqu'une tâche est suspendue pendant une certaine période de temps), ou elle peut être le résultat d'un autre appel d'API dans lequel la tâche est bloquée (la suspension dite "conditionnelle"), en attente d'accès à la ressource noyau. Contrairement à Nucleus RTOS, Nucleus SE ne prend pas en charge les délais d'expiration lors du blocage des appels d'API.

La variété des mécanismes présentés vous permet de choisir parmi une hiérarchie de moyens de synchronisation et de communication entre les tâches: des sémaphores aux signaux, drapeaux d'événements, boîtes aux lettres et files d'attente / pipelines.

Articles précédents de la série:
Article # 7. Nucleus SE: Introduction
Article # 6. Autres services RTOS
Article # 5. Interaction et synchronisation des tâches
Article # 4. Tâches, changement de contexte et interruptions
Article # 3. Tâches et planification
Article # 2. RTOS: Structure et mode temps réel
Article # 1. RTOS: introduction.

Vérification des paramètres

Lors du choix de la configuration NUSE_API_PARAMETER_CHECKING , le code de vérification des paramètres est inclus dans toutes les fonctions de l'API: vérification des pointeurs nuls, des index d'objets, etc. Comme il s'agit d'un code supplémentaire qui nécessite de la mémoire supplémentaire, il serait sage d'activer cette fonction pendant le débogage, mais de la désactiver dans l'assembly de publication.

La configuration

Nucleus SE a une structure flexible, ce qui nous donne deux points positifs. D'une part, le noyau peut avoir une configuration à grain fin qui satisfait les tâches d'une application particulière en raison de la configuration simple des fonctionnalités disponibles et de la gestion simple de l'utilisation de la mémoire. En revanche, le code Nucleus SE est facilement transportable entre les deux outils et entre les processeurs.

Conventions de dénomination

Étant donné que la clarté et la facilité de compréhension étaient importantes lors du développement de Nucleus SE, les conventions de dénomination ont été soigneusement pensées. Chaque caractère du code est préfixé par NUSE_. Tout ce qui suit ce préfixe obéit à un ensemble de règles simples.

Appels API

Chaque fonction d'appel d'API dans Nucleus SE commence par NUSE_, qui est presque toujours suivi d'un type d'objet, suivi d'une opération à casse mixte, séparée par des traits de soulignement. Un exemple est la fonction NUSE_Queue_Send () , qui met les messages en file d'attente .

Autres fonctions et variables

Les autres fonctions et variables (globales) du code Nucleus SE utilisent également le préfixe NUSE_, mais le reste du nom n'a pas toujours de «structure». Ce n'est pas important pour l'utilisateur moyen du noyau, car il aura suffisamment de fonctions API.

Symboles de configuration

Étant donné que Nucleus SE est configuré avec des caractères #define, ils obéissent également aux conventions de dénomination. Ils ne sont écrits qu'en majuscules. Les noms des activateurs des appels d'API sont les mêmes que les noms des fonctions et sont également écrits en majuscules, par exemple, NUSE_QUEUE_SEND.

Autres caractères #define

Tous les autres caractères #define (par exemple, les paramètres d'appel d'API et les valeurs d'état de retour) qui peuvent être utilisés par le code d'application obéissent aux mêmes règles, ils commencent par NUSE_ et sont écrits en majuscules. Par exemple, NUSE_SUCCESS.

Structures de données

Tous les RTOS ont un ensemble de structures de données qui décrivent les objets du noyau. Dans la plupart des implémentations, ce sont des structures de données en C qui forment des listes liées, souvent avec une communication bidirectionnelle et même circulaire. C'est logique, car les données importantes sont commodément encapsulées et les éléments de liste peuvent être ajoutés ou supprimés à mesure que les objets sont créés et supprimés.

Dans Nucleus SE, tous les objets sont statiques, donc organiser toutes les structures de données de ces objets dans une liste simple était la solution évidente. Cela réduit le volume et la complexité des pointeurs avant et arrière. Cependant, j'ai décidé de renforcer l'optimisation du système et j'ai refusé d'utiliser les structures du tout. Dans Nucleus SE, toutes les données des objets du noyau sont représentées par plusieurs tableaux simples (également appelés tables) de différents types, un ou plusieurs pour chaque type d'objet. Plusieurs arguments plaident en faveur de cette décision:

• Nucleus SE a été conçu dans un souci de compatibilité avec les structures 8 bits. La plupart des petits processeurs ne disposent pas d'outils optimaux pour implémenter des structures de données dans un compilateur C. Les tableaux simples sont beaucoup plus efficaces.
• Étant donné que le nombre maximal autorisé d'objets de chaque type est de 16 et que l'accès aux éléments de chaque tableau nécessite quatre bits, un octet est souvent utilisé. C'est plus efficace qu'une adresse, qui prend généralement 16 ou 32 bits.
• Les données d'objets permanents doivent être stockées dans la ROM et non copiées dans la RAM. Comme la structure ne peut pas être divisée entre ROM et RAM (en C portable traditionnel), chaque type d'objet peut avoir deux structures, ce qui est trop complexe. Dans Nucleus SE, les tableaux de description d'objet peuvent être trouvés à la fois dans la ROM et la RAM, selon les besoins.
• En raison de la configurabilité élevée de Nucleus SE («évolutivité ultra-élevée»), certaines données de description d'objet peuvent être facultatives, selon les outils sélectionnés. Cela conduit à une utilisation généralisée de la compilation conditionnelle. Une définition structurelle avec des directives de compilation conditionnelle intégrées est très difficile à comprendre. Le contrôle de l'instanciation de tableaux individuels à l'aide de cette méthode est à son tour assez facile à comprendre.

Tous les tableaux de données d'objets sont soumis à la convention de dénomination hiérarchique mentionnée ci-dessus. Ainsi, il est assez facile de comprendre quelles tables sont logiquement liées.

Différences clés par rapport à Nucleus RTOS

Bien que Nucleus SE ait été conçu avec un haut degré de compatibilité avec Nucleus RTOS, certaines différences petites et plus importantes n'ont pas pu être évitées. Ils seront décrits en détail dans les articles pertinents, et une brève description est donnée ci-dessous.

Données d'objet

Dans Nucleus RTOS, les objets sont créés et supprimés sur demande. Dans Nucleus SE, tous les objets sont créés statiquement et déterminés lors de l'assemblage.

Nombre d'objets

Nucleus RTOS prend en charge un nombre indéfini d'objets de chaque type. Nucleus SE prend en charge un maximum de seize objets de chaque type.

Noms d'objets

Nucleus RTOS vous permet d'affecter des types de texte à certains types d'objets pouvant être utilisés pour le débogage. Nucleus SE ne dispose pas de cette fonctionnalité.

Mécanisme de verrouillage des tâches

Le mécanisme de blocage des tâches avec un appel d'API dans Nucleus SE est assez simple. Lorsqu'une ressource est libérée, toutes les tâches en attente sont reprises et rivalisent (à l'aide du planificateur de tâches) pour les ressources. Les tâches perdues sont à nouveau suspendues (bloquées). Dans Nucleus RTOS, le mécanisme est plus complexe, seules les tâches importantes s'y poursuivent, ce qui est plus efficace.

Délai d'attente de l'API

Lors de l'appel de l'API de blocage, Nucleus RTOS permet au développeur de spécifier un délai d'expiration après lequel l'appel reprendra même si la ressource n'est pas libérée. Nucleus SE ne dispose pas de cette fonctionnalité.

Planification des tâches

Le planificateur Nucleus RTOS est flexible, efficace et bien défini. Nucleus SE propose un ensemble de planificateurs, chacun étant suffisamment simple et efficace pour un nombre réduit de tâches prises en charge: de 1 à 16.

Priorités des tâches

Un système utilisant Nucleus RTOS peut avoir un nombre arbitraire de tâches qui peuvent être affectées à l'un des 256 niveaux de priorité, tandis que plusieurs tâches peuvent avoir un niveau de priorité. Les niveaux de priorité des tâches peuvent également changer au moment de l'exécution. Dans Nucleus SE, si un planificateur de priorité est sélectionné, chaque tâche doit avoir un niveau de priorité unique qui ne peut pas être modifié dynamiquement. Il ne peut y avoir qu'un seul niveau de priorité par tâche.

Interruption de la manipulation

Nucleus RTOS prend en charge l'architecture sophistiquée d'un gestionnaire d'interruptions à deux niveaux qui permet une interopérabilité efficace du gestionnaire d'interruptions et des services du noyau. Nucleus SE utilise une approche similaire qui prend en charge à la fois des gestionnaires d'interruptions non kernel simples (interruptions non gérées) et des gestionnaires d'interruptions pleinement sensibles au contexte qui peuvent utiliser des appels d'API (interruptions gérées).

Pilotes de périphériques

Nucleus RTOS possède une architecture de pilote de périphérique bien conçue. Nucleus SE ne possède pas une telle architecture, laissant au développeur la tâche de répartir le contrôle des périphériques entre les tâches et le code du gestionnaire d'interruption.

Distribution de Nucleus SE

Les codes source de Nucleus SE seront publiés au fur et à mesure du développement de cette série d'articles. Les fichiers disponibles seront disponibles sur demande par e-mail. Vers la fin de la série d'articles, un référentiel sera créé pour télécharger tous les fichiers publiés.