Toute la vérité sur RTOS. Article # 32. Migration de Nucleus SE: fonctionnalités et compatibilité non réalisées

La principale exigence pour le développement de Nucleus SE était un haut degré de compatibilité avec le principal produit Mentor RTOS - Nucleus RTOS. Nucleus SE prend en charge une certaine partie des fonctionnalités de Nucleus RTOS, qui a été discutée à plusieurs reprises dans les articles précédents, mais dans cet article, j'essaierai de rassembler toutes les principales différences en un seul endroit. Cet article a été conçu comme une référence rapide pour tous ceux qui vont passer d'un noyau à un autre ou qui sont en train de choisir un noyau pour un projet spécifique.



En plus de fonctionnalités limitées ou simplifiées, par rapport à Nucleus RTOS, Nucleus SE a également été conçu en mettant l'accent sur l'optimisation de l'utilisation de la mémoire avec de nombreuses options de personnalisation. Une partie importante de cette approche est l'évolutivité. De nombreuses fonctionnalités de la fonctionnalité du noyau peuvent être activées ou désactivées si nécessaire. De toute évidence, la désactivation des fonctionnalités dans une implémentation particulière augmente son incompatibilité avec Nucleus RTOS.

Dans Nucleus RTOS, un système peut être créé avec un nombre indéterminé d'objets du noyau; la seule limitation ici est la quantité de ressources disponibles (c'est-à-dire la mémoire). Nucleus SE a une limite de seize objets de chaque type; le système peut avoir de une à seize tâches et de zéro à seize objets de chaque type (boîtes aux lettres, files d'attente, etc.). Malgré le fait que cette limite peut être augmentée, des efforts considérables seront nécessaires, car Nucleus SE utilise largement la possibilité de stocker l'index d'un objet dans un quartet (quatre bits). De plus, avec plus de seize tâches, le planificateur de priorités risque de devenir très inefficace. Une application dont les fonctionnalités souffrent sérieusement de ces limitations n'est pas adaptée à Nucleus SE, dans ce cas Nucleus RTOS est un choix beaucoup plus approprié.

Planificateur

Comme tous les cœurs modernes en temps réel, Nucleus RTOS dispose d'un planificateur très flexible qui fournit plusieurs niveaux de priorité (avec un nombre indéterminé de tâches à chaque niveau de priorité), ainsi que la possibilité de sélectionner le planificateur Round Robin et Time Slice. Nucleus SE est beaucoup plus simple et propose quatre planificateurs qui doivent être sélectionnés au moment de la génération: Run to Completion, Round Robin, Time Slice et Priority. Il est impossible de combiner différents ordonnanceurs (c'est-à-dire qu'il n'y a pas d'ordonnanceur composite). Par exemple, vous ne pouvez pas sélectionner une combinaison de planificateurs de tranches de temps et de priorités. De plus, le planificateur de priorités vous permet d'affecter une seule tâche à chaque niveau de priorité, c'est-à-dire qu'il y a autant de niveaux de priorité qu'il y a de tâches. La priorité de la tâche est définie lors de la génération et ne change plus (comme le créneau horaire si le planificateur de tranche de temps est sélectionné).

Appels API

Interface de programmation d'application (API) - la «face» visible du système d'exploitation. Sans surprise, c'est là que les différences entre Nucleus RTOS et Nucleus SE sont les plus évidentes.

L'API Nucleus SE est différente de l'API Nucleus RTOS. Cependant, l'API Nucleus SE a été soigneusement conçue pour pouvoir être transférée vers le fragment d'API Nucleus RTOS. Les détenteurs de Nucleus RTOS sous licence peuvent obtenir un «shell» (un fichier d'en-tête contenant des macros #define ) qui effectuera le transfert presque directement.

Du fait que l'API Nucleus SE peut être appelée un «sous-ensemble» de l'API Nucleus RTOS, il s'ensuit que certains appels d'API sont manquants. C'est vrai et c'est un résultat inévitable des critères de développement de Nucleus SE. Certains appels API n'ont tout simplement aucun sens, car ils sont associés à des fonctionnalités inexistantes; d'autres appels ont été exclus afin de simplifier la mise en œuvre de certains objets du noyau. Tout cela est décrit en détail dans les sections suivantes de cet article.

Fonctions API communes

Nucleus RTOS possède des fonctions API communes à plusieurs types différents d'objets du noyau, voire à tous les types d'objets. Certains d'entre eux ont également été implémentés dans Nucleus SE, un bon exemple d'une telle fonction est réinitialisé. Les autres fonctions ne s'appliquent pas à l'implémentation des objets du noyau dans Nucleus SE.

Créer et supprimer

Dans Nucleus RTOS, tous les objets du noyau sont dynamiques; ils sont créés et supprimés selon les besoins. Par conséquent, il existe des appels API pour cela. Dans Nucleus SE, tous les objets sont statiques (ils sont créés lors de l'assemblage), donc ces appels d'API ne sont pas nécessaires.

Retour de pointeurs sur des objets

L'identifiant principal (descripteur) des objets du noyau dans Nucleus RTOS est un pointeur vers le bloc de contrôle d'objet, qui est attribué lors de la création de l'objet. Par conséquent, il existe également un ensemble d'appels d'API qui renvoient une liste de pointeurs vers des objets de chaque type. Étant donné que Nucleus SE utilise un index simple pour identifier les objets du noyau, de tels appels ne sont pas nécessaires. Un programme peut interroger le noyau pour savoir combien d'instances d'objets d'un type particulier sont configurées (en utilisant un appel comme NUSE_Mailbox_Count () ); si cette valeur est n , les indices des objets de ce type auront des valeurs de zéro à n-1 .

Streaming de données

Pour certains types d'objets du noyau RTOS Nucleus (tels que les boîtes aux lettres, les files d'attente et les canaux), une surcharge de l'API est fournie pour traduire les données. Cela vous permet d'envoyer des données à chaque tâche qui attend des données de l'objet. Cette possibilité a été exclue de Nucleus SE pour simplification, car l'accès aux données de ces objets est toujours effectué dans le contexte d'une tâche spécifique, ce qui libère ensuite l'objet. Par conséquent, pour implémenter la traduction, un mécanisme d'indicateur supplémentaire serait nécessaire.

Objets API de fonctionnalités uniques

De nombreux objets du noyau ont des appels d'API qui sont uniques à un type particulier d'objet et diffèrent dans Nucleus RTOS et Nucleus SE.

Les tâches

Étant donné que le planificateur Nucleus RTOS est beaucoup plus complexe que Nucleus SE, certaines fonctions API ne sont pas nécessaires:

• Modification de la position d'une interruption de tâche - non prise en charge dans Nucleus SE.
• Modifier la priorité des tâches - Dans Nucleus SE, la priorité des tâches est affectée lors de la configuration et ne peut pas être modifiée.
• Modification de la plage horaire des tâches - dans Nucleus SE, la valeur de la plage horaire est commune à toutes les tâches et est définie lors de la configuration.
• Achèvement de la tâche - Nucleus SE ne prend pas en charge l'état de tâche «terminé».

Mémoire dynamique

Comme tout est créé statiquement dans Nucleus SE, la mémoire dynamique n'est pas prise en charge (et n'est pas requise). Par conséquent, les fonctions API associées sont également inutiles.

Signaux

Nucleus RTOS prend en charge les gestionnaires de signaux, des programmes qui s'exécutent (comme les gestionnaires d'interruptions) lorsque les signaux de tâche changent. Cette fonctionnalité a été exclue de Nucleus SE, par conséquent, les appels d'API pour gérer les signaux et créer un gestionnaire de signaux ne sont pas requis.

