Temps réel ?????

[flyingman]

Salut.

Qu'est ce que la programmation temps reele?

Quel sont les inconnues à determiner?( frequence du proc par ex?)

Peut on en faire avec n'importe quels langages? ou bien uniquement avec un l'assambleur?

Merci.
-----

[inviteba3c7366]

?

tu parle de language et puis tu parle de l assembleur ??

et si tu parle de programation quel raport avec la fréquence du processuer ?

j avous n avoir rien compris à ton msg

[invitedebe236f]

c est le genre de pgm qui recoit des donnees et qui doit les traite imediatement et prendre une decision ( il a pas des minutes)
ex pgm informatique d un airbus si tous d un coup il recoit des donnee de turbulance ou autre il doit reagir immediatement

donc la particularite c est qu il travaille par interuption
pas question qu un bout d un pgm bloque un autre pgm s il a besoin de reagir

[flyingman]

rep cricri : ah ok ! je pensais qu'il y avait aussi un calcul du temps des intructions car tu dois avoir, meme si il y a une interruption, un decalage entre le signale e tle traitement de ce signale, non?
Ex: Si une sonde altimetrique capte une variation de pression, alors il y aura un traitement avant affichage( sur l'altimetre ), donc decalage avec la realité !

MErci

[A voir en vidéo sur Futura]

[vanos]

Salut.

Qu'est ce que la programmation temps reele?

Quel sont les inconnues à determiner?( frequence du proc par ex?)

Peut on en faire avec n'importe quels langages? ou bien uniquement avec un l'assambleur?

Merci.

Salut,
Simplement programmer en temps réel c'est utiliser un language qui n'a pas besoin de compilation pour fonctionner, autrement dit qui peut être testé et corrigé immédiatement.

tu parle de language et puis tu parle de l assembleur ??

Je te signale que l'Assembler, prononcer "assembleur", est un langage de programmation déjà trés ancien mais fort souple.
Ciao

[invite36602837]

Salut,
Simplement programmer en temps réel c'est utiliser un language qui n'a pas besoin de compilation pour fonctionner, autrement dit qui peut être testé et corrigé immédiatement.

Ca c'est plutot les language interprété (pas besoin de compilation) comme le VBScript, le PHP, le HTML (bref, les language web en general, ainsi que tout les language de script, meme les .bat sont des programmes interprété, par DOS). Et en plus, ces language ne sont pas capable de faire du temps reel, puisque en fait il fonctionne sur un PC virtuel (un interpreteur, qui lui fonctionne soit sur le CPU, soit sur un autre PC virtuel, un autre interpreteur), contrairement au language compiler qui eux fonctionne directement sur le CPU (certain OS peuvent meme etre courtcircuité par les programmes, comme DOS et la serie des Win9x).

Le temps reel, c'est simplement faire fonctionné un programme a la vitesse maxi du CPU. Le concept de temps reel n'existe pas en info, puisque les programme sont executé sequentiellement. Après, y a plein de technique pour faire tourné tout ou parti du programme presque en temps reel (les interruption sont une technique). Par ex : un jeu peut etre cadencé par un timer, qui va executé tout les X milliseconde les calcul. Comme c'est executé tout les X milliseconde, le CPU n'est pas utilisé a 100%, donc ce n'est pas du temps reel (par contre, on connais très bien la base de temps, ce qui permet de faire boucler le programme dans des base de temps différent, 1 pour l'affichage, tout les 10milliseconde, et une pour l'IA, tout les 50 milliseconde, par ex). Le temps reel, ca serais de cadencé le jeu sur la vitesse necessaire pour faire un cycle. Ca veux dire qu'on rentre dans la boucle de calcul, puis quant elle est fini, on y rerentre immediatement, comme ca, les calculs s'effectue a la vitesse maxi (pas de temps d'attente entre 2 boucle). Mais fait tourné un programme en temps reel sur un 386, et tu pourra presque voir chaque instruction s'executé tellement le CPU est lent a la base (du 10Mhz par rapport a du 3Ghz, on voit la différence) et ton programme en temps reel sur ton 3Ghz deviendra un programme totalement inutilisable sur ton 386 (parce que la base de temps d'un 386 est bien inferieur a celle d'un 3Ghz, question de frequence d'execution).

Je te signale que l'Assembler, prononcer "assembleur", est un langage de programmation déjà trés ancien mais fort souple.
Ciao

