Toute la vérité sur RTOS. Article # 6. Autres services RTOS

Dans les articles précédents, nous avons discuté de la fonctionnalité du noyau en termes de tâches effectuées et de l'interaction entre elles. Dans cet article, nous examinons ce que le noyau peut faire d'autre, ce qui se manifeste largement dans un certain nombre d'autres appels d'API disponibles. Nous répondrons également à la question: qu'est-ce qui transforme le noyau en système d'exploitation?

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

Gestion des tâches

En plus de la planification des tâches et de l'interaction entre eux, le RTOS comprendra des fonctionnalités (appels API) pour gérer les tâches de différentes manières. Examinons quelques possibilités.

Créer et supprimer des tâches

Dans le RTOS "dynamique", il existe des appels de fonction qui vous permettent de créer des tâches (et d'autres objets RTOS) quand elles sont nécessaires. Ces appels incluent un large éventail de paramètres qui définissent la tâche, par exemple, le point d'entrée, la taille de la pile et la priorité. L'appel d'API de suppression de tâche correspondant vous permet de libérer des ressources une fois la tâche terminée.

Dans le RTOS "statique", les paramètres de définition de la tâche sont configurés dans une sorte de fichier de configuration lors de l'assemblage.

Mettre en pause et reprendre une tâche

Comme nous l'avons vu, la plupart des RTOS ont le concept d'un état de tâches «suspendu». Cela peut être réalisé de différentes manières. L'un d'eux est un appel explicite à la fonction API Suspend Task. Il peut être causé par lui-même ou par une autre tâche. L'appel «Reprendre la tâche» correspondant permet à la tâche de faire à nouveau la queue pour la planification.

État de veille des tâches

Pour un système en temps réel, le contrôle du temps est une exigence importante et peut prendre diverses formes. Une vue simple est la capacité de la tâche à "s'endormir", c'est-à-dire que la tâche est suspendue pendant un certain temps. Lorsque le temps est écoulé, la tâche se "réveille" et est à nouveau mise en file d'attente pour la planification. Un appel API sera généralement disponible à cet effet. Bien entendu, cette fonctionnalité dépend de la disponibilité de la minuterie.

Exemption

Lors de l'utilisation de l'ordonnanceur Round Robin ("carrousel"), une tâche peut refuser de contrôler le processeur pour la prochaine tâche de la chaîne. Pour ce faire, la fonction API «Release task» sera disponible. La tâche n'est pas suspendue, elle sera disponible pour la planification à son tour. Lors de l'utilisation du planificateur de tranche de temps, il est possible qu'une tâche puisse libérer une partie de son intervalle de temps si elle n'a pas de travail important à faire immédiatement. La libération d'une tâche n'a aucune signification logique lors de l'exécution des planificateurs Exécuter jusqu'à la fin ou Priorité.

Achèvement de la tâche

Dans un article précédent, nous avons constaté qu'en plus des états «Prêt» ou «Suspendu», le RTOS peut prendre en charge d'autres états de tâche. La tâche peut être «terminée», ce qui signifie que sa fonction principale vient de quitter: aucun appel API spécial n'est requis. Une tâche peut être «Terminée», ce qui signifie qu'elle n'est pas disponible pour la planification et doit être réinitialisée pour redevenir disponible pour le lancement, voir «Réinitialisation d'une tâche» ci-dessous. Cela nécessite un appel API spécial. La disponibilité de ces états de tâche supplémentaires, la terminologie utilisée et leurs définitions exactes varient en fonction du RTOS.

Réinitialisation de la tâche

De nombreux RTOS proposent un appel à la fonction API «Reset Task», qui vous permet de ramener la tâche à son état d'origine. Elle peut être suspendue et exiger l'exécution de la fonction «Reprendre la tâche» afin de faire la queue pour la planification.

Tâches prioritaires, etc.

Dans un RTOS «dynamique», des appels d'API peuvent être disponibles pour configurer plusieurs paramètres de tâche au moment de l'exécution. Les exemples incluent la priorité et la durée de l'intervalle de temps.

Informations système

Dans RTOS, il y aura un certain nombre d'appels d'API pour fournir au système des informations sur la tâche, notamment:
Informations sur les tâches . Combien de tâches se trouvent dans le système, leur configuration et leur état actuel.
Informations sur d'autres objets du noyau. Le nombre d'objets de chaque type dans le système, leur configuration et les informations sur l'état actuel. Par exemple:

• Quelle est la capacité actuelle de la file d'attente? Puis-je ajouter d'autres messages?
• combien de tâches sont suspendues sur une boîte aux lettres particulière?

Informations sur la version RTOS . Un appel API peut fournir des données similaires.

Allocation de mémoire

Dans de nombreuses applications, il est important que le programme puisse capturer dynamiquement de la mémoire lorsqu'elle est nécessaire et la libérer lorsqu'elle n'est plus nécessaire. La même chose se produit dans le firmware. Cependant, les approches conventionnelles sont sujettes à des problèmes qui sont peu probables ou incommodes dans les applications de bureau, mais elles peuvent être désastreuses pour un système embarqué. Néanmoins, il existe des moyens de mettre en œuvre de tels services, même dans un RTOS statique.

Problèmes avec les fonctions malloc () et free ()

Dans un programme C de bureau, une fonction peut appeler malloc () , indiquant la quantité de mémoire requise, et récupérer un pointeur vers la zone de stockage. En utilisant la mémoire, elle peut être libérée en appelant free () . La mémoire est allouée à partir d'une zone appelée tas. Le problème avec cette approche est qu'avec une séquence non coordonnée d'appels à ces fonctions, la zone de tas peut facilement devenir fragmentée, puis l'allocation de mémoire échouera même si suffisamment de mémoire est disponible, car les zones adjacentes ne sont pas assez grandes. Certains systèmes (tels que Java et Visual Basic) utilisent des schémas sophistiqués de «garbage collection» pour défragmenter. Le problème est que ces schémas peuvent entraîner des retards imprévisibles importants dans l'exécution et la nécessité d'utiliser des pointeurs indirects (qui ne fonctionne pas en C).

Si malloc () et free () étaient implémentés de manière réentrante (généralement pas) et utilisés par les tâches RTOS, la fragmentation se produira très rapidement et une défaillance du système sera presque inévitable. En C ++, il existe de nouveaux opérateurs de suppression qui exécutent généralement les mêmes fonctions que malloc () et free (). Ils sont soumis aux mêmes limitations et problèmes.

Sections de mémoire

Pour fournir un système en temps réel avec une mémoire accessible dynamiquement, une approche par blocs de la gestion de la mémoire peut être utilisée. Ces blocs sont communément appelés "partitions"; les partitions peuvent être allouées à partir du "pool de partitions".

Le pool de partitions contient un certain nombre de blocs, chacun ayant la même taille. Le nombre et la taille des blocs d'une partition sont déterminés lors de la création du pool de partitions. Cela peut être dynamique si le système lui-même le permet, ou statiquement pendant l'assemblage. En règle générale, une application peut inclure plusieurs pools de partitions offrant des blocs de tailles différentes.

Si une tâche a besoin de mémoire, elle appelle une API qui demande un bloc à partir d'un pool spécifique. Si cet appel réussit, la tâche recevra un pointeur vers le bloc sélectionné. Si l'appel échoue parce que il n'y a pas de partitions disponibles dans le pool indiqué, la tâche peut recevoir une réponse d'erreur. Alternativement, la tâche peut être bloquée (suspendue) jusqu'à ce qu'une autre tâche libère le blocage dans la section.

En règle générale, une tâche passe simplement un pointeur vers un bloc de mémoire dans n'importe quel code qui utilise le bloc. Cela conduit à un problème lorsque le bloc n'est plus nécessaire. Si le code n'a qu'un pointeur sur un bloc, comment peut-il indiquer au RTOS via un appel d'API, à partir de quel pool de partitions veut-il libérer de la mémoire? La réponse est que la plupart des RTOS prennent en charge des données supplémentaires dans un bloc dédié (généralement un décalage négatif par rapport au pointeur) qui fournissent les informations requises. Ainsi, pour appeler l'API pour libérer un bloc, seule son adresse est requise.

L'article suivant contiendra plus d'informations sur les partitions de mémoire.

Le temps

Les fonctionnalités associées à l'utilisation et au contrôle du temps sont susceptibles d'être disponibles dans le système d'exploitation en temps réel. Les opportunités varieront en fonction du RTOS, mais nous considérerons celles disponibles publiquement. Dans tous les cas, le temporisateur en temps réel est un élément indispensable au fonctionnement de l'un de ces services.

Heure système

L'heure système simple, ou "horloge", est presque toujours disponible. Il s'agit simplement d'un compteur (généralement 32 bits), qui est incrémenté à l'aide de la routine de service d'interruption en temps réel et peut être défini et lu via des appels d'API.

Délais d'attente des appels de service

En règle générale, un RTOS permet de bloquer les appels d'API, c'est-à-dire que la tâche d'appel est suspendue (bloquée) jusqu'à ce que le service demandé soit fourni. Habituellement, ce verrou est vague, mais certains RTOS offrent un délai pendant lequel l'appel revient à l'expiration du délai si le service continue d'être indisponible. Les délais d'expiration des appels API ne sont pas pris en charge par tous les RTOS.

État de veille des tâches

En règle générale, les tâches ont la possibilité de s'interrompre pendant une période de temps fixe. Cela a été discuté précédemment dans la section Gestion des tâches.

Minuteries logicielles

Pour que les tâches du programme exécutent des fonctions de comptage du temps, la plupart des RTOS proposent des objets de temporisation. Ce sont des temporisateurs indépendants mis à jour par le gestionnaire d'interruption de temporisateur en temps réel, qui peuvent être contrôlés par des appels d'API. Ces appels configurent, contrôlent et contrôlent le fonctionnement du temporisateur. En règle générale, ils peuvent être définis pour un seul actionnement ou redémarrage automatique. Une routine d'expiration est également généralement prise en charge, une fonction qui s'exécute chaque fois qu'une minuterie termine un cycle. Le prochain article fournira plus d'informations sur les temporisateurs logiciels et une description de leur implémentation.

Interruptions, pilotes et E / S

La mesure dans laquelle les RTOS sont associés aux interruptions et aux E / S est très différente. De même, certains RTOS ont une structure très claire pour les pilotes de périphériques, ce qui peut ajouter des problèmes lors du choix d'un produit spécifique.

Interruptions

Les interruptions présentent un problème pour RTOS pour deux raisons.

• Sans aucune précaution, le gestionnaire d'interruption (ISR) «volera» le temps processeur, perturbant ainsi le comportement RTOS en temps réel.
• Si l'ISR effectue des appels d'API qui affectent la planification des tâches, cela doit être surveillé et le RTOS doit pouvoir exécuter son algorithme de planification.

Un exemple d'un tel appel API est la procédure pour réveiller une tâche avec une priorité plus élevée que celle qui a été lancée lorsque l'interruption s'est produite.

Certains RTOS contrôlent entièrement toutes les interruptions. Une série d'appels API sont disponibles pour "enregistrer" les programmes ISR. Cette approche permet au planificateur de déterminer quand les interruptions sont activées et facilite l'utilisation de la plupart des appels d'API à partir de l'ISR.

Par exemple, Nucleus RTOS implémente le concept de gestionnaires d'interruptions «basse priorité» et «haute priorité», qui fournit une gestion fiable des interruptions sans surcharge inutile (c'est-à-dire une augmentation du délai d'interruption).

D'autres RTOS peuvent utiliser le mode automatique «sans intervention» pour les interruptions, ce qui offre aux développeurs plus d'options pour s'assurer que les gestionnaires d'interruption fonctionnent correctement. En règle générale, un préfixe ISR supplémentaire (prologue) et un suffixe (épilogue) sont fournis pour protéger les appels d'API qui y sont effectués.
Nucleus SE utilise une routine d'interruption légère, qui sera décrite dans un futur article.

Pilotes

La plupart des RTOS déterminent la structure du pilote de périphérique. Les détails peuvent varier en fonction du RTOS, mais le pilote se compose généralement de deux composants en interaction: le code intégré (appels API) et ISR. En règle générale, d'autres appels API seront disponibles pour gérer et enregistrer les pilotes.

Entrée / sortie

Actuellement, la plupart des RTOS sur le marché ne se soucient pas des entrées / sorties de niveau supérieur, mais certains d'entre eux définissent un flux d'entrée / sortie, qui établit essentiellement une connexion entre les pilotes de périphérique correspondants et les fonctions du langage C standard, telles que printf ().
Historiquement, le RTOS supportait souvent la «console», l'interface utilisateur du RTOS via un canal série. Cela a été principalement utilisé pour les diagnostics et le débogage. L'utilisation de débogueurs modernes qui prennent en charge le débogage d'applications avec RTOS élimine le besoin de tels objets.

Diagnostics

En règle générale, RTOS nécessite des performances maximales avec un encombrement mémoire minimal. Par conséquent, la vérification d'intégrité n'est pas une priorité élevée. Avec l'aide de technologies de débogage modernes qui prennent en compte les fonctionnalités du RTOS, la plupart des contrôles peuvent être effectués en dehors du RTOS lui-même.

Vérification des paramètres d'appel d'API

Les appels d'API peuvent avoir de nombreux paramètres complexes. Cela peut provoquer des erreurs. De nombreux RTOS fournissent une vérification des paramètres d'exécution avec le retour d'un code d'erreur en cas de paramètre incorrect. Étant donné que cela nécessite du code supplémentaire et que les vérifications elles-mêmes affectent négativement les performances, il est préférable de vérifier les paramètres lors de l'assemblage ou de la configuration.

Vérification de la pile

Pour la plupart des types de planificateurs (sauf Run to Completion), chaque tâche a sa propre pile, dont la taille est déterminée individuellement. Dans certains RTOS, le noyau a une pile distincte, dans d'autres, la pile de tâches est «empruntée» lors d'un appel d'API. De toute évidence, l'intégrité de la pile est importante pour la fiabilité globale du système. Par conséquent, les RTOS offrent souvent des outils pour vérifier l'intégrité de la pile au moment de l'exécution. Il existe plusieurs options:

• Un appel d'API qui renvoie la quantité d'espace de pile pour la tâche actuelle ou spécifiée.
• Les paramètres de délimitation de la pile. On leur attribue une valeur unique (généralement impaire et non nulle), qui est périodiquement vérifiée pour la réécriture.

Diagnostic d'application

Malgré le fait que cette fonction n'est pas directement prise en charge dans le RTOS, une tâche d'application peut être allouée pour vérifier l'intégrité de l'ensemble du système. Une telle tâche peut être responsable de la réinitialisation du temporisateur de surveillance. Une tâche peut recevoir des données d'entrée périodiques (par exemple, des paramètres de signal) de chaque tâche critique. La réinitialisation de la minuterie du chien de garde (qui empêchera le redémarrage du système) ne sera effectuée qu'après l'arrivée des données de toutes les tâches.

Services non noyaux

Le RTOS est plus que le noyau sur lequel nous nous sommes concentrés jusqu'à présent. Ce système d'exploitation de bureau est considérablement différent du RTOS intégré. En règle générale, dans un système d'exploitation de bureau, tous les composants supplémentaires sont regroupés ou peuvent être installés (tous les PC de bureau ont une interface utilisateur graphique et seuls quelques-uns d'entre eux n'ont pas accès au réseau). Le PC de bureau n'a pas de réelles limites de ressources: il y a toujours de la mémoire libre, de l'espace disque dur et des ressources CPU inutilisées. Dans un monde de systèmes embarqués avec des ressources limitées, des composants supplémentaires tels que des cartes vidéo, des composants réseau et des systèmes de fichiers peuvent être nécessaires, mais ils doivent être déconnectables et évolutifs pour minimiser l'empreinte mémoire.

Fonctionnalités de mise en réseau

La plupart des systèmes embarqués sont en quelque sorte liés aux réseaux. Ainsi, il est prévu qu'il existe un intérêt important pour les solutions de mise en réseau pour les systèmes embarqués, en raison de laquelle il existe un grand nombre de produits sur le marché.

TCP / IP est un protocole standard qui est largement utilisé et est le choix évident pour de nombreuses applications. En règle générale, TCP / IP est utilisé pour le protocole Ethernet (IEEE802.3), qui fournit une vitesse moyenne de 10 Mb / s. Aujourd'hui, 100 Mb / s sont assez courants, et à l'approche 1 Gb / s. De plus, TCP / IP peut être utilisé pour d'autres protocoles. Par exemple, PPP (Point-to-Point Protocol) est une implémentation TCP / IP pour le transfert de données série qui a été adaptée pour les connexions Internet à large bande.

Jusqu'à récemment, la version v4 du protocole IP (IPv4) était utilisée. Cependant, il devient obsolète à mesure que les adresses libres s'épuisent. La solution est IPv6, augmentant considérablement le nombre d'adresses possibles et fournissant des outils plus efficaces pour la maintenance et la sécurité. IPv6 est largement disponible et utilisé dans les équipements de nombreux pays, ainsi que dans les systèmes militaires du monde entier.
Une alternative est le protocole UDP (User Datagram Protocol). Ce protocole est utilisé pour des performances maximales. UDP n'offre pas la même fiabilité et cohérence que TCP, mais il est léger et très efficace.

L'USB est le bus série universel, largement utilisé dans les appareils pour la connexion aux ordinateurs de bureau. Il fournit une interface plug-and-play très facile à utiliser qui cache des logiciels assez sophistiqués.Un périphérique intégré qui doit être connecté à un PC doit être implémenté en tant que fonction USB, ce qui nécessite un ensemble spécifique de composants logiciels. Si l'appareil doit gérer d'autres appareils connectés via USB (comme un PC ordinaire), il a besoin d'un ensemble de logiciels de type hôte.

IEEE1394 est une autre norme d'interface série utilisée pour transférer rapidement de grandes quantités de données entre les appareils (par exemple, pour la transmission de données vidéo), également connue sous le nom de FireWire et i.Link.

Protocoles sans fil - la commodité et la prévalence de diverses technologies sans fil chez les consommateurs ont entraîné une forte demande de capacités sans fil dans les appareils intégrés. Le Wi-Fi (ensemble de normes IEEE802.11) fournit un ensemble complet de capacités réseau, vous permettant de mettre en œuvre des topologies homologues et d'infrastructure à une distance suffisante. L'intérêt pour la sécurité des données dans de tels réseaux augmente, ce qui signifie que cela devrait affecter les logiciels. D'autres technologies radio, notamment Bluetooth et ZigBee, fournissent des communications sans fil point à point à courte portée.

Vérification du protocole

Les opportunités de réseautage étant très demandées, de nombreux fournisseurs proposent leurs solutions. Les clients sont confrontés au défi de vérifier la qualité des produits disponibles. Contrairement au noyau RTOS, une vérification complète des fonctionnalités et des performances de la pile de protocoles n'est pas une tâche facile. Heureusement, des boîtes à outils sont disponibles pour vérifier les protocoles (bien qu'à un prix important), et un acheteur potentiel peut s'informer auprès du fournisseur de l'ensemble qu'il a utilisé pour vérifier.