Interruptions

Nucleus SE utilise l'approche sans interruption des interruptions, offrant simplement la possibilité de faire des appels API à partir du gestionnaire d'interruption. Par conséquent, certains appels d'API Nucleus RTOS qui spécifient comment le noyau doit gérer les interruptions ne sont pas pris en charge.

Diagnostics

Nucleus SE propose des services de diagnostic très modestes, suivant son style de développement "restreint", se limitant à la vérification (facultative) des paramètres et à la sortie du code de version du produit. Par conséquent, les appels d'API Nucleus RTOS liés à la journalisation de l'historique et à la confirmation des erreurs ne sont pas pris en charge.

Pilotes

Nucleus RTOS possède une structure de pilote formelle bien définie et plusieurs fonctions API liées à la gestion des pilotes. Nucleus SE n'a pas cette structure; par conséquent, les appels d'API correspondants ne sont pas nécessaires.

Fonctionnalité d'appel API

Certains aspects des fonctionnalités de Nucleus SE, qui sont implémentés sous une forme simplifiée, entraînent des différences par rapport à Nucleus RTOS. Certains d'entre eux affectent la façon dont les appels API sont utilisés et les services disponibles.

Délais

Lors de l'utilisation de Nucleus RTOS, il existe souvent des situations où un appel API peut suspendre une tâche en attente d'accès à une ressource: la tâche est bloquée. Une telle suspension d'une tâche peut être implicite (c'est-à-dire jusqu'à ce que la ressource devienne disponible), ou une valeur de délai d'attente peut être spécifiée. Nucleus SE fournit le blocage par les appels d'API en option, cependant, seule une suspension implicite peut être utilisée (c'est-à-dire qu'un appel peut uniquement utiliser NUSE_SUSPEND ou NUSE_NO_SUSPEND , pas une valeur de délai). Cette fonctionnalité est assez simple à ajouter à Nucleus SE.

