Toute la vérité sur RTOS de Colin Walls

Toute la vérité sur RTOS. Article # 1.

Systèmes d'exploitation en temps réel: Introduction

Cette série d'articles est consacrée à une étude approfondie de tous les aspects des systèmes d'exploitation en temps réel (RTOS). Les articles sont destinés aux développeurs qui sont curieux d'apprendre comment fonctionne le RTOS et comment les utiliser. Le point de départ sera la discussion sur les systèmes en temps réel en général, puis nous parlerons de la manière dont RTOS peut simplifier leur implémentation et rendre le code résultant plus fiable.

En regardant à l'intérieur du RTOS, nous verrons comment fonctionne le planificateur de tâches. Grâce au multithreading, il semble que le CPU effectue plusieurs opérations simultanément. Ce n'est pas magique, une compréhension des principes du planificateur de tâches est disponible même pour un ingénieur logiciel inexpérimenté. Nous parlerons d'autres objets du RTOS: de l'interaction entre les tâches et la synchronisation, du mode temps réel, de la gestion de la mémoire, etc., tout sera décrit avec précision et soutenu par des exemples de code.

Pour le développeur, un aspect clé du RTOS est l'API, un ensemble d'appels de procédure qui donnent accès à la fonctionnalité RTOS. La série contiendra des articles sur le fonctionnement de l'API, les normes disponibles et comment passer d'une API à une autre.

Voici une liste de sujets que nous examinerons dans un avenir proche:

• Structure du programme et temps réel
• Systèmes d'exploitation en temps réel
• Tâches et planification
• Interaction et synchronisation des tâches
• Autres services de système d'exploitation
• Nucleus SE
• Planificateur
• Les tâches
• Sections de mémoire
• Signaux
• Groupes de drapeaux d'événements
• Sémaphores
• Boîtes aux lettres
• Files d'attente
• Chaînes
• Heure système
• Minuteries logicielles
• Interruptions
• Diagnostics et vérification des erreurs
• Initialisation et lancement

La série d'articles n'est liée à aucun système d'exploitation en temps réel particulier; la plupart du matériel est applicable aux options accessibles au public pour la mise en œuvre de RTOS. Selon l'auteur, l'utilisation d'un système d'exploitation commercial prêt à l'emploi avec le support existant est le moyen de travail le plus fiable et le plus productif. L'un des articles sera consacré à une discussion détaillée sur le thème «faire contre acheter» et d'autres méthodologies pour choisir un RTOS.

Cependant, pour expliquer la conception interne du RTOS, des exemples du vrai code de produit, Nucleus SE, sont utilisés.

Source: http://www.embedded.com/design/operating-systems/4442729/Introducing--RTOS-Revealed

Toute la vérité sur RTOS. Article n ° 2

RTOS: Structure et mode temps réel
Structure du programme et temps réel

Cette série d'articles concerne les systèmes embarqués et, en particulier, les logiciels fonctionnant sur des systèmes embarqués. Commençons par la définition. Qu'est-ce qu'un système embarqué? En 1986, lorsque j'ai écrit le premier livre sur ce sujet, un tel terme n'existait pas. Les concepts de «système dédié» ou de «microsystème» ont été utilisés, mais, bien sûr, ils ne reflétaient pas toute l'essence. Quelques années plus tard, le mot «intégré» est entré en vigueur et tous les spécialistes ont commencé à l'utiliser activement.

Retour à la définition d'un système embarqué. Dans le but d'expliquer à mes amis et à ma famille sur quoi je travaille, j'ai proposé l'explication suivante: un système embarqué est tout appareil électronique doté d'un processeur, mais qui n'est généralement pas accepté comme ordinateur.

Le système d'exploitation (OS) est toujours sur l'ordinateur; dans les systèmes embarqués modernes, seuls certains types de systèmes d'exploitation sont utilisés. Malgré le fait que l'utilisation du noyau prédomine dans les systèmes hautes performances (32 et 64 bits), il est possible de bénéficier de son utilisation dans des appareils à faible consommation. Ces articles se concentrent sur les systèmes d'exploitation, à la fois en général et avec une implémentation spécifique.

