Toute la vérité sur RTOS. Article # 33. Utilisation du système d'exploitation en temps réel Nucleus SE

Jusqu'à présent, dans cette série d'articles, nous avons examiné les fonctionnalités fournies par Nucleus SE. Il est maintenant temps de voir comment il peut être utilisé dans une véritable application de firmware.

Qu'est-ce que Nucleus SE?

Nous savons que Nucleus SE est le cœur d'un système d'exploitation en temps réel, mais vous devez comprendre comment il s'intègre dans le reste de l'application. Et cela convient, car contrairement à un système d'exploitation de bureau (par exemple, Windows), l'application ne démarre pas sur Nucleus SE; le noyau fait simplement partie d'un programme exécuté sur un périphérique intégré. Il s'agit du cas d'utilisation le plus courant pour RTOS.

D'un point de vue de haut niveau, une application intégrée est une sorte de code qui démarre au démarrage du CPU. Dans ce cas, l'environnement matériel et logiciel est initialisé, puis la fonction main () est appelée, ce qui lance le code d'application principal.

Lors de l'utilisation de Nucleus SE (et de nombreux autres noyaux similaires), la différence est que la fonction main () fait partie du code du noyau. Cette fonction initialise simplement les structures de données du noyau, puis appelle l'ordonnanceur, ce qui conduit au lancement du code d'application (tâches). L'utilisateur peut ajouter n'importe quel code d'initialisation natif à la fonction main () .

Nucleus SE comprend également un ensemble de fonctions - une interface de programmation d'application (API) qui fournit un ensemble de fonctions telles que la communication et la synchronisation des tâches, le travail avec des minuteries, l'allocation de mémoire, etc. Toutes les fonctions API ont été décrites plus haut dans les articles de cette série.

Tous les logiciels Nucleus SE sont fournis en tant que code source (principalement en C). Pour configurer le code conformément aux exigences d'une application particulière, une compilation conditionnelle est utilisée. Ceci est décrit en détail dans cet article dans la section Configuration.

Une fois le code compilé, les modules d'objet Nucleus SE résultants sont associés aux modules de code d'application, résultant en une seule image binaire, qui est généralement placée dans la mémoire flash du périphérique intégré. Le résultat de cette liaison statique est que toutes les informations symboliques restent disponibles à la fois dans le code d'application et dans le code du noyau. Ceci est utile pour le débogage, mais il faut être prudent pour éviter une mauvaise utilisation des données Nucleus SE.

Prise en charge du processeur et des outils

Étant donné que Nucleus SE est fourni en tant que code source, il doit être portable. Cependant, le code s'exécutant à un niveau aussi bas (lors de l'utilisation de planificateurs où un changement de contexte est requis, c'est-à-dire autre chose que Run to Completion), ne peut pas être complètement indépendant du langage d'assembly. J'ai minimisé cette dépendance, et pour le portage vers une nouvelle programmation de bas niveau CPU n'est presque pas nécessaire. L'utilisation d'un nouvel ensemble d'outils de développement (compilateur, assembleur, éditeur de liens, etc.) peut également entraîner des problèmes de portage.

Configuration de l'application Nucleus SE

La clé d'une utilisation efficace de Nucleus SE est une configuration correcte. Cela peut sembler compliqué, mais en fait, tout est assez logique et ne nécessite qu'une approche systématique. Presque toute la configuration se fait en éditant deux fichiers: nuse_config.h et nuse_config.c .

Paramètre Nuse_config.h

Ce fichier n'est qu'un jeu de caractères de la directive #define , auquel sont affectées les valeurs appropriées pour obtenir la configuration de noyau nécessaire. Dans le fichier nuse_config.h, par défaut, tous les caractères sont présents, mais les paramètres minimaux leur sont attribués.

Compteurs d'objets
Le nombre d'objets noyau de chaque type est défini par des valeurs de symboles de la forme NUSE_SEMAPHORE_NUMBER . Pour la plupart des objets, cette valeur peut varier de 0 à 15. Les tâches sont une exception, il doit y en avoir au moins une. Les signaux, en fait, ne sont pas des objets indépendants, car ils sont associés à des tâches et sont activés en définissant NUSE_SIGNAL_SUPPOR T sur TRUE .

Activateurs de fonctions API
Chaque fonction d'API Nucleus SE peut être activée séparément en affectant un symbole dont le nom correspond au nom de la fonction (par exemple, NUSE_PIPE_JAM ) à TRUE . Cela conduit à l'inclusion du code de fonction dans l'application.