L'assembleur n'est pas vraiment un language a part entiere, c'est plutot la correspondance en code "textuel" du code machine (le code binaire, les instruction CPU). Le language le plus ancien, c'est le FORTRAN (FORmula TRANsletor), et l'assembleur existait deja avant (il n'est donc pas considerer comme un language a part entiere, du point de vue historique). L'assembleur depend du type du CPU, pas de se qu'on veux faire. Un code assembleur x86 est bien différent d'un code assembleur de Motorola. Alors que le C sur x86 ou sur motorola est le meme. C'est d'ailleurs en partie pour ca qu'on a crée des language de programmation compiler, pour se passé de l'assembleur (c'est le compilateur qui traduit le code C ou VB en code binaire, donc assembleur, qui correspond au CPU pour lequel le compilateur a été crée). Ca permet de faire un code pour PSII sur un PC, vu que c'est le compilateur qui traduit la logique (le source) dans l'un ou l'autre des codes assembleur (qui va nous donné un .exe, sous windows). Parce que vous imaginé les ingenieurs apprendre l'assembleur du x86, du motorola, des PIC, des CPU Texas Instrument, etc... ??? Moi pas (et je suis informaticien). Je prefere apprendre le C, en connaissant les subtilité du motorola et du x86, plutot que de connaitre 2 code assembleur différent. Parce que deja bien maitrisé rien qu'un language, c'est pas evident, alors 36 et notre tete explose.

[invitedebe236f]

un systeme d exploitation est un temp reel
quand tu tape une touche que tu bouge la sourie tu declenche une interuption qui traite tous de suite
mais bon on fait rarement du temp reel ou alors sans le savoir quand tu ecrit une procedure sur un onclick onkeypress par exemple

[invite36602837]

un systeme d exploitation est un temp reel

Faux. Un systeme d'exploitation n'est pas temps reel. En fais, ca sers a rien d'attendre d'un PC qu'il soit temps reel, puisque physiquement il ne peut pas. Le seul moyen que tu as de faire du temps reel, c'est multiplié les CPU.

quand tu tape une touche que tu bouge la sourie tu declenche une interuption qui traite tous de suite