Procédure de suspension

Lorsque plusieurs types d'objets sont créés dans Nucleus RTOS, un ordre de suspension peut être attribué. Il s'agit d'une séquence dans laquelle plusieurs tâches bloquées reprendront à mesure que les ressources deviendront disponibles. Deux options sont disponibles: FIFO, premier entré, premier sorti (premier entré, premier sorti), dans lequel les tâches sont reprises dans le même ordre dans lequel elles sont bloquées; ou par priorité, dans laquelle la tâche avec la priorité la plus élevée reprend toujours en premier. Nucleus SE n'offre pas un tel choix. Il implémente uniquement l'ordre de priorité. En fait, il est plus correct de dire l'ordre par l'index de tâche, car l'ordre de suspension peut être appliqué non seulement lors de l'utilisation du planificateur de priorité, mais aussi lors de l'utilisation des planificateurs Round Robin et Time Slice.

Fonctionnalité unique

Dans certains cas, des changements fonctionnels liés à certains types d'objets étaient nécessaires.

Gestionnaires de signaux
Comme mentionné ci-dessus, l'implémentation du signal dans Nucleus SE ne prend pas en charge les procédures de traitement du signal.

Paramètres du minuteur d'application
Le temporisateur a une durée initiale / durée initiale de fonctionnement et une durée de redémarrage et peut éventuellement exécuter une fonction définie par l'utilisateur à la fin. Cette fonctionnalité est prise en charge dans Nucleus RTOS et Nucleus SE. Cependant, contrairement à Nucleus RTOS, Nucleus SE ne permet pas de modifier les paramètres décrits ci-dessus lors de l'appel de la fonction API pour réinitialisation. De plus, dans Nucleus SE, toute la prise en charge des procédures de fin de temporisation est facultative.

Drapeaux d'événement
Nucleus RTOS a une option pour «absorber» les drapeaux d'événements. Cela signifie que les indicateurs qui correspondent aux critères définis par la tâche sont réinitialisés. Une telle fonctionnalité n'est pas prise en charge dans Nucleus SE, car la possibilité de rechercher les critères de plusieurs tâches augmente considérablement la complexité du système.

Tailles des données

Deux critères de développement pour Nucleus SE: maintenir la simplicité et minimiser l'utilisation de la mémoire, ont conduit à certaines différences de taille des éléments de données par rapport à Nucleus RTOS. Il convient de noter que Nucleus RTOS utilise généralement des données non signées , qui sont très probablement 32 bits. tandis que Nucleus SE utilise des types de données rationalisés comme U32 , U16 , U8 , etc. ( Note du traducteur: à mon avis, l'auteur a raison pour les systèmes 8 bits. Dans les systèmes modernes, les registres sont toujours 32 bits, donc couper la partie la plus ancienne consomme de la mémoire pour les cycles de code et d'horloge pour son exécution, et les données sont tout de même égales à 32 bits lorsqu'elles sont stockées dans mémoire, sinon les performances du système chuteront, donc cette approche ne donne pas de gain pour les systèmes modernes, et une perte due aux instructions ajoutées par le compilateur qui a coupé la partie la plus ancienne peut très bien. ).