Sélection et paramètres du planificateur
Nucleus SE prend en charge quatre types de planificateurs, comme décrit dans un article précédent. Le planificateur utilisé est défini en affectant NUSE_SCHEDULER_TYPE à l' une des valeurs suivantes: NUSE_RUN_TO_COMPLETION_SCHEDULER , NUSE_TIME_SLICE_SCHEDULER , NUSE_ROUND_ROBIN_SCHEDULER ou NUSE_PRIORITY_SCHEDULER .

Vous pouvez configurer d'autres paramètres du planificateur:
NUSE_TIME_SLICE_TICKS indique le nombre de ticks par slot pour le planificateur de tranche de temps. Si un autre ordonnanceur est utilisé, ce paramètre doit être défini sur 0.
NUSE_SCHEDULE_COUNT_SUPPORT peut être défini sur TRUE ou FALSE pour activer / désactiver le mécanisme de compteur du planificateur.
NUSE_SUSPEND_ENABLE active le verrouillage des tâches (suspension) pour de nombreuses fonctions API. Cela signifie qu'un appel à une telle fonction peut entraîner une suspension de la tâche appelante jusqu'à ce que la ressource soit libérée. Pour sélectionner cette option, NUSE_SUSPEND_ENABLE doit également être défini sur TRUE .

Autres options
Plusieurs autres paramètres peuvent également être affectés de valeurs VRAI ou FAUX pour activer / désactiver d'autres fonctions du noyau:
NUSE_API_PARAMETER_CHECKING ajoute un code de vérification de paramètre d'appel d'appel de fonction API. Couramment utilisé pour le débogage.
NUSE_INITIAL_TASK_STATE_SUPPORT définit l'état initial de toutes les tâches comme NUSE_READY ou NUSE_PURE_SUSPEND . Si ce paramètre est désactivé, toutes les tâches auront l'état initial NUSE_READY .
NUSE_SYSTEM_TIME_SUPPORT - prise en charge de l'heure système.
NUSE_INCLUDE_EVERYTHING - un paramètre qui ajoute le nombre maximal de fonctions à la configuration de Nucleus SE. Il conduit à l'activation de toutes les fonctionnalités optionnelles et de chaque fonction API des objets configurés. Utilisé pour créer rapidement une configuration Nucleus SE pour vérifier un nouveau portage du code du noyau.

Définition de nuse_config.c

Après avoir spécifié la configuration du noyau dans nuse_config.h, il est nécessaire d'initialiser les différentes structures de données stockées dans la ROM. Cela se fait dans le fichier nuse_config.c . La définition des structures de données est contrôlée par une compilation conditionnelle, donc toutes les structures sont contenues dans une copie du fichier nuse_config.c par défaut.

Données de tâche
Le tableau NUSE_Task_Start_Address [] doit être initialisé avec la valeur des adresses de départ de chaque tâche. Il s'agit généralement d'une liste de noms de fonction, sans parenthèses. Les prototypes des fonctions de saisie des tâches doivent également être visibles. Dans le fichier par défaut, la tâche est configurée avec le nom NUSE_Idle_Task () , cela peut être changé en tâche d'application.

Si vous utilisez n'importe quel planificateur sauf Run to Completion, chaque tâche nécessite sa propre pile. Pour chaque pile de tâches, vous devez créer un tableau en RAM. Ces tableaux doivent être de type ADDR et l'adresse de chacun d'eux doit être stockée dans NUSE_Task_Stack_Base [] . Il est difficile de prédire la taille du tableau, il est donc préférable d'utiliser des mesures (voir la section «Débogage» plus loin dans cet article). La taille de chaque tableau (c'est-à-dire le nombre de mots sur la pile) doit être stockée dans NUSE_Task_Stack_Size [] .

Si une fonction a été activée pour indiquer l'état initial de la tâche (à l'aide du paramètre NUSE_INITIAL_TASK_STATE_SUPPORT ), le tableau NUSE_Task_Initial_State [] doit être initialisé avec l'état NUSE_READY ou NUSE_PURE_SUSPEND .

Données du pool de partitions
Si au moins un pool de partitions est configuré, une baie (de type U8 ) doit être créée pour chacun d'eux dans la ROM. La taille de ces tableaux est calculée comme suit: (nombre de partitions * (taille de partition + 1)). Les adresses de ces sections (c'est-à-dire leurs noms) doivent être affectées aux éléments NUSE_Partition_Pool_Data_Address [] correspondants. Pour chaque pool, le nombre de partitions et leur taille doivent être placés respectivement dans NUSE_Partition_Pool_Partition_Number [] et NUSE_Partition_Message_Size [] .