Faux. Quant je bouge ma souris, la boule (ou le laser) va enregistrer des mouvements qu'il transforme en impulsion. Ces impulsion sont transportée par les cable jusqu'a l'interface (la prise). Derriere l'interface, un petit composant va retransformé les signaux en bit (si ce n'est pas deja fais directement dans le peripherique). Cette transformation prend deja du temps (que se soit sur le CPU ou sur un composant dedié). Ensuite, les bit (qui sont en fait des impulsion) vont etre "déposé" sur le bus d'adresse et de commande, tandis qu'une interruption va etre "emise". A ce moment, le CPU recoit une impulsion sur son port d'interruption. A ce moment, le compteur interne va etre modifié pour permettre au CPU de recevoir les information en provenance des bus d'adresse (pour savoir quel peripherique dialogue), le bus de données (pour savoir ce qui se passe) et le bus de commande (pour savoir si on lit ou si on ecrit sur le bus de données). Tout ceci prend egalement des cycle, mais en plus les prend au CPU qui pendant se temps ne peut rien faire d'autre, y compris executé l'OS. Le CPU prend les valeurs du bus de données et les place en memoire RAM. Puis, le compteur interne va denouveau changé pour pointé vers la RAM et la suite du programme. Si c'est l'OS qui prend la main a ce moment (ce qui est loin d'etre un cas general, typiquement le cas d'un ralentissement du PC), il va aller en memoire, taper dans l'adresse ou on a précédemment enregistrer les valeurs de la souris et deplacé le pointeur sur l'ecran. Ca c'est le cas du deplacement du pointeur. Dans le cas du clic, c'est encore pire, parce qu'après avoir enregistrer le clic (ou plutot l'impulsion correspondante), il va falloir balayé l'ecran (ou se qui représente l'ecran en memoire) pour savoir ce qu'est entrain de pointé la souris (un icone, un bouton, donc un code d'un autre programme, un texte, etc...). Puis quant on as trouvé, y a plus qu'a executé le programme corespondant (qui prend lui aussi des cycle au CPU, donc au autre programmes). Et tout ce processus ce fait sequenciellement, en interrompant justement le reste. Alors dire qu'un PC est en temps reel a cause des interruption, c'est ne pas savoir ce qu'est une interruption (interuption signifie interompre en francais, et c'est bien ce que c'est, une interuption d'execution, donc le contraire du temps reel). La seul différence qu'il y a entre le temps reel et la patiente, c'est le nombre de cycle par seconde. Le cerveau humain est cadencé a 25hz (25 image par seconde) si le PC va a 26 images, on est en temps reel pour le cerveau humain (on ne vois pas les calcul, parce qu'ils ont lieu entre nos propre operation, on ne peut donc pas les observé, d'ou l'impression de vitesse), mais pas dans un vrai temps reel (qui serait une execution parallele). Si le PC va en dessous de 25 images, on constate des ralentissement, alors que le PC va toujours a la meme vitesse (le CPU n'as pas de boite de vitesse, c'est 200Mhz ou rien, pas 124,65 Mhz. Ce qui fais ralentir les programme (jeux, OS, applic), c'est un programme qui monopolise le CPU pour lui tout seul). Et il faut savoir que les OS ne sont pas des OS temps reel, mais des OS multitache, parce qu'ils sont capable de partagé les cycle entre les applic. Ex :

Word, VirusScan, un jeu et windows
base de temps milliseconde, T=0.
T=0, Windows fait qqch
T=10 windows va en memoire et execute le code correspondant a l'adresse memoire de l'exe de word
T=11 Word s'execute
T=19 Word redonne la main a windows
T=20 Windows fais qqch
T=25 Windows pointe en memoire vers l'exe de l'antivirus
T=26 L'antivirus demande l'accès au disque
T=27 l'antivirus pointe en memoire vers l'adresse de la DLL chargé du dialogue avec le disque (DLL windows)
T=28 la DLL (donc windows) fait ce que l'antivirus lui demande
T=35 la DLL place le fichier en memoire
T=36 la DLL redonne la main a l'antivirus (en pointant vers l'adresse memoire correspondante)
T=37 l'antivirus scan le fichier a la recherche de virus
T=38 Comparaison du premiere bit du fichier avec le premier bit de la signature d'un virus connu
T=39 Comparaison du 2eme bit
T=40 L'antivirus redonne la main a windows
T=41 etc..........

Ca c'est le fonctionnement interne d'un PC. Et tout les informaticien te dirons la meme chose, un CPU execute en sequencielle, il ne peut donc pas, physiquement parlant, etre capable de temps reel, puisque le temps reel suppose la possibilité d'execution parallele. Cette possibilité n'est donées que par les machine multiprocesseurs (et encore, les CPU ne sont pas a egalité, meme si les frequence sont les memes).

[invitedebe236f]

oula tu cherche la petite bete
si je me souviens bien de mes cours d informatique "le temp reel"
c est une programation a base d interruption plus ou moins prioritaire

entre le moment ou je bouge la sourie ou que je tape une touche evidement que c est pas instantane (impossibilite) mais c est le plus cours possible

[invite36602837]

oula tu cherche la petite bete
si je me souviens bien de mes cours d informatique "le temp reel"
c est une programation a base d interruption plus ou moins prioritaire

entre le moment ou je bouge la sourie ou que je tape une touche evidement que c est pas instantane (impossibilite) mais c est le plus cours possible

Oui, je suis d'accord que les interuptions sont le moyen le plus rapide de dialoguer, mais le problème c'est que l'interruption interromp justement l'execution, donc tu passe du temps reel du programme X au temps reel du programme Y, mais le PC n'est pas en temps reel lui. Donc parler de temps reel c'est une question de marketing, pas une question de technique. Ce que je veux dire, c'est qu'il faut arreter de croire que l'info c'est tout beau, tout propre, tout facile. C'est un domaine complexe qui n'est pas accessible a tout le monde. Je dit pas ca par rapport a toi, je dit ca par rapport a ce que pense les gens du PC. Moi qui suis informaticien, qui depanne des utilisateur bete et mechant, j'ai des fois envie de leur dire que le PC ben ca s'apprend et c'est pas comme dit microsoft dans ces pub "Clé en main". Non, l'informatique c'est complexe et c'est un domaine a part, ou on reflechit différemment (justement pas en temps reel) et ou il faut comprendre la logique avant d'esperer faire quoique se soit de productif avec le PC. La secretaire qui veux faire du publipostage devra apprendre la logique du publipostage (creation du document de base et de la base de données des nom/adresses, sous excel ou sous une DB classique) meme si pour elle ca consiste a ecrire les adresses a un endroit precis. Pour le PC, ca implique de savoir ou on va chercher les info, de definir les providers (type ODBC ou lecture du fichier), ou on les place (dans quel fichier, donc gestion du disque, etc...) et a quelle emplacement du document. Tout ca la secretaire n'as pas conscience et quant ca bug, c'est toujours de la faute du PC, alors qu'elle a pt etre oublié de changé le nom du fichier, de definir le provider, elle a pt etre utilisé une premiere fois le fichier excel, comme ca marchait, elle la supprimé et maintenant ca marche plus alors que pour elle, y a plus besoin du fichier Excel. Si toi tu veux faire du temps reel, tu es obligé de reflechir de maniere sequencielle, parce que quant t'as un bug, tu doit remonté le temps pour savoir ou ce situe l'erreur. Et quant tu remonte le temps, tu le fais instruction par instruction, donc pas en temps reel. Je precise juste que la je parle de programme complexe, qui dialogue avec divers composant physique. Une calculette est en temps reel puisque en fait elle ne fais qu'attendre des evenements utilisateur. Mais c'est un cas special, la calculette. Quant justement tu as en meme temps des evenements utilisateur, des evements systeme et que tu tourne au dessus d'un OS, tu n'est pas en temps reel. C'est le cas d'un browser par exemple. Tu n'as jamais remarquer de temps en temps des ralentissement suivi d'acceleration brutale. Genre tu as windows qui se fige pendant 2 minutes. Pour essayé de le reveiller, on clic, on ouvre une applic, on en ferme une autre, rien ne se passe (plein de bug graphique, presque envie de faire un reboot) et tout d'un coup, y a tout qui bouge, les applic que tu voulais fermer se ferme, celle que tu voulais ouvrir s'ouvre, les clic en attente s'executent alors qu'au moment du reveil, tu avais laché la souris par desespoir, et ca devient la panique pendant 30sec parce que le PC fait plus tout a fait ce qu'on voulais. Mais on attend 30sec de plus, et le PC retombe sur ces pattes (si c'est un OS qui tiens la route, style 2k ou XP, pas 98 qui lui va te faire une erreur). Et si les interruptions marchais si bien, le ctrl-alt-del marcherait toujours (ce qui n'est pas le cas) puisque ctrl-alt-del est un code CPU (il marche que tu soit sous windows ou sous le chargement du PC, c'est donc une interruption materiel, pas logiciel comme la souris qui depend de l'OS).

Le temps reel n'existe pas (ou alors il faudrais un quartz qui soit capable d'evolué a une frequence qui soit superieur a la frequence maximale autorisée par les lois de la physique). Mais le "temps reel" (remarque les guillemet) est une maniere de bluffé l'utilisateur en allant plus vite que ce qu'il est capable de percevoir. Ca ne veux pas dire qu'a cette vitesse, on pourrait observé des phenomene physique très rapide (parce qu'ils sont pt etre effectué a une vitesse superieur a celle du PC, le PC est trop lent pour observé la reaction, on est donc loin du temps reel relatif à la reaction observée), ca veux simplement dire que l'utilisateur croit que le PC est en temps reel, comme toi actuellement (ce qui en plus pose des problème de comprehension quant ca bug, parce qu'il faut reexpliquer les choses a la personne, parce qu'elle a compris de travers). C'est pour ca que j'insiste sur le fait que le temps reel n'existe pas, histoire d'evité qu'on vienne après me dire "Ouais, mais si le PC est en temps reel, pourquoi il ralenti alors". Non il est pas en temps reel et il ne ralentie pas, il est simplement entrée dans une boucle infini qui interromp le reste des programme. Et voila la source du ralentissement (ou du "temps reel"), une monopolisation des cycles au profit d'une seule applic au detriment des autres. Ce que permettent les interruption justement. Et c'est pour ca je pense que ton prof t'as parler des interruption pour la prog "temps reel" (qui en fait n'existe pas reelement).

