Comment fonctionnent les systèmes D'exploitation en temps réel?

Dans RTOSes, les paramètres les plus critiques à prendre en compte sont les latences inférieures et le déterminisme temporel. Ce qu'il fait agréablement en suivant certaines politiques et astuces.

Alors que dans GPOSes, avec des latences acceptables, les paramètres critiques sont un débit élevé. vous ne pouvez pas compter sur les GPOS pour le déterminisme du temps.

Les RTOSes ont des tâches beaucoup plus légères que les processus/threads dans les GPOS.

Ce n'est pas qu'ils sont capables de respecter des délais, c'est plutôt qu'ils ont des délais fixés alors que dans un OS régulier il n'y a pas de tel délai.

Dans un système d'exploitation régulier, le planificateur de tâches n'est pas vraiment strict. C'est-à-dire que le processeur exécutera tant d'instructions par seconde, mais il peut parfois ne pas le faire. Par exemple, une tâche peut être préemptée pour permettre l'exécution d'une tâche de priorité plus élevée (et peut être plus longue). Dans RTOS le processeur exécutera toujours le même nombre de tâche.

En outre, il y a généralement une limite de temps pour les tâches à terminer après quoi un échec est signalé. Cela ne se produit pas dans le système d'exploitation régulier.

Évidemment, il y a beaucoup plus de détails à expliquer, mais ce qui précède sont deux des aspects de conception importants qui sont utilisés dans RTOS.

Votre RTOS est conçu de telle sorte qu'il peut garantir des horaires pour les événements importants, comme la gestion des interruptions matérielles et le réveil des processus de sommeil exactement quand ils doivent l'être.

Cette synchronisation exacte permet au programmeur d'être sûr que son (disons) stimulateur va produire une impulsion exactement quand il en a besoin, pas quelques dizaines de millisecondes plus tard parce que le système d'exploitation était occupé avec une autre tâche inefficace.

C'est généralement un système d'exploitation beaucoup plus simple qu'un Linux à part entière ou Windows, tout simplement parce qu'il est plus facile d'analyser et de prédire le comportement du code simple. Il n'y a rien qui empêche un système d'exploitation à part entière comme Linux utilisé dans un environnement RTOS, et il a des extensions RTOS. En raison de la complexité de la base de code, il ne sera pas en mesure de garantir ses horaires à une échelle aussi petite qu'un système d'exploitation plus petit.

Le planificateur RTOS est également plus strict qu'un planificateur à usage général. Il est important de savoir que le planificateur ne va pas changer votre tâche priorité parce que vous avez été en cours d'exécution depuis longtemps et ne pas avoir d'utilisateurs interactifs. La plupart des OS réduiraient la priorité interne de ce type de processus pour favoriser les programmes interactifs à court terme où l'interface ne devrait pas être considérée comme étant en retard.

Vous trouverez peut-être utile de lire la source d'un RTOS typique. Il y a plusieurs exemples open-source là-bas, et les liens suivants ont donné dans un peu de recherche rapide:

• FreeRTOS
• eCos

Un RTOS commercial bien documenté, disponible sous forme de code source et facile à utiliser est µC/OS-II. Il a une licence très permissive pour un usage éducatif, et (une version légèrement obsolète de) sa source peut être avait lié dans un livre décrivant sa théorie de fonctionnement en utilisant l'implémentation réelle comme exemple de code. Le livre est MicroC OS II: le noyau en temps réel par Jean Labrosse.

J'ai utilisé µC / OS-II dans plusieurs projets au fil des ans, et je peux le recommander.

Je n'ai pas utilisé de RTOS, mais je pense que c'est comme ça qu'ils fonctionnent.

Il y a une différence entre" temps réel dur "et"temps réel doux". Vous pouvez écrire des applications en temps réel sur un non-RTOS comme Windows, mais elles sont "soft" en temps réel:

• En tant qu'application, je pourrais avoir un thread ou une minuterie que je demande à L'O/S de courir 10 fois par seconde ... et peut-être le faire, la plupart du temps, mais il n'y a aucune garantie qu'il sera toujours en mesure de ... ce manque de garantie est pourquoi il est appelé "doux". La raison pour laquelle le O / S pourrait ne pas être en mesure de le faire est qu'un thread différent pourrait garder le système occupé à faire autre chose. En tant qu'application, je peux augmenter ma priorité de thread par exemple HIGH_PRIORITY_CLASS, mais même si je fais cela, L'O/S n'a toujours pas D'API que je peux utiliser pour demander une garantie que je serai exécuté à certains moments.

