Réel

Quand avez-vous besoin d’utiliser un système d’exploitation en temps réel (RTOS) pour un projet embarqué ? Qu’est-ce que cela apporte et quels en sont les coûts ? Heureusement, il existe des définitions techniques strictes, qui peuvent également aider à déterminer si un RTOS est le bon choix pour un projet.

La partie « temps réel » du nom couvre notamment le principe de base d'un RTOS : la garantie que certains types d'opérations se termineront dans un laps de temps prédéfini et déterministe. Au sein du « temps réel », nous trouvons des catégories distinctes : temps réel dur, ferme et souple, avec des pénalités de moins en moins sévères en cas de non-respect des délais. À titre d'exemple de scénario en temps réel difficile, imaginez un système dans lequel le contrôleur intégré doit répondre aux données entrantes des capteurs dans un laps de temps spécifique. Si le non-respect d’un tel délai a pour conséquence de briser les composants en aval du système, au sens figuré ou littéral, le délai est difficile.

En comparaison, le temps réel doux serait le genre d'opération dans laquelle il serait formidable que le contrôleur réponde dans ce laps de temps, mais si cela prend un peu plus de temps, ce serait également très bien. Certains systèmes d'exploitation sont capables de fonctionner en temps réel, alors que d'autres ne le sont pas. C'est principalement un facteur de leur conception fondamentale, en particulier du planificateur.

Dans cet article, nous examinerons divers systèmes d'exploitation, pour voir où ils s'intègrent dans ces définitions et quand vous souhaiteriez les utiliser dans un projet.

Différents systèmes d'exploitation intégrés s'adressent à différents types de systèmes et disposent de différents ensembles de fonctionnalités. Le plus minimaliste des RTOS populaires est probablement FreeRTOS, qui fournit un planificateur et avec lui des primitives multithread comprenant des threads, des mutex, des sémaphores et des méthodes d'allocation de tas sécurisées pour les threads. En fonction des besoins du projet, vous pouvez choisir parmi un certain nombre de méthodes d'allocation dynamique et autoriser uniquement l'allocation statique.

À l’autre extrémité de l’échelle, nous trouvons des RTOS tels que VxWorks, QNX et Linux avec des correctifs de planification en temps réel appliqués. Il s'agit généralement de systèmes d'exploitation certifiés POSIX ou compatibles, qui offrent la commodité de développer une plate-forme hautement compatible avec les plates-formes de bureau classiques, tout en offrant un certain degré de garantie de performances en temps réel, grâce à leur modèle de planification.

Encore une fois, un RTOS n'est un RTOS que si le planificateur garantit un certain niveau de déterminisme lors du changement de tâche.

Même en dehors du domaine des systèmes d’exploitation, les performances en temps réel des processeurs peuvent différer considérablement. Cela devient particulièrement évident lorsque l’on examine les microcontrôleurs et le nombre de cycles requis pour qu’une interruption soit traitée. Pour les microcontrôleurs Cortex-M populaires, par exemple, la latence d'interruption est comprise entre 12 cycles (M3, M4, M7) et 23+ (M1), dans le meilleur des cas. Divisez par la vitesse du processeur et vous obtenez environ un quart de microseconde.

En comparaison, lorsque nous examinons la gamme de microcontrôleurs 8051 de Microchip, nous pouvons voir dans le « Manuel matériel des microcontrôleurs Atmel 8051 » dans la section 2.16.3 (« Temps de réponse ») qu'en fonction de la configuration de l'interruption, la latence de l'interruption peut être n'importe où. de 3 à 8 cycles. Sur les plates-formes x86, l'histoire est encore plus compliquée, en raison de la nature quelque peu alambiquée des IRQ x86. Encore une fois, une fraction de microseconde.

Cette latence impose une limite absolue aux meilleures performances en temps réel qu'un RTOS peut atteindre, bien qu'en raison de la surcharge liée à l'exécution d'un planificateur, un RTOS ne se rapproche pas de cette limite. C'est pourquoi, pour obtenir les meilleures performances en temps réel, une approche déterministe à boucle d'interrogation unique avec des routines de gestion d'interruption rapides pour les événements entrants est de loin la plus déterministe.

Si l'interruption, ou tout autre changement de contexte, coûte des cycles, l'exécution plus rapide du processeur sous-jacent peut également évidemment réduire la latence, mais s'accompagne d'autres compromis, dont le moindre n'est pas la consommation d'énergie plus élevée et les besoins de refroidissement accrus.

Comme le démontre FreeRTOS, le principal objectif de l'ajout d'un système d'exploitation est d'ajouter la prise en charge du multitâche (et du multithreading). Cela signifie un module de planification qui peut utiliser une sorte de mécanisme de planification pour découper le temps processeur en « tranches » dans lesquelles différentes tâches ou threads peuvent être actifs. Bien que le planificateur multitâche le plus simple soit un planificateur de style coopératif, dans lequel chaque thread cède volontairement pour laisser les autres threads faire leur travail, cela présente le net inconvénient que chaque thread a le pouvoir de tout gâcher pour les autres threads.