Un autre exemple de "temps reel", c'est la 3D, parce qu'elle est executé en parallele au CPU, sur le GPU (le CPU de la carte graphique). D'ailleurs, le "temps reel" graphique a du etre introduit a cause des jeux video, qui utilisait plus de cycle pour le graphisme que pour l'IA. On as donc decidé de crée un composant specifique qui se chargerais du graphisme, et c'est devenu les cartes acceleratrice 3D. Mais elle aussi ne sont pas en temps reel, puisque des fois on constate des ralentissement d'affichage (alors que l'IA continue elle a tournée, ce qui fais qu'on peut subir des explosions avant de voir partir les roquettes, bug connu dans Unreal Tournament 2000 quant on joue en reseau).

[flyingman]

Ok merci les gars pour ces multiples informations !!!
Je retiendrais du temps reele qu'il s'agis de programmation normale (langage compilé à base d'interruptions) et que pour bien faire il faudrait une machine multiprocesseur !

Merci.

[invite36602837]

(langage compilé à base d'interruptions)

Les interruption ne sont necessaire que si tu dialogue avec des elements exterieur. Si tu ne le fais pas, tu n'as plus qu'a gerer tes enchainement en interne, ce qui est deja complexe entre la gestion des evenements utilisateur et l'execution qui doit prendre en compte ces evenement, mais pas n'importe comment. Ca veux dire dans un jeu par exemple, que tu calcul le prochain niveau d'energie de la base, mais si le joueur ajoute un generateur, doit-il etre pris en compte immediatement ou au prochain cycle ??? Et s'il doit etre pris immediatement, comment faire pour, en plein dans une procedure, changé le comportement de ladit procedure afin qu'elle prennent en compte le dernier evenement. Perso, et je te le dit après avoir du gerer ce genre de cas (pour un jeu justement, mais pas seulement), que je prefere attendre le cycle suivant plutot que de me prendre la tete a modifié ma procedure en "temps reel". Mais j'ai choisit cette solution parce que mes cycle ne sont pas cadencé. Dans cet exemple, mon jeu fais, en moyenne, 1 cycle toute les 10 milliseconde (j'evolue a 100 frame et ca peut baissé jusqu'a 50, mais ca oscille entre 70 et 90 en moyenne), ce qui est presque la vitesse max (1 milliseconde etant la vitesse max, avec le language que j'utilise). Et l'avantage c'est que si un cycle me prend plus de 10 millisecond, j'ai pas de probleme de concurrence entre cycle, puisque il ne sont pas cadencé. Si ca avait été le cas, j'aurais du me prendre la tete pour savoir quant est-ce que je peux rentré dans un cycle et qu'en est-ce que je ne peut pas, avec en plus le risque de perdre du temps. Parce que si le premier cycle prend 11 milliseconde et que les cycle sont declenché tout les 10 milliseconde, je vais perdre 9 milliseconde, du au decalage que le ralentissement du premier cycle a provoquer. En etant cadencé par les cycle eux meme, je n'est pas de perte de milliseconde, puisque je n'est pas a attendre le prochain declenchement. Mais rien que pour arrivé a faire tout ca sans que ca se rentre dedans (demarrage du deuxieme cycle avant la fin du premier et gestion des evenements utilisateur, qui interrompe temporairement les cycles de calcul, sans que ca ce marche dessus) ca m'as pris un moment (et debugage après chaque modife pour verifié le calage du tout, qui des fois passe mal).

[flyingman]

ok, le vieux SPACE INVADER est il un programme temps reel ( meme si le tire partait quelque miliseconde apres avoir appuyer sur "feu")?
Merci.

[invite36602837]

ok, le vieux SPACE INVADER est il un programme temps reel ( meme si le tire partait quelque miliseconde apres avoir appuyer sur "feu")?
Merci.

Je pense que oui, parce que la vitesse du jeu change quant on le met sur un PC plus recent. En fait, voilà comment voir si un prog est en temps reel, le mettre sur un PC plus rapide. Si le prog va plus vite que d'habitude, c'est que c'est un "temps reel". S'il va a la meme vitesse, il est cadencé par un timer interne au jeu. Maintenant, est ce que ton space invader et le meme que le mien, c'est une autre question. Parce que des Space Invader, y en a eux pas mal. Un autre exemple, c'est front line. Exemple typique d'un jeu T.R.. En plus, sur un PII, il devient injouable, l'IA te tue en 10 seconde, humaine, de jeu (alors que sur un 386, il est très jouable et meme facile a gagner).

Par contre, C&C : Red Alerte, lui est cadencé. Parce qu'il va toujours a la meme vitesse quelque soit le PC qui le fait tourné. C'est donc la preuve qu'un timer interne cadence les cycle, sinon, le jeu irais plus vite avec l'evolution du materiel.

[flyingman]

ok merci pour vos reponses!

[JPL]

Modération,

Merci à tous pour votre participation, mais puis-je demander aux auteurs de longs textes de fragmenter leur pavé, ou de découper davantage leurs paragraphes, en mettant une ligne d'espace entre chacun. C'est très intéressant, mais c'est un truc à attraper une indigestion.

[invite504c296f]

On ne parle pas de langage (sans "u", on parle français) temps réel mais de système temps réel, donc de système d'exploitation. "Temps Réel" en soit ne veut rien dire, qu'est-ce que le temps réel? On rentre dans la 4ème dimension. Tu peux très bien avoir un système temps réel dont un processus va mettre 15 JOURS à s'exécuter, sans aucun problème. En fait on parle de tolérance de temps d'exécution, en demandant à l'OS d'exécuter complètement un processus dans un temps imparti et pas plus. Le cas de l'avion avec les turbulences qui doit corriger automatiquement ses gouvernes, le processus doit être de quelques µs, alors que l'affichage de "turbulences" sur l'écran de contrôle peut prendre quelques ms. Pour cela l'OS augmente ou abaisse les temps CPU alloués aux processus afin de satisfaire aux conditions, il "renice" les processus via l'ordonnanceur. Tu peux faire du temps réel sur un vieux 486, s'il convient aux applications et aux critères que tu définis.

[JP]

Salut,

Un OS temps réel est utilisé pour des applications temps réel dont le temps de réponse est primordial.
Exemple d'application: Asservissement d'un système.
Comme ça a déjà été dit il fonctionne sur le principe d'interruption.
Les temps de réponses maximum aux interruptions est fixe.

Si tu veux plus d'informations, tu peux chercher de la doc sur RTLinux, un vrai OS temps réel, utilisé dans l'industrie et la recherche.

a+
JP

[invite36602837]

On ne parle pas de langage (sans "u", on parle français) temps réel mais de système temps réel, donc de système d'exploitation. "Temps Réel" en soit ne veut rien dire, qu'est-ce que le temps réel? On rentre dans la 4ème dimension. Tu peux très bien avoir un système temps réel dont un processus va mettre 15 JOURS à s'exécuter, sans aucun problème. En fait on parle de tolérance de temps d'exécution, en demandant à l'OS d'exécuter complètement un processus dans un temps imparti et pas plus. Le cas de l'avion avec les turbulences qui doit corriger automatiquement ses gouvernes, le processus doit être de quelques µs, alors que l'affichage de "turbulences" sur l'écran de contrôle peut prendre quelques ms. Pour cela l'OS augmente ou abaisse les temps CPU alloués aux processus afin de satisfaire aux conditions, il "renice" les processus via l'ordonnanceur. Tu peux faire du temps réel sur un vieux 486, s'il convient aux applications et aux critères que tu définis.

Très bon exemple de temps reel en informatique. On joue sur les temps CPU des divers processus en cours. Mais il faut bien comprendre que tout depend de la vitesse max du CPU, donc de sa frequence. C'est pour ca que dans les avions, on a des machines un peu (un peu ??? bcp !!!) plus puissante que nos PC de bureau. Mais on peut très bien arrivé a faire du temps reel sur un PC si, comme le dit joshua_fr, on force pas sur les criteres. Un jeu tolere très bien, un avion moins (Attend, faut que je stop winword.exe avec le task man pour liberer du temps CPU pour le pilote automatique ).

[inviteb865367f]

C'est pour ca que dans les avions, on a des machines un peu (un peu ??? bcp !!!) plus puissante que nos PC de bureau.

Hum hum.... presque. A moins que tu considères les 486 comme des foudres de guerre ...

De toute manière comment peut tu imaginer un truc pareil ? regarde la date de naissance du 747 et quels sont les CPU qu'ont savait faire à ce moment là .. c'est pareil pour les Airbus et à mon avis sur le derniers A-380 on devrait trouver des PowerPC de l'ordre de 500Mhz.

Si on s'amuse pas à modifier les systèmes embarqués à tout va c'est que :
1) ça marche
2) les appli ont étés écrites pour ce type de materiel
3) la certification tres couteuse serait à refaire