Pourquoi utiliser le système d'exploitation?

Voyons pourquoi les systèmes d'exploitation sont utilisés en principe. Les explications sont nombreuses, certaines dépendent à la fois du facteur humain et des caractéristiques techniques. Je me souviens de l'histoire. Dans l'un de nos bureaux, il y avait un coin cuisine où vous pouviez faire du café. Sur la porte, il y avait un panneau avec l'inscription: "Veuillez ne pas fermer la porte." En dessous, quelqu'un a écrit: "Pourquoi pas?", À quoi quelqu'un d'autre a répondu: "Parce que." Une version très abrégée de l'expression "parce que nous vous disons de faire exactement cela." Pour les mêmes raisons, les systèmes d'exploitation sont utilisés sur certains systèmes, simplement parce que cela doit être fait.

Une autre explication est l'utilisation d'applications de bureau. Par où commencer si vous écrivez des logiciels pour PC ou Mac? Vous allumez l'ordinateur, démarrez Windows / Linux ou macOS et lancez la programmation. Avoir un système d'exploitation est une condition donnée, et il fournit un certain nombre de services utiles. Il est peu probable que vous décidiez de repartir de zéro lors de la programmation du bare metal. Par conséquent, il n'est pas surprenant qu'un ingénieur qui a de l'expérience en écriture de logiciels, mais pour qui le firmware est nouveau, s'appuie sur la présence d'un système d'exploitation dans le système qu'il développe.

Il convient de noter un aspect clé du système d'exploitation de bureau que les utilisateurs connaissent est l'interface utilisateur (UI). Demandez à quelqu'un ce qu'est Windows et il répondra qu'il s'agit de fenêtres, de menus, de boîtes de dialogue, d'icônes, mais le système de fichiers, la communication inter-programme et la possibilité d'interagir avec d'autres systèmes sont rarement mentionnés. C'est la principale différence entre le bureau et le système embarqué: ce dernier peut ne pas avoir d'interface utilisateur, et si c'est le cas, c'est assez simple. Il s'agit de la première des nombreuses différences clés:

• Un système intégré exécute généralement une seule application logicielle de la mise sous tension à la mise hors tension.
• Les systèmes embarqués ont des ressources limitées. La quantité de mémoire peut être assez grande, mais pas le fait qu'elle puisse être étendue; Le processeur a une puissance limitée.
• De nombreuses applications intégrées fonctionnent en temps réel. Plus d'informations à ce sujet dans l'article ci-dessous.
• Les outils de développement du micrologiciel sont spécialisés et exécutés sur l'ordinateur hôte (tel qu'un PC) et non sur le système cible.
• La mise à jour du firmware est un processus complexe. Malgré les opportunités qui apparaissent en raison des appareils connectés, les mises à jour du micrologiciel pendant le fonctionnement ne sont toujours pas la norme (contrairement aux mises à jour et correctifs réguliers (correctifs) utilisés pour les logiciels de bureau).

Avant d'examiner comment structurer les applications intégrées, nous comprendrons les concepts utilisés sur les ordinateurs pour exécuter des programmes à l'aide du système d'exploitation.

Tout d'abord, il y a une exécution de programmes de style DOS, lorsque les programmes sont exécutés en alternance.



Chaque programme est lancé, mis en œuvre et terminé. Nous utilisons, disons, le programme 1, puis le programme 2, puis peut-être faire une pause, passer au programme 3, puis revenir au programme 2. La deuxième utilisation du programme 2 recommence: le lancement ne démarre pas là où nous nous sommes arrêtés cela (sauf dans les cas où la demande elle-même ne fournit pas une telle possibilité).

Après DOS, les choses se sont un peu compliquées, car Windows est devenu monnaie courante. L'exécution de programmes de style Windows signifie l'exécution de plusieurs programmes en mode multithread.