• Un O/s en temps réel 'dur' a (j'imagine) des API qui me permettent de demander des tranches d'exécution garanties. La raison pour laquelle les RTOS peut faire de telles garanties est qu'il est prêt à abandonner les threads qui prennent plus de temps que prévu / qu'ils ne sont autorisés.

Ce qui est important, ce sont les applications en temps réel, pas le système d'exploitation en temps réel. Habituellement, les applications en temps réel sont prévisibles: de nombreux tests, inspections, analyse WCET, preuves,... ont été effectuées qui montrent que les délais sont respectés dans toutes les situations spécifiées.

Il arrive que les RTOSes aident à faire ce travail (construire l'application et vérifier ses contraintes RT). Mais j'ai vu des applications en temps réel s'exécuter sur Linux standard, en s'appuyant davantage sur la puissance matérielle que sur la conception du système d'exploitation.

... Bien...

Un système d'exploitation temps réel essaie d'être déterministe et de respecter les délais, mais tout dépend de la façon dont vous écrivez votre demande. Vous pouvez faire un RTOS très non en temps réel si vous ne savez pas comment écrire du code "correct".

Même si vous savez écrire le code approprié: Il est plus question d'essayer d'être déterministe que d'être rapide.

Quand on parle de déterminisme, c'est

1) déterminisme des événements

Pour chaque ensemble d'entrées, les états suivants et les sorties d'un système sont connues

2) déterminisme temporel

... le temps de réponse pour chaque ensemble de sorties est également connu

Cela signifie que si vous avez des événements asynchrones comme des interruptions, votre système n'est plus à proprement parler déterministe temporel. (et la plupart des systèmes utilisent des interruptions)

Si vous voulez vraiment être déterministe sondage tout.

... mais peut-être qu'il n'est pas nécessaire d'être 100% déterministe

La réponse du manuel / de l'entrevue est "préemption déterministe". Le système est garanti pour transférer le contrôle dans une période de temps limitée si un processus de priorité plus élevée est prêt à fonctionner (dans la file d'attente prête) ou une interruption est affirmée (généralement entrée externe à la CPU/MCU).

En fait, ils ne garantissent pas le respect des délais; ce qu'ils font qui les rend vraiment RTOS est de fournir les moyens de reconnaître et de traiter les dépassements de délais. Les systèmes RT "durs" sont généralement ceux où manquer une date limite est désastreux et une sorte d'arrêt est nécessaire, alors qu'un système RT "doux" est un système où continuer avec des fonctionnalités dégradées est logique. De toute façon, un RTOS vous permet de définir des réponses à de tels dépassements. Les systèmes D'exploitation non RT ne détectent même pas les dépassements.

"fondamentalement, vous devez coder chaque "tâche" dans le RTOS de sorte qu'ils se termineront dans un temps fini."

C'est en fait correct. Les RTOS auront une tique de système définie par l'architecture, disons 10 millisec., avec toutes les tâches (threads) à la fois conçues et mesurées pour compléter dans des délais spécifiques. Par exemple, dans le traitement de données audio en temps réel, où la fréquence d'échantillonnage audio est de 48 kHz, il y a un temps connu (en millisecondes) pendant lequel le pré-tampon deviendra vide pour toute tâche en aval qui traite les données. Par conséquent, l'utilisation du RTOS nécessite un dimensionnement correct des tampons, l'estimation et la mesure du temps nécessaire et la mesure des latences entre toutes les couches logicielles du système. Ensuite, les délais peuvent être respectés. Sinon, les demandes manqueront les délais. Cela nécessite une analyse du traitement des données dans le pire des cas sur l'ensemble de la pile, et une fois que le pire des cas est connu, le système peut être conçu pour, disons, 95% de temps de traitement avec un temps d'inactivité de 5% (ce traitement peut ne jamais se produire dans une utilisation réelle, car le traitement des données dans le pire des cas peut ne pas être un État autorisé dans toutes les couches à un moment donné).

Exemples de diagrammes de synchronisation pour la conception d'une application réseau de système d'exploitation en temps réel sont dans cet article à EE Times, Mode D'emploi du produit: Améliorer la qualité de la voix en temps réel dans une téléphonie VoIP la conception de http://www.eetimes.com/design/embedded/4007619/PRODUCT-HOW-TO-Improving-real-time-voice-quality-in-a-VoIP-based-telephony-design

Fondamentalement, vous devez coder chaque "tâche" dans le RTOS de sorte qu'ils se termineront dans un temps fini.

En outre, votre noyau allouerait des quantités spécifiques de temps à chaque tâche, dans une tentative de garantir que certaines choses se sont produites à certains moments.

Notez que ce n'est pas une tâche facile à faire cependant. Imaginez des choses comme les appels de fonctions virtuelles, dans OO, il est très difficile de déterminer ces choses. En outre, un RTOS doit être soigneusement codé en ce qui concerne la priorité, il peut exiger qu'une tâche de haute priorité soit donnée à la CPU en x millisecondes, ce qui peut être difficile à faire en fonction du fonctionnement de votre planificateur.