D'ailleurs, le temps réel n'a strictement rien à voir avec la puissance de calcul. Tout ce qu'on demande c'est d'avoir le résultat dans un temps imparti, ni plus, ni moins.

[invite36602837]

Hum hum.... presque. A moins que tu considères les 486 comme des foudres de guerre ...

Je vois pas ce que tu veux dire. Si tu pense que dans un 747 ou un airbus (que ce soit le A380 ou a un autre) il ont des 486, c'est que tu oublie qu'a l'epoque du 747, le 486 n'existait pas encore. Et en info, y a pas que le monde des PC, y a aussi celui des ordinateur (un pc est un micro-ordinateur, une classe en dessous) et des supercalculateur. Chaque classe est plus ou moins dedié a des taches precise, avec des exceptions bien sur (un developpeur de pilote automatique va travailler sur la machine qui fera tourné le pilote automatique, meme si lui n'utilise pas toute la puissance de la machine).

Voilà un site ou on présente les divers classes
http://www.biomultimedia.net/biomed/...iers/frame.htm

De toute manière comment peut tu imaginer un truc pareil ? regarde la date de naissance du 747 et quels sont les CPU qu'ont savait faire à ce moment là .. c'est pareil pour les Airbus et à mon avis sur le derniers A-380 on devrait trouver des PowerPC de l'ordre de 500Mhz.

Tu sais en info, c'est pas tellement la frequence qui importe, mais le nombre de cycle par seconde. Un cray va a une frequence inferieur a nos PC, sauf que vu qu'il a 64 CPU en parallele, il fait bcp plus d'operation a la seconde que nos PC. Si on parle de frequence pour nos PC, c'est que ce sont des machine monoprocesseur. Mais a part dans les PC, y a pas bcp de machine monoprocesseur en realité. C'est soit des cluster de machine (une grappe de 10PC, ce qui fais 10 CPU en parallele, ce qu'on trouve dans un centre de calcul) ou alors une machine avec des grappe de CPU (comme le cray qui ont bcp de CPU dans 1 machine).