Données de file d'attente
Si au moins une file d'attente est configurée, un tableau (de type ADDR ) doit être créé pour chacun d'eux dans la RAM. La taille de ces tableaux est le nombre d'éléments dans chaque file d'attente. Les adresses de ces tableaux (c'est-à-dire leurs noms) doivent être affectées aux éléments NUSE_Queue_Data [] correspondants. La taille de chaque file d'attente doit être affectée à l'élément NUSE_Queue_Size [] correspondant.

Données de liaison de données
Si au moins un canal de données est configuré, un tableau (de type U8 ) doit être créé en RAM pour celui-ci (ou pour chacun d'eux). La taille de ces tableaux est calculée comme suit: (taille du canal * taille du message dans le canal). Les adresses de ces tableaux (c'est-à-dire leurs noms) doivent être attribuées aux éléments NUSE_Pipe_Data [] correspondants. Pour chaque canal, sa taille et sa taille de message doivent être attribuées aux éléments NUSE_Pipe_Size [] et NUSE_Pipe_Message_Size [] correspondants , respectivement.

Données de sémaphore
Si au moins un sémaphore est configuré, le tableau NUSE_Semaphore_Initial_Value [] doit être initialisé avec les valeurs initiales du compte à rebours.

Données du minuteur d'application
Si au moins un temporisateur est configuré, le tableau NUSE_Timer_Initial_Time [] doit être initialisé avec les valeurs initiales des compteurs. De plus, NUSE_Timer_Reschedule_Time [] doit recevoir des valeurs de redémarrage. Ces valeurs de minuterie seront utilisées après la fin du premier cycle de minuterie. Si les valeurs de redémarrage sont définies sur 0, le compteur s'arrête après un cycle.

Si la prise en charge des mécanismes d'achèvement de compte est configurée (en définissant le paramètre NUSE_TIMER_EXPIRATION_ROUTINE_SUPPORT sur TRUE ), deux autres tableaux doivent être créés. Les adresses des mécanismes de complétion (juste une liste de noms de fonction, sans parenthèses) doivent être placées dans NUSE_Timer_Expiration_Routine_Address [] . Le tableau NUSE_Timer_Expiration_Routine_Parameter [] doit être initialisé avec les valeurs des paramètres d'achèvement.

Quelle API?

Tous les systèmes d'exploitation sous une forme ou une autre ont une API (interface de programmation d'application). Nucleus SE ne fait pas exception, et les fonctions qui composent l'API ont été décrites en détail dans cette série d'articles.

Il peut sembler évident que lors de l'écriture d'une application à l'aide de Nucleus SE, vous devez utiliser l'API comme décrit dans les articles précédents. Mais ce n'est pas toujours le cas.

Pour la plupart des utilisateurs, l'API Nucleus SE sera quelque chose de nouveau, peut-être même leur première expérience d'utilisation de l'API du système d'exploitation. Et comme il est assez simple, il peut servir de bonne introduction au sujet. Dans ce cas, la procédure est claire.

Pour certains utilisateurs, une autre API peut être une option plus attrayante. Il y a trois situations évidentes où cela est possible.

1. Nucleus SE n'est qu'une partie d'un système qui utilise d'autres systèmes d'exploitation pour d'autres composants. Par conséquent, la portabilité du code et, plus important encore, l'expérience de l'utilisation de divers systèmes d'exploitation semblent très tentantes.
2. L'utilisateur possède une vaste expérience de l'utilisation de l'API d'un autre système d'exploitation. L'utilisation de cette expérience est également très recommandée.
3. L'utilisateur souhaite réutiliser du code écrit pour l'API d'un autre système d'exploitation. La modification des appels API est possible, mais prend du temps.

Étant donné que le code source complet de Nucleus SE est disponible pour tout le monde, rien ne vous empêche de modifier chaque fonction API afin qu'elle ressemble à son équivalent d'un autre système d'exploitation. Cependant, cela prendra beaucoup de temps et sera très improductif. Une approche plus correcte serait d'écrire un «wrapper». Il existe plusieurs façons de procéder, mais la plus simple consiste à créer un fichier d'en-tête ( #include ) contenant un ensemble de macros #define qui mapperont les fonctions d'API tierces aux fonctions d'API Nucleus SE.

