Toute la vérité sur RTOS. Article # 7. Nucleus SE: Introduction



Dans le reste de la série «Toute la vérité sur RTOS», nous examinerons en détail comment le RTOS est mis en œuvre et déployé. Pour ce faire, nous considérerons un RTOS spécifique: Nucleus SE. Même si vous n'utilisez pas ce noyau particulier ou d'autres noyaux qui lui sont liés, comprendre comment il fonctionne fournira une bonne base pour travailler avec n'importe quel RTOS.

Pour comprendre pourquoi Nucleus SE a été conçu de cette manière, il est important de mettre en évidence les tâches et les objectifs principaux que j'ai suivis au début de ce projet.

Articles précédents de la série:
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.


Simplicité

Le code du noyau doit être simple, direct, bien commenté et documenté. Nucleus SE est principalement destiné à un usage éducatif.

La taille

Cela devrait être un petit noyau bien évolutif (car la mémoire, en particulier la mémoire opérationnelle (RAM), peut être insuffisante).

Fonctionnalité

Le noyau doit avoir un niveau élevé de fonctionnalités qui prend en charge les services RTOS standard.

Prise en charge 8/16 bits

Il doit prendre en charge les architectures 8 et 16 bits: dans la mesure du possible, utilisez des données de la taille d'un octet; les structures de données ne devraient pas nécessiter de méthodes d'adressage exotiques; les données persistantes ne doivent pas être copiées dans la RAM inutilement.

Le futur

Il doit y avoir un chemin de développement de Nucleus SE vers Nucleus RTOS. Les utilisateurs devraient pouvoir transférer facilement le code entre les cœurs. Plus important encore, leurs connaissances doivent également être transférées. L'API Nucleus SE implémente efficacement un sous-ensemble de l'API RTOS Nucleus.

Coût

Le modèle d'entreprise devrait être attrayant pour tous les utilisateurs potentiels: les développeurs d'appareils 8/16 bits, ceux qui utilisent d'abord le RTOS et ceux qui étudient simplement la technologie elle-même. Ainsi, Nucleus SE est disponible gratuitement, absolument gratuit à des fins commerciales et éducatives; le code peut être utilisé et modifié.

Public cible Nucleus SE

Le résultat de cette approche est un noyau qui peut être utile pour trois types de développeurs:

  • Programmeurs d'appareils 8/16 bits qui nécessitent un simple noyau ou planificateur de tâches. Cela est particulièrement intéressant si les développeurs souhaitent acquérir certaines compétences pour utiliser RTOS ou développer un système qui utilise d'autres appareils 32 bits où Nucleus RTOS peut être un bon choix.
  • Développeurs d'applications embarqués utilisant des appareils 32 bits où la complexité logicielle ne vaut pas le coût d'un RTOS commercial traditionnel. L'utilisation de Nucleus SE peut être utile et permettra le développement (jusqu'à Nucleus RTOS) si la complexité de l'application augmente.
  • Les étudiants dans le processus d'apprentissage peuvent utiliser Nucleus SE comme base d'apprentissage RTOS. Les compétences acquises seront utiles plus tard quand elles commenceront à travailler.

Décisions de conception et compromis

Afin d'atteindre les objectifs ci-dessus, plusieurs décisions de conception soigneusement pensées ont dû être prises. Les détails seront décrits plus tard lorsque nous considérerons des fonctions spécifiques, mais voici un bref résumé des points clés.

Configuration statique

Nucleus SE est un RTOS statique, ce qui signifie que toutes les décisions de configuration sont prises au moment de la construction, et non dynamiquement au moment de l'exécution. Cela présente de nombreux avantages, notamment la simplification de la structure des données et la réduction de la taille du code, il n'est donc pas nécessaire d'appeler les fonctions de création et de suppression d'API. Pour la plupart des applications, la création d'objet dynamique n'est pas requise.

Nombre d'objets

Le nombre d'objets de chaque type est limité dans une application basée sur Nucleus SE. Il peut s'agir d'une à seize tâches et de zéro à seize types différents d'objet noyau. Cela simplifie l'adressage des objets (voir ci-dessous). Cette restriction n'est pas difficile pour les petites applications auxquelles le noyau est destiné.

Adressage d'objets

Les objets sont adressés à l'aide d'un «index», qui peut aller de zéro à quinze. Par rapport à l'utilisation habituelle des pointeurs, cela peut être plus efficace sur des processeurs plus petits et permettre moins de mémoire: l'index ne nécessite que 4 bits de mémoire; L'adresse est de 16 à 32 bits.

Planificateur

L'ordonnanceur appartenait au domaine de l'architecture du noyau qui était simplifié. Au lieu de fournir un mécanisme flexible avec différentes politiques de planification, quatre types de planificateurs distincts sont disponibles dans le noyau; le planificateur spécifique pour l'application est sélectionné lors de la configuration.

Fonctionnalité limitée