D'ailleurs, le temps réel n'a strictement rien à voir avec la puissance de calcul. Tout ce qu'on demande c'est d'avoir le résultat dans un temps imparti, ni plus, ni moins.

Ben voyons, si le temps reel n'avais rien a voir avec la puissance de calcul, explique moi pourquoi les ordinateurs on pas arreter d'evolué depuis que le premiere a été crée. Si c'etait tellement vrai, on en serais encore aux tubes a vide. Ou alors aux machine qui prenne un immeuble.

Si on veux augmenté la puissance de calcul, soit on augmente la frequence des CPU (donc la technologie), soit le nombre de CPU (donc le volume, le cout, le poid). Mais dans un avions, on peut pas mettre des milliers de CPU. Ca prend de la place, du poids, etc.. Alors on se dit qu'avec 10CPU de 200Mhz, on rentre pile dans les specification. Alors que si on prenait 20 CPU de 100Mhz (nombre de cycle par seconde egaux), ben on sort des specification parce qu'on as trop de poid. Et a coup de 200gr par CPU, ca fais deja 2kilo de trop sur l'avion. Bon, tu me dira que pour avion, c'est pt etre pas trop un problème. Mais sur une navette, ou le kilo coute 100'000.- dollars (je suis pas sur du nombre de zero), ca fair chere le pentium.