Un wrapper qui transfère (partiellement) les fonctions de l'API RTOS Nucleus à Nucleus SE est distribué avec Nucleus SE. Il peut être utile aux développeurs ayant une expérience de l'utilisation de Nucleus RTOS, ou où à l'avenir il sera possible de passer à ce RTOS. Ce wrapper peut également servir d'exemple lors du développement de choses similaires.

Débogage des applications Nucleus SE

L'écriture d'une application embarquée à l'aide d'un noyau multitâche est une tâche complexe. S'assurer que le code fonctionne et détecter les erreurs peut être une tâche intimidante. Malgré le fait qu'il ne s'agit que de code qui s'exécute sur un processeur, l'exécution simultanée de plusieurs tâches rend assez difficile de se concentrer sur un thread d'exécution spécifique. Cela est encore plus compliqué lorsque plusieurs tâches partagent un code commun. Pire encore, lorsque deux tâches ont exactement le même code (mais fonctionnent avec des données différentes). La complication des structures de données utilisées pour implémenter les objets du noyau afin de voir des informations significatives est également compliquée.

Pour déboguer des applications construites à l'aide de Nucleus SE, aucune bibliothèque ou autre service supplémentaire n'est requis. Tout le code du noyau est lisible par le débogueur. Par conséquent, toutes les informations symboliques sont disponibles pour étude. Lorsque vous travaillez avec des applications Nucleus SE, tout outil de débogage moderne peut être utilisé.

Utiliser un débogueur

Les outils de débogage conçus spécifiquement pour les systèmes embarqués sont devenus très puissants au cours des 30 dernières années. La principale caractéristique d'une application embarquée, par rapport à un programme de bureau, est que tous les systèmes embarqués sont différents (et tous les ordinateurs personnels sont assez similaires les uns aux autres). Un bon débogueur intégré doit être flexible et avoir suffisamment de paramètres pour correspondre à la variété de systèmes intégrés et aux besoins des utilisateurs. La personnalisation du débogueur s'exprime sous diverses formes, mais il existe généralement la possibilité de créer des scripts. C'est cette fonctionnalité qui permet au débogueur de bien fonctionner avec une application au niveau du noyau. Ci-dessous, je vais discuter de quelques cas d'utilisation du débogueur.

Il convient de noter qu'en général, un débogueur est une famille d'outils, pas seulement un programme. Le débogueur peut avoir différents modes de fonctionnement, grâce auxquels il aide lors du développement de code sur un système virtuel ou sur du matériel réel.

Points d'arrêt sensibles aux tâches

Si le programme a un code commun à plusieurs tâches, l'utilisation de points d'arrêt conventionnels lors du débogage est compliquée. Il est fort probable que le code ne s'arrête que lorsqu'un point d'arrêt est atteint dans le contexte d'une tâche spécifique que vous déboguez actuellement. Pour ce faire, vous avez besoin d'un point d'arrêt qui tiendra compte de la tâche.

Heureusement, la possibilité de créer des scripts sur des débogueurs modernes et la disponibilité des données de caractères Nucleus SE rendent l'implémentation de points d'arrêt spécifiques à une tâche assez simple. Il suffit d'écrire un script simple qui sera associé à un point d'arrêt que vous souhaitez enseigner pour distinguer les tâches. Ce script prendra le paramètre: index (ID) de la tâche qui vous intéresse. Le script compare simplement cette valeur avec l'index de la tâche en cours ( NUSE_Task_Active ). Si les valeurs correspondent, le programme s'arrête. S'ils sont différents, l'exécution continue. Il est à noter que l'exécution de ce script affectera l'exécution de l'application en temps réel ( note du traducteur: cela signifie que l'exécution du programme ralentira son fonctionnement normal ). Cependant, si le script n'est pas dans une boucle qui sera exécutée très souvent, cet effet sera minime.

Informations sur les objets du noyau

Le besoin évident de déboguer l'application Nucleus SE est la possibilité d'obtenir des informations sur les objets du noyau: quelles sont leurs caractéristiques et quel est leur statut actuel. Cela vous permet d'obtenir des réponses à des questions telles que: "Quelle est la taille de cette file d'attente et combien de messages y figurent maintenant?"

Cela peut être utilisé en ajoutant du code de débogage supplémentaire à votre application, qui utilisera les appels d'API "informatifs" (tels que NUSE_Queue_Information ). Bien sûr, cela signifie que votre application contient maintenant du code supplémentaire, qui ne sera plus nécessaire après la mise en œuvre de l'application. L'utilisation de #define pour activer et désactiver ce code à l'aide de la compilation conditionnelle serait une décision logique.

