Rtos

[invitea4a9cbca]

Bonsoir à toutes et à tous
quelle est la différence entre un programme qui utilise un OS et un autre qui utilise seulement des interruptions?
merci d'avance
-----

[vincent66]

Bonsoir,
Un OS permet non seulement de faire tourner un programme en "temps"réel" mais aussi de gérer un système de fichiers ...
Le temps réel est géré par l'OS , ce qui évite d'avoir à s'en préoccuper dans son programme, mais implique moins de souplesse ...
Vincent

[invitea4a9cbca]

Merci Vincent

...mais aussi de gérer un système de fichiers...
...Le temps réel est géré par l'OS , ce qui évite d'avoir à s'en préoccuper dans son programme

Pourriez vous mieux m'expliquer votre idée??

[invited3dcf66c]

Salut,
Imagine qu'on ait plusieurs programmes et que chacun a besoin d'avoir accès à au processeur pour travailler. Seulement il n'y a qu'un seul processeur, et un processeur ne sait faire qu'une seule chose à la fois. Dans un RTOS, chaque programme a un niveau de priorité. A priori, c'est le programme 1 ayant le niveau de priorité le plus haut qui s'exécute. Si ce denier n'a pas besoin du processeur (donc de s'exécuter) ou est bloqué à un instant donné, alors le système d'exploitation va exécuter un programme 2 moins prioritaire. Si entre temps, lorsque 2 tourne, un évènement fait que le programme 1 (plus prioritaire) a besoin de s'exécuter, l'OS va effectuer à nouveau ce qu'on appelle un changement de contexte pour refaire tourner le programme 1, en reprenant là où il s'était arrêté.
De cette manière, grâce à l'OS, on peut avoir l'impression que plusieurs programmes fonctionnent en même temps, alors qu'en réalité, ils se partagent le temps de calcul à tour de rôle. L'intérêt, c'est que ça simplifie, voire même ça rend possible, la programmation dans les cas où t'as pleins de trucs à faire en même temps, sans savoir forcément quand à priori.
Imagines par exemple que tu as une application dans laquelle il y a un écran et des données qui arrivent par Ethernet. Quand des données arrivent par Ethernet, il faut les traiter. L'Ethernet c'est rapide, on n'a pas le temps de trainer! Cette tâche sera prioritaire. Lorsqu'on n'a rien à traiter venant du réseau, on peut se permettre de traiter l'affichage. L'affichage c'est "lent", s'il y a quelques millisecondes de retard sur l'affichage de temps à autre, l'utilisateur ne le remarquera même pas.

[A voir en vidéo sur Futura]

[Jack]

Dans un RTOS, chaque programme a un niveau de priorité

Dans un OS classique aussi. Je dirais que dans un RTOS, le temps au bout duquel on est sur qu'une tâche s'exécutera est déterministe. Cela garantit des temps de réaction à des évènements par exemple.

Les interruptions c'est un mécanisme permettant la commutation des tâches.

A+

[invited3dcf66c]

Dans un OS classique aussi.

Pas nécessairement, il existe des OS où seul le round robin est appliqué, ou des OS coopératifs dans lesquels les programmes doivent inclure du code pour passer la main au suivant.

[Jack]

Pas nécessairement

Je n'ai pas dit le contraire. Je faisais juste remarquer que la priorité des tâches n'était pas spécifique aux RTOS.

A+

[invitea4a9cbca]

Merci de votre réponse

Salut,
Imagine qu'on ait plusieurs programmes et que chacun a besoin d'avoir accès à au processeur pour travailler. Seulement il n'y a qu'un seul processeur, et un processeur ne sait faire qu'une seule chose à la fois. Dans un RTOS, chaque programme a un niveau de priorité. A priori, c'est le programme 1 ayant le niveau de priorité le plus haut qui s'exécute. Si ce denier n'a pas besoin du processeur (donc de s'exécuter) ou est bloqué à un instant donné, alors le système d'exploitation va exécuter un programme 2 moins prioritaire. Si entre temps, lorsque 2 tourne, un évènement fait que le programme 1 (plus prioritaire) a besoin de s'exécuter, l'OS va effectuer à nouveau ce qu'on appelle un changement de contexte pour refaire tourner le programme 1, en reprenant là où il s'était arrêté.
De cette manière, grâce à l'OS, on peut avoir l'impression que plusieurs programmes fonctionnent en même temps, alors qu'en réalité, ils se partagent le temps de calcul à tour de rôle. L'intérêt, c'est que ça simplifie, voire même ça rend possible, la programmation dans les cas où t'as pleins de trucs à faire en même temps, sans savoir forcément quand à priori.
Imagines par exemple que tu as une application dans laquelle il y a un écran et des données qui arrivent par Ethernet. Quand des données arrivent par Ethernet, il faut les traiter. L'Ethernet c'est rapide, on n'a pas le temps de trainer! Cette tâche sera prioritaire. Lorsqu'on n'a rien à traiter venant du réseau, on peut se permettre de traiter l'affichage. L'affichage c'est "lent", s'il y a quelques millisecondes de retard sur l'affichage de temps à autre, l'utilisateur ne le remarquera même pas.

Si j'ai bien compris, si on a plusieurs tâches à exécuter en même temps et s'il n y a pas le RTOS alors ça risque de ne pas les exécuter simultanément. est ce juste?
Donc l'avantage majeur c'est le temps réel.

[Jack]

s'il n y a pas le RTOS alors ça risque de ne pas les exécuter simultanément

Dans tous les cas, un processeur ne pourra pas exécuter 2 tâches simultanément avec un processeur monocoeur). Il faut donc découper le temps et l'affecter séquentiellement à l'exécution de chacune des tâches.

Au minimum donc, un processseur sans OS pourra faire du multitâches à condition de générer une interruption périodiquement et de commuter de tâches à chaque fois, en n'oubliant pas de sauvegarder l'état du processeur.

A+

[invitea4a9cbca]

Merci Jack

Au minimum donc, un processseur sans OS pourra faire du multitâches à condition de générer une interruption périodiquement et de commuter de tâches à chaque fois, en n'oubliant pas de sauvegarder l'état du processeur.
A+

Quel est l'impact de la génaration d'une interruption périodiquement sur le fonctionnemnt du µC en générale??
merci

[Jack]

Merci Jack

Quel est l'impact de la génaration d'une interruption périodiquement sur le fonctionnemnt du µC en générale??
merci

Impact à quel point de vue? D'un point de vue temporel, il faut du temps pour switcher d'une tâche à l'autre car il faut sauvegarder/recharger le contexte propre à chaque tâche.

Si tu switches trop souvent, tu peux passer plus de temps à gérer le contexte qu'à exécuter la tâche. Si tu ne switches pas assez souvent, par exemple avec une interface graphique ou une entrée clavier, tu auras l'impression que ton système fonctionne de manière saccadée.

[invitea4a9cbca]

Merci Jack encore une fois
J'ai compris l'utilité du RTOS.
Autre question : ce Noyau Temps réel sera aussi chargé dans le mémoire de µC. Si oui, où exactement??

[invite05fc252b]

Elle vaut combien de points dans ton devoir maison cette question ?

[invitea4a9cbca]

Elle vaut combien de points dans ton devoir maison cette question ?

Vous êtes trompé! c'est pas un devoir.
J'essaye juste de comprendre le fonctionnement d'un RTOS. J'ai commencé par le livre de LABROSSE (µc/OS-II). Mais toujours il reste des idées qui sont incompréhensibles.
Si j'ai bien compris, ce noyau c'est aussi un programme sous formes des fichier .c. Après avoir généré l'exécutable. j'aimerai savoir l'emplacement de ce noyau dans la mémoire.
J'ai pas bien compris ce point car ce noyau gère aussi la mémoire !!
Quelqu'un pourra m'aider à comprendre ce point.
Merci

[Jack]

Merci Jack encore une fois
J'ai compris l'utilité du RTOS.
Autre question : ce Noyau Temps réel sera aussi chargé dans le mémoire de µC. Si oui, où exactement??

Ca dépend de la cible. Il peut être chargé en RAM au boot ou s'exécuter en ROM.

J'ajoute que la mémoire (ROM ou RAM) sera souvent externe au µC.

A+

[invitea4a9cbca]

Ca dépend de la cible. Il peut être chargé en RAM au boot ou s'exécuter en ROM.

J'ajoute que la mémoire (ROM ou RAM) sera souvent externe au µC.

A+

ça veut dire que la mémoire interne n'est pas suffisantes??
Autre question : Avant de lancer l'exécution d'un programme, on le recopie au préalable dans la RAM puis on lance l'exécution.
Pourquoi ne pas exécuter le programme dans la mémoire FLASH??

[Jack]

ça veut dire que la mémoire interne n'est pas suffisantes??

Oui, certains µC ont trop peu de mémoire. Mais il existe des rtos plus ou moins sophistiqués. Certains sont taillés pour rentrer dans de tout petis µC. Par exemple:
http://helium.sourceforge.net/index.html

Autre question : Avant de lancer l'exécution d'un programme, on le recopie au préalable dans la RAM puis on lance l'exécution.

J'ai pourtant dit plus haut que l'exécution pouvait se faire en RAM ou en ROM (ou en flash si tu préfères, ce qui reviens au même une fois le code chargé).

[invitea4a9cbca]

Bonjour Jack
Merci de votre réponse
lorsqu'on charge un programme dans un calculateur, l'exécution d'un programme signifie t il la commande des interrupteurs (transistors) existant à l’intérieure de ce calculateur ???

[invited3dcf66c]

Oui, comme dans tout circuit numérique. Seulement est-ce qu'il est nécessaire de s'en soucier? Pas nécessairement. Les instructions que tu lui donnes sont des instructions logiques ou arithmétiques. Ce qui t'importe, c'est le résultat, et éventuellement en combien de temps c'est fait. Comment agit chaque transistor n'a, pour le programmeur, aucun intérêt (si ce n'est les étages de sorties si tu doit concevoir aussi le hardware). Vue la complexité des microprocesseurs actuels (le coeur d'un ARM9, déjà une belle bête tout de même, contient 111 000 transistors, auxquels il faut ajouter tous les périphériques) il serait de toutes façons illusoire de vouloir contrôler chaque transistor.

[invitea4a9cbca]

Merci de votre réponse

Oui, comme dans tout circuit numérique. Seulement est-ce qu'il est nécessaire de s'en soucier? Pas nécessairement. Les instructions que tu lui donnes sont des instructions logiques ou arithmétiques. Ce qui t'importe, c'est le résultat, et éventuellement en combien de temps c'est fait. Comment agit chaque transistor n'a, pour le programmeur, aucun intérêt (si ce n'est les étages de sorties si tu doit concevoir aussi le hardware). Vue la complexité des microprocesseurs actuels (le coeur d'un ARM9, déjà une belle bête tout de même, contient 111 000 transistors, auxquels il faut ajouter tous les périphériques) il serait de toutes façons illusoire de vouloir contrôler chaque transistor.

J'aimerai juste savoir comment l’exécution fonctionne? mais comme vous m'avez dit, le fonctionnement interne n'a aucun intérêt. Puisqu'on a déjà des instructions qui sont compréhensible par le programmeur.
Autre question : Qui se charge d'exécuter le programme?? dés qu'on alimente le µC, le programme s’exécute tout seule ???

[invited3dcf66c]

Dans ton processeur, tu as un bloc très important appelé Unité Algorithmique et Logique. Tu peux voire ça comme une boite avec une entrée pour une instruction, deux entrées pour les opérandes et une sortie. L'entrée pour l'instruction te permet de choisir ce que tu vas faire (addition, soustraction, OU logique, accès mémoires...), l'UAL appliquera cette opération aux deux opérandes et sortira le résulta sur la sortie. Le rôle du processeur est donc d'aller chercher à tour de rôle dans la mémoire les instructions et les opérandes, de les mettre en entrée de l'UAL et de récupérer ce qui sort.
C'est avec ce cycle de base que l'on fait tout. Après ce que j'ai décrit là c'est vraiment le processeur élémentaire, et j'ai omis pleins de choses pour simplifier. Parce qu'il existe pleins de mécanismes plus ou moins modernes pour réaliser et optimiser tout ce que l'on peut faire.

[invitea4a9cbca]

Dans ton processeur, tu as un bloc très important appelé Unité Algorithmique et Logique. Tu peux voire ça comme une boite avec une entrée pour une instruction, deux entrées pour les opérandes et une sortie. L'entrée pour l'instruction te permet de choisir ce que tu vas faire (addition, soustraction, OU logique, accès mémoires...), l'UAL appliquera cette opération aux deux opérandes et sortira le résulta sur la sortie. Le rôle du processeur est donc d'aller chercher à tour de rôle dans la mémoire les instructions et les opérandes, de les mettre en entrée de l'UAL et de récupérer ce qui sort.
C'est avec ce cycle de base que l'on fait tout. Après ce que j'ai décrit là c'est vraiment le processeur élémentaire, et j'ai omis pleins de choses pour simplifier. Parce qu'il existe pleins de mécanismes plus ou moins modernes pour réaliser et optimiser tout ce que l'on peut faire.

Si j'ai bien compris,toutes les instructions sont des opérations logiques !?

[Jack]

On ne va pas s'en sortir. Il faut que tu lises un cours sur l'architecture des ordinateurs. Celui-ci par exemple:
http://www.loria.fr/~jloncham/polyArchi.pdf

ou celui-là:
http://rmdiscala.developpez.com/cour...html#basesinfo

[invitea4a9cbca]

Merci à vous tous et toutes.