Comment tu fais pour avoir le resultat de 2+2 en moins (et je precise, MOINS, pas pile) de 1 seconde sur un PC qui tourne a 1hz avec un seul CPU ????? Si tu y arrive, c'est que tu es très fort (faut deja 2 instruction minimum en info pour faire une addition, donc tu n'es pas pret d'y arrivé).

[monnoliv]

D'ailleurs, le temps réel n'a strictement rien à voir avec la puissance de calcul. Tout ce qu'on demande c'est d'avoir le résultat dans un temps imparti, ni plus, ni moins.

Je rejoins cet avis. Temps réel ne veut pas dire utilisation du (des) processeurs à 100%, c'est débile.
uinet_propane, tu devrais aller faire un tour du coté des microcontrôleurs et OS embarqués pour bien comprendre ce que temps réel signifie en informatique.
A+

[invite36602837]

Je rejoins cet avis. Temps réel ne veut pas dire utilisation du (des) processeurs à 100%, c'est débile.
uinet_propane, tu devrais aller faire un tour du coté des microcontrôleurs et OS embarqués pour bien comprendre ce que temps réel signifie en informatique.
A+

Et bien avant que j'aille faire un tour sur les microcontroleur et les OS, va faire un tour sur les transistor et l'electronique numerique. Le temps reel n'existe pas en electronique parce que l'electronique fonctionne en sequentielle. Ce que vous faite, c'est bluffé. Le temps reel implique la programmation concurrente (faire tournée des process parallele sur un CPU sequencielle) et c'est la que ce situe le bluff. Parce que l'OS va passé d'une tache a l'autre très rapidement. Mais ce n'est pas du temps reel. Prend tout les soft TR que tu veux et met les sur un CPU 10x moins rapide que le CPU qui les fait tournée normalement. Et bien si tu te considere toujours en temps reel, c'est que le temps pris pour executé une tache n'as pas d'importance pour toi. Et donc je ne vois pas en quoi, vu que le temps n'est pas d'importance, tu te permet de dire que c'est du TR.

[invite36602837]

Je rejoins cet avis. Temps réel ne veut pas dire utilisation du (des) processeurs à 100%, c'est débile.