Dans ce mode, il semble que les programmes s'exécutent en même temps, et Windows contrôle cette illusion. Tout d'abord, le programme 1 démarre, puis en même temps le programme 2 démarre, puis le programme 3. Le programme 2 se termine, les programmes 1 et 3 sont toujours en cours d'exécution. Le programme 3 se termine, seul le programme 1 reste. Plus tard, le programme 2 reprend et le programme 1 se termine, seul le programme 2 reste. Il s'agit d'un déroulement réaliste des événements lorsque Windows est utilisé par un utilisateur ordinaire. Le système d'exploitation alloue des ressources pour que tous les programmes utilisent correctement le processeur. Il permet également une communication facile entre les programmes (par exemple, le presse-papiers) et contrôle l'interface utilisateur.

Certains périphériques portables nécessitent plus de flexibilité que DOS ne peut en offrir, mais étant donné les ressources limitées, des frais généraux plus faibles sont nécessaires que Windows. En conséquence, nous avons l'exécution de programmes dans le style d'iOS, à savoir:



Les programmes sont lancés un à la fois, mais leur statut est automatiquement enregistré afin que vous puissiez continuer au même endroit lors de la fermeture. Par exemple, le programme 1 démarre, puis s'arrête pour utiliser le programme 2, puis, par exemple, l'appareil s'éteint pendant un certain temps. Lors de la reprise, le programme 3 est chargé (l'état du programme 2 a été enregistré automatiquement), puis l'utilisateur revient au programme 2, en continuant à y travailler. Je comprends que le modèle d'exécution d'une application iOS est beaucoup plus compliqué que celui décrit ci-dessus, cependant, cette description n'est qu'un bref résumé de la perception initiale de l'utilisateur.

La plupart des applications intégrées ne correspondent à aucun des modèles ci-dessus. En règle générale, l'appareil démarre le programme à la mise sous tension et continue de fonctionner uniquement avec ce logiciel pendant une durée indéterminée. La structure d'un tel code doit être soigneusement pensée.

Modèles de micrologiciel

Les systèmes de bureau sont presque tous les mêmes. Du point de vue du programme d'application, tous les ordinateurs personnels avec Windows sont identiques. Les systèmes embarqués sont uniques: chacun est différent des autres. Les différences peuvent être techniques: type de processeur, taille de la mémoire, nombre de périphériques. Les aspects prioritaires des applications peuvent également différer en termes de vitesse, de consommation d'énergie, de sécurité et de fiabilité. Il peut y avoir des différences commerciales qui affectent les prix: les volumes de production et le choix entre du matériel personnalisé ou standard.

Ces différences sont importantes pour les développeurs embarqués. Par exemple, le choix des outils de développement (compilateurs, débogueurs, etc.) dépend du type de processeur. De nombreux facteurs influencent le choix du système d'exploitation ou même la décision de l'appliquer en principe. La structure logicielle (modèle logiciel) doit être soigneusement sélectionnée pour chaque application intégrée individuelle.

Selon les exigences de l'application, le logiciel embarqué peut avoir différentes structures de différents niveaux de complexité, par exemple:



La forme la plus simple est une structure fermée dans laquelle la même séquence d'actions est répétée. Si l'application est suffisamment simple pour pouvoir être implémentée de cette manière, c'est l'idéal: un code simple est fiable et compréhensible. Cependant, une telle structure est extrêmement sensible à la partie du code qui peut prendre trop de temps processeur, c'est-à-dire que certaines commandes sont exécutées si longtemps qu'elles retardent l'exécution d'autres tâches d'application. De plus, ce modèle n'est pas très évolutif: l'amélioration du code peut être un problème, car les modules complémentaires peuvent affecter les performances de l'ancien code.