Boîtes aux lettres

Dans Nucleus RTOS, une boîte aux lettres stocke un message composé de quatre éléments de données non signés. Dans Nucleus SE, une boîte aux lettres stocke un élément de données ADDR . À mon avis, les boîtes aux lettres sont souvent utilisées pour transférer une adresse (indiquant des données spécifiques) d'une tâche à l'autre.

Files d'attente

Dans Nucleus RTOS, une file d'attente traite les messages d'un ou plusieurs éléments de données non signés . La file d'attente peut également être configurée pour gérer des messages de longueur variable. Dans Nucleus SE, une file d'attente traite les messages consistant en un seul élément de données ADDR . À mon avis, les files d'attente sont utilisées de manière similaire avec les boîtes aux lettres. De plus, dans Nucleus RTOS, la taille totale de la file d'attente (c'est-à-dire le nombre total d'éléments non signés pouvant être placés dans la file d'attente) est spécifiée en tant que valeur non signée. Dans Nucleus SE, cette valeur est de type U8 . Par conséquent, une file d'attente peut contenir moins de données.

Canaux de données

Dans Nucleus RTOS, un canal traite les messages d'un ou plusieurs octets; Le canal peut également être configuré pour gérer des messages de longueur variable. Dans Nucleus SE, un canal traite les messages constitués d'un ou plusieurs éléments de données de type U8 . La taille du message est définie lors de la configuration pour chaque canal. De plus, dans Nucleus RTOS, la taille totale du canal (c'est-à-dire le nombre total d'octets pouvant être placés dans un canal) est spécifiée comme une valeur non chantée . Dans Nucleus SE, cette valeur est de type U8 et représente le nombre de messages (dans l'appel d'API NUSE_Pipe_Information () ). Par conséquent, un canal peut contenir moins de données.

Groupes de drapeaux d'événements

Dans Nucleus RTOS, un groupe d'indicateurs d'événements contient 32 indicateurs; dans Nucleus SE, leur nombre est réduit à huit. Cette taille a été choisie car les processeurs Nucleus SE cibles susceptibles de traiter efficacement les données 8 bits. Dans le même temps, la modification du nombre d'indicateurs dans les groupes d'indicateurs d'événements traités par Nucleus SE ne sera pas difficile.

Signaux

Dans Nucleus RTOS, chaque tâche a un ensemble de 32 drapeaux de signal. Dans Nucleus SE, les signaux sont facultatifs et chaque tâche a un ensemble de 8 drapeaux. Cette taille a été choisie car les processeurs Nucleus SE cibles susceptibles de traiter efficacement des données 8 bits. Dans le même temps, la modification du nombre d'indicateurs dans les ensembles d'indicateurs de signaux traités par Nucleus SE ne sera pas difficile.

Sections de mémoire

Dans Nucleus RTOS, le nombre et la taille des partitions ne sont pas signés . Dans Nucleus SE, le nombre de partitions est un paramètre de type U8 et la taille de la partition est U16 . Cela conduit à certaines restrictions de taille de partition et de pool.

Minuteries

Dans Nucleus RTOS, les temporisateurs (les temporisateurs d'application et les temporisateurs de sommeil de tâche) fonctionnent avec des valeurs non signées . Dans Nucleus SE, ils sont de type U16 . Ce type a été choisi parce que les processeurs Nucleus SE cibles probables peuvent traiter efficacement des données 16 bits (et huit bits ne sont clairement pas suffisants pour utiliser un temporisateur). Dans le même temps, la modification de la taille des minuteries dans Nucleus SE ne sera pas difficile.

L'article suivant examine comment Nucleus SE peut être utilisé dans un projet de logiciel intégré.

À propos de l'auteur: Colin Walls travaille dans l'industrie électronique depuis plus de trente ans, consacrant la majeure partie de son temps au micrologiciel. Il est maintenant ingénieur firmware chez Mentor Embedded (une division de Mentor Graphics). Colin Walls intervient souvent lors de conférences et séminaires, auteur de nombreux articles techniques et de deux livres sur le firmware. Vit au Royaume-Uni. Blog professionnel de Colin , e-mail: colin_walls@mentor.com.