Certains débogueurs peuvent effectuer un appel de fonction ciblé, c'est-à-dire appeler directement une fonction API pour récupérer des informations.Cela élimine le besoin de code supplémentaire, mais cette fonction API doit être configurée pour que le débogueur puisse l'utiliser.

Une approche alternative, plus flexible, mais moins «non vieillissante» est l'accès direct aux structures de données des objets du noyau. Très probablement, il est préférable de le faire en utilisant des scripts de débogage. Dans notre exemple, la taille de la file d'attente peut être obtenue à partir de NUSE_Queue_Size [] , et son utilisation actuelle à partir de NUSE_Queue_Data [] . De plus, les messages dans la file d'attente peuvent être affichés en utilisant l'adresse de la zone de données de la file d'attente (à partir de NUSE_Queue_Data [] ).

Valeurs de retour d'appel API

De nombreuses fonctions API renvoient une valeur d'état indiquant le succès de l'appel. Il serait utile de garder une trace de ces valeurs et de marquer les cas dans lesquels elles ne sont pas égales à NUSE_SUCCESS (c'est-à-dire qu'elles ont une valeur de zéro). Étant donné que ce suivi est uniquement destiné au débogage, la compilation conditionnelle est tout à fait appropriée. La définition d'une variable globale (par exemple, NUSE_API_Call_Status ) peut être compilée conditionnellement (sous le contrôle du symbole de directive #define). Ensuite, une partie de la définition des appels d'API, à savoir NUSE_API_Call_Status = , peut également être compilée conditionnellement. Par exemple, à des fins de débogage, un appel qui ressemble généralement à ceci:

NUSE_Mailbox_Send (mbox, msg, NUSE_SUSPSEND);

prendra la forme suivante:

NUSE_API_Call_Status = NUSE_Mailbox_Send (mbox, msg, NUSE_SUSPEND);

Si le verrouillage des tâches est activé, de nombreux appels de fonction API peuvent uniquement renvoyer des informations sur la réussite d'un appel ou sur la réinitialisation de l'objet. Cependant, si la vérification des paramètres d'API est activée, les appels d'API pourront renvoyer de nombreuses autres valeurs.

Définition de la taille de la pile de tâches et du débordement de pile

Le sujet de la protection contre le débordement de pile a été abordé dans un article précédent (# 31). Il existe plusieurs autres possibilités lors du débogage.

La zone mémoire de la pile peut être remplie d'une valeur caractéristique: autre chose que tous les uns ou tous les zéros. Après cela, le débogueur peut être utilisé pour surveiller les zones de mémoire et combien les valeurs seront modifiées, ce qui permettra de comprendre le degré de saturation de la pile. Si toutes les zones de mémoire ont été modifiées, cela ne signifie pas que la pile était pleine, mais cela peut signifier que sa taille est à peine suffisante, ce qui est dangereux. Elle devrait être augmentée et les tests poursuivis.

Comme décrit dans l' article # 31, lors de la mise en œuvre des diagnostics, des zones supplémentaires, des «mots de protection», peuvent être situées sur l'un des bords de la zone de mémoire de la pile. Le débogueur peut être utilisé pour suivre l'accès à ces mots, car toute tentative de les écrire signifie un débordement ou un épuisement de la pile.

Liste de contrôle de configuration de Nucleus SE

Étant donné que Nucleus SE a été conçu comme un système hautement flexible et personnalisable pour répondre aux exigences des applications, il nécessite un nombre important de paramètres personnalisables. C'est pourquoi l'intégralité de cet article est en fait consacrée à la configuration de Nucleus SE. Pour vous assurer de ne rien manquer, voici une liste de contrôle de toutes les étapes clés que vous devez suivre pour créer l'application intégrée Nucleus SE.

1. Nucleus SE. , Nucleus SE , Nucleus SE .
2. CPU/. .
3. . , , .
4. . . . , . 16 .
5. . - main() ?
6. . 4 , .
7. , .
8. .
9. . , .
10. . , .
11. . , . . — 16 .
12. . , .
13. . , (, ).
14. API. API, .

Le prochain article (le dernier de cette série) résumera toute l'histoire avec Nucleus SE et fournira également des informations pour vous aider à créer et à utiliser des implémentations Nucleus SE.

À 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.