Si quelque chose de plus compliqué est requis, vous pouvez essayer de placer une partie non critique du code dans la boucle principale et une partie sensible au temps dans le gestionnaire d'interruption (Interrupt Service Routines, ISR). Les actions du gestionnaire d'interruption sont fondamentalement assez courtes, n'effectuant que des tâches critiques et marquant des sections de la boucle principale pour terminer le travail dès que possible. Des difficultés peuvent survenir lorsqu'il est nécessaire de répartir le travail entre la boucle principale et le gestionnaire d'interruption (ainsi qu'entre plusieurs développeurs).

Pour une flexibilité d'application maximale, il sera nécessaire de le diviser en plusieurs programmes distincts et relativement indépendants (appelons-les tâches ou threads), qui seront exécutés en mode multi-thread. De petits gestionnaires d'interruption peuvent également être inclus dans le système, mais ils notifient principalement les tâches ou déclenchent une action. Pour ce faire, vous avez besoin d'un système d'exploitation ou au moins d'un noyau. L'utilisation du multithreading fournit non seulement une distribution flexible des fonctionnalités dans les logiciels, mais facilite également la distribution du travail entre les développeurs.

Qu'est-ce que le temps réel?

Plus tôt, j'ai écrit que de nombreuses applications embarquées fonctionnent en temps réel. Dans ce contexte, il est d'usage de parler de systèmes d'exploitation en temps réel, et non d'un simple OS. Définissons la terminologie.

«Un système d'exploitation en temps réel est un système dans lequel l'exactitude des calculs dépend non seulement de l'exactitude logique des calculs, mais également de la durée pendant laquelle le résultat sera atteint.

Si les contraintes de temps du système ne sont pas respectées, on pense qu’une défaillance du système s’est produite. »

Une caractéristique importante d'un tel système est sa prévisibilité ou, comme on dit souvent, le déterminisme.

Un système d'exploitation en temps réel n'est pas nécessairement très rapide, «temps réel» ne signifie pas toujours «temps vraiment rapide». Cela signifie que toute action nécessaire sera réalisée en temps opportun. Autrement dit, assez rapide, mais en même temps pas trop rapide (c'est-à-dire assez lent).

RTOS (lorsqu'il est utilisé correctement) fournit un contrôle très précis sur la distribution du temps processeur pour les tâches et, par conséquent, rend les applications complètement déterministes. La seule chose qui peut ruiner cette image, ce sont les interruptions. Il existe des RTOS qui contrôlent entièrement les interruptions. Leur travail consiste à gérer le service d'interruption dans le cadre du planificateur de tâches. Malgré le fait que cela devrait conduire à un comportement prévisible, ce mécanisme est assez compliqué et contient des frais généraux élevés.

La plupart des RTOS permettent simplement au gestionnaire d'interruption de "voler" le temps d'une tâche qui s'exécutait au moment de l'interruption. Ceci, à son tour, oblige le programmeur à écrire le code du gestionnaire d'interruption aussi court que possible. Par conséquent, nous avons une erreur admissible en temps réel. La seule difficulté est d'appeler les services RTOS dans le cadre d'une tâche de gestionnaire. Certains appels peuvent être assez inoffensifs, tandis que d'autres provoqueront un changement de contexte lors du retour d'une interruption. Cette situation doit être spécialement traitée, ce qui est possible avec l'aide de divers RTOS.

Source: https://www.embedded.com/design/operating-systems/4442900/Program-structure-and-real-time

Lorsque nous avons travaillé sur notre propre système d'exploitation OSRV MAX en temps réel (articles déjà publiés à ce sujet) , notre équipe a « découvert » le blog de Colin Walls, un expert en microélectronique et firmware de Mentor Graphics. Les articles semblaient intéressants, les traduisaient eux-mêmes, mais afin de ne pas "écrire sur la table", ils ont décidé de publier. J'espère qu'ils vous seront également utiles. Si c'est le cas, nous prévoyons de publier tous les articles traduits de la série.

À 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: http://blogs.mentor.com/colinwalls , e-mail: colin_walls@mentor.com

L'article 3 est publié ici.