Certaines fonctionnalités disponibles dans Nucleus RTOS ne sont pas implémentées dans Nucleus SE. Dans certains cas, cela est fait par souci de simplicité. Dans d'autres cas, une légère perte de fonctionnalité dans un domaine facilite la mise en œuvre de l'autre fonctionnalité. Ces incompatibilités sont mises en évidence dans les articles pertinents de la série.

Utilisation de la mémoire

Étant donné que Nucleus SE doit prendre en charge des applications de mémoire limitées, une attention particulière a été accordée à l'utilisation de la mémoire. Il était censé utiliser la ROM et la RAM "classiques": la ROM était utilisée pour le code et les données persistantes; RAM - pour stocker des variables, une pile, etc. Bien qu'une cible spécifique puisse avoir un schéma différent, le code Nucleus SE est assez flexible; les définitions (#defines) de ROM et RAM sont utilisées pour préfixer toutes les structures de variables et de données pour indiquer leur emplacement. Cela peut être réalisé à l'aide d'outils.

La principale exigence était d'éviter la copie inutile des données de la ROM vers la RAM, car la RAM peut ne pas être suffisante. Le mécanisme par lequel cela est réalisé est décrit dans la section Structures de données de l'article suivant.

Implémentation d'API

L'API pour Nucleus SE est implémentée de manière traditionnelle: la fonction de langage C implémente chaque appel d'API. Ces appels sont regroupés logiquement. Bien que les appels d'API dans Nucleus SE ne soient pas tout à fait les mêmes que dans Nucleus RTOS, la fonctionnalité globale est simulée et le mappage entre les API est facile. Les détails de l'API RTOS Nucleus seront inclus.

Sections critiques

Le code de nombreux appels de fonction API comprend des séquences d'instructions qui manipulent les données du noyau. Généralement, les données peuvent être dans un état invalide lors de l'exécution de ces instructions, il faut donc veiller à éviter toute interruption. Ou, il peut être interdit d'exécuter du code à partir d'une autre tâche ou d'interrompre le gestionnaire s'il peut accéder à ces données (actuellement non valides). Ces séquences d'instructions sont appelées sections critiques.

Une paire de macros est définie appelée NUSE_CS_Enter () et NUSE_CS_Exit (). Tous les codes des fonctions de l'API Nucleus SE les utilisent pour couvrir la section critique, ainsi:

NUSE_CS_Enter ();
<code non interruptible>
NUSE_CS_Exit ();

En règle générale, ces macros seront développées respectivement en instructions de désactivation des instructions d'interruption et en instructions d'activation d'interruption. Cela devra être vérifié si Nucleus SE est implémenté sur une architecture de processeur différente. Plus d'informations sur le portage de Nucleus SE seront décrites dans le prochain article.

Évolutivité

Comme tous les RTOS modernes, Nucleus SE est évolutif. Pour vous assurer que seuls les composants RTOS utilisés sont inclus, toutes les fonctions API sont présentées sous la forme d'une bibliothèque. Ainsi, lors de la liaison, les fonctions référencées sont extraites et incluses dans l'image finale de l'application. Nucleus RTOS utilise cette approche pour le noyau et tous les autres composants du système d'exploitation. Nucleus SE utilise une technique différente.

Au lieu de s'appuyer sur la bibliothèque de la boîte à outils sélectionnée, tous les fichiers source de la distribution Nucleus SE contiennent des directives de compilation conditionnelle. Pour configurer Nucleus SE pour le programme, le développeur doit installer plusieurs caractères #define (plus à ce sujet dans le prochain article). Cela détermine quelles fonctions API sont compilées et donc incluses dans le programme.

Nucleus SE améliore cette approche en proposant un objet que j'appelle «une évolutivité extrême». Plusieurs aspects de la fonctionnalité du noyau peuvent être activés et désactivés, ou configurés d'autres manières en utilisant des caractères #define similaires. Ainsi, le développeur a un contrôle ponctuel sur l'utilisation de la mémoire.

Quelle API?

Nucleus SE possède sa propre API, qui sera décrite en détail dans les prochains articles. Pour de nombreux utilisateurs, le simple fait d'inclure ces appels aux fonctions API dans le code sera suffisant.

Certains utilisateurs peuvent préférer utiliser une autre API: standard ou familière. L'API Nucleus SE est assez flexible et vous permet de créer un wrapper qui transforme une interface en une autre API.

L'un des principaux objectifs du développement de Nucleus SE est un degré élevé de compatibilité au niveau de l'utilisateur avec Nucleus RTOS. Bien que les API soient différentes, elles sont conçues pour être faciles à associer. Un wrapper sera disponible pour faciliter l'utilisation de l'API RTOS Nucleus sur Nucleus SE.

Dans le prochain article, nous continuerons à examiner Nucleus SE et à nous concentrer sur la structure interne et le déploiement de RTOS.

Source: https://habr.com/ru/post/fr418601/


All Articles