Graphisme

Une interface graphique devient de plus en plus courante parmi les appareils embarqués. Il peut s'agir d'un petit écran LCD monochromatique très simple (comme sur les anciens téléphones, lecteurs MP3, alarmes, etc.). D'un autre côté, un récepteur de télévision numérique peut avoir son propre écran HDTV haute résolution. Un tel écran nécessite un support logiciel entièrement intégré au noyau RTOS.
Étant donné que l'écran possède généralement une sorte de périphérique d'entrée, la prise en charge de ces périphériques est souvent incluse dans le package graphique. Un tel package peut prendre en charge des périphériques de pointage (par exemple, une souris), des écrans tactiles, des claviers et des claviers complets.
Les graphiques peuvent être utilisés de différentes manières. Il peut simplement fournir des informations (par exemple, comme un tableau de bord électronique). Ou l'affichage peut faire partie d'une interface utilisateur graphique avec des menus, des fenêtres, des icônes et des éléments similaires. Dans tous les cas, un ensemble de logiciels assez spécifique est requis, et le package graphique fourni avec le RTOS devrait fournir la flexibilité nécessaire sans augmenter de manière significative la quantité de mémoire utilisée.

Systèmes de fichiers

Lorsqu'une application intégrée doit stocker et traiter des quantités importantes de données, il est évident qu'il est logique d'organiser ces données dans une sorte de système de fichiers. Les données peuvent être dans la RAM, dans la mémoire flash intégrée, sur un lecteur flash USB, sur un disque dur ordinaire ou sur un disque optique (CD-ROM ou DVD-ROM). Encore une fois, une telle opportunité devrait avoir un support logiciel entièrement intégré dans le RTOS. Le système de fichiers doit être soigneusement conçu pour répondre aux exigences réentrantes d'un système multitâche.

La conformité est particulièrement importante pour les systèmes de fichiers. Par exemple, l'utilisation du format de disque compatible MS-DOS permet aux développeurs d'utiliser l'architecture bien établie et offre un échange de données à part entière avec les systèmes de bureau.