De plus, et la tu as vraiment interet a te renseigner, un CPU est TOUJOURS a 100%. Et c'est une obligation, parce qu'un CPU travail constamment (exception fait des systemes avec economie d'energie, mais c'est recent et ca n'as rien de standard, encore moins dans des systemes critique). Ce que toi tu dit, c'est 100% du CPU pour une seul tache (100% du CPU dedié a cette tache) et ca je suis d'accord, on est rarement a 100% (si on est a 100%, on "bug"). Mais un CPU est toujours a 100%. Si tu fais deja une erreur la dessus, comment veux tu comprendre ce qu'implique le temps reel pour le materiel. Parce que la, on parle du matos, pas de la logique.

[inviteb865367f]

Et bien avant que j'aille faire un tour sur les microcontroleur et les OS, va faire un tour sur les transistor et l'electronique numerique. Le temps reel n'existe pas en electronique parce que l'electronique fonctionne en sequentielle. Ce que vous faite, c'est bluffé. Le temps reel implique la programmation concurrente (faire tournée des process parallele sur un CPU sequencielle) et c'est la que ce situe le bluff. Parce que l'OS va passé d'une tache a l'autre très rapidement. Mais ce n'est pas du temps reel. Prend tout les soft TR que tu veux et met les sur un CPU 10x moins rapide que le CPU qui les fait tournée normalement. Et bien si tu te considere toujours en temps reel, c'est que le temps pris pour executé une tache n'as pas d'importance pour toi. Et donc je ne vois pas en quoi, vu que le temps n'est pas d'importance, tu te permet de dire que c'est du TR.

Pour toi le TR c'est d'avoir le résultat le plus vite possible ??

Si l'appli est TR, la faire tourner sur un CPU 10x moins puissant, on saurra toujours prédire le temps de traitement. 10x plus long certe mais les instructions seront toujours déroulées dans le même ordre. Apres il convient de vérifier qu'on respecte toujours les contraintes de temps. Si t'as contriantes est d'avoir un résultat avant 100ms, que tu l'ais en 5 ou 50ms c'est bon.

Le TR ne fait que garantir ce temps, certainement pas d'avoir un résultat instantané.

[invite36602837]

Pour toi le TR c'est d'avoir le résultat le plus vite possible ??

Non, c'est d'avoir le resultat avant un delai precis.

Comme tu le dit si bien, si le resultat doit venir en moins de 100ms et qu'il arrive en 50ms, c'est du TR. Mais pour arrivé a 50ms, il faut aussi prendre en compte le fait que la tache justement est exectué sequenciellement. Et si tu prend un CPU 10x moins rapide, et bien ta tache s'executera parfaitement, mais en 500ms. Tu n'est donc plus dans tes specification et se n'est donc plus du TR.

Le TR ne fait que garantir ce temps, certainement pas d'avoir un résultat instantané.

Et pour garantir le temps, il faut savoir a quel vitesse fonctionn le CPU (ou les CPUs), donc les cycle pas seconde. C'est donc bien un problème de vitesse (les cycle par seconde, pas la frequence) et pas un problème de logique (OS, langage, etc...), le TR.

[inviteb865367f]

C'est un problème d'OS car seul l'OS te garantie l'execution en un nombre donné de cycle, chose impossible sur un OS non TR.

[invite36602837]

Je reprend un exemple que j'ai mis plus haut :

Comment tu fais pour avoir le resultat de 2+2 en moins (et je precise, MOINS, pas pile) de 1 seconde sur un PC qui tourne a 1hz avec un seul CPU ?????

Explication:

1hz signifie 1 operation a la seconde.
La tache "2+2" necessite 3 instruction CPU.
1ere, aller chercher en memoire la valeur A qui est "2" et la placé dans le registre CPU.
2eme instruction, aller chercher la valeur B qui est "2" est la place dans le registre CPU.
Effectué l'operation "+" en utilisant pour cela l'ALU (Algorithmic & Logical Unit, en d'aute mot le coprocesseur arithemtique).

Et bien comme je viens de te le montrer, il faut 3 cycle, donc 3 seconde pour effectué ce calcul sur un CPU a 1hz. Et bien si le calcul devait etre effectué en moins de 1 seconde, on ne peut utilisé ce CPU.

Donc le TR depend plus du temps CPU que de la prog (interruption, prog concurrente, etc...).

[invite36602837]

C'est un problème d'OS car seul l'OS te garantie l'execution en un nombre donné de cycle, chose impossible sur un OS non TR.

Je l'ai deja dit, mais je le redit, les OS Temps Réel n'existe pas.

Ce qui existe, c'est les OS :

monotache-monoutilisateur (DOS)
multitache-monoutilisateur (Mac, Win 9x, Win NT, Win 2k, Win XP), capacité TR du au multitache
multitache-multiutilisateur (win2k serveur, win2k3 serveur), capacité TR du au multitache

Le reste, c'est du marketing et de la fioriture.

[monnoliv]

Et bien avant que j'aille faire un tour sur les microcontroleur et les OS, va faire un tour sur les transistor et l'electronique numerique.

Je ne pense pas avoir grand chose à apprendre de toi sur ces sujets

Posté par monnoliv
Je rejoins cet avis. Temps réel ne veut pas dire utilisation du (des) processeurs à 100%, c'est débile.

De plus, et la tu as vraiment interet a te renseigner, un CPU est TOUJOURS a 100%.

La bonne blague, je te signale que je n'ai fait que reprendre tes propres propos (POST #6):

...Comme c'est executé tout les X milliseconde, le CPU n'est pas utilisé a 100%, donc ce n'est pas du temps reel...

Je l'ai deja dit, mais je le redit, les OS Temps Réel n'existe pas.

Ecoute, soit tu donnes ta définition de l'OS temps réel (ou d'un système temps réel), définition qui est sûrement fausse, soit on arrête les frais. Tu n'as visiblement pas la connaissance de la programmation temps réel, donc laisse tomber et écoute Jeremy.