Version imprimable
Salut,
Je me pose une question simple sur la programmation temps réel :
Est ce que le langage C est adapté pour la programmation temps réel ? :?
Personnellement je pense que non puisque on ne maitrise pas vraiment le temps d'exécution des scripts. Par exemple sous LabView, on peut cadencer des boucles de sorte à s'exécuter en un temps très limité ... chose impossible en C non ?
merci :)
Oula.... Je crois que ta définition de temps réel est mauvaise. La gestion du temps réel vient surtout des tâches par l'OS. Tu devrais lire des articles sur les systèmes temps réel pour affûter ta réflexion sur le sujet. Pour commencer : http://fr.wikipedia.org/wiki/Syst%C3...emps_r%C3%A9el
;)
effectivement je n'ai aucune notion dans la programmation temps réel. J'essaie de m'initier à ce domaine car mon stage m'y contraint. Une tâche un peu compliquée surtout pour un type qui n'est pas vraiment formé dans le domaine de l’informatique.
Donc si je comprends bien, le gestion du temps en ce qui concerne l'exécution d'un script dépend entièrement de l'OS temps réel. On a pas à intervenir pour influencer le temps d'exécution en modifiant le script ... ?
Pour comprendre le principe du temps réel, regarde juste les parties Spécifités et Tâches du lien wikipedia mis par Bktero.
Un système qui s'exécute tout les 100 ans et doit durer au plus 112secondes est un système temps réel. Un système qui se lance toutes les 30secondes et doit se terminer en moins de 30 secondes aussi. Un système qui se lancera dans 2 minutes mais qui ne garantit pas une date de terminaison n'est par contre pas un système temps réel.
Sur un autre contexte, une mission en CDD c'est du temps réel si tu sais exactement ce qu'il faut faire (bouger 300cartons) et que tu as une deadline (et qu'on te donne rien d'autre à faire si tu finis plus tôt), la même mission en CDI sans deadline n'est pas temps réel.
Edit : "Range ta chambre", c'est pas temps réel, "Range ta chambre avant ce soir", oui :mrgreen:
Merci ManusDei pour ces explications. Tu me confirmes bien ce que je pense avoir compris. Un programme temps réel c'est un programme qui doit donner le bon résultat mais aussi dans des temps prédéfinis.
En fait j'ai écris une application serveur client qui va servir dans une boucle d'asservissement temps réel pour transférer des fichiers. le serveur et sont client sont chacun exécuté sur un OS temps réel différent pour transférer des fichiers du premier ordinateur vers le deuxième ordinateur.
Donc je me demandais si cette application allait fonctionner en temps réel juste en la faisant exécuter sur des OS temps réel ou alors fallait il apporter des modifications directement sur le code pour le rendre exécutable en temps réel.
@ManusDei : j'ai ri à l'exemple de la chambre :lol:
Plus qu'un programme, c'est un système qui est temps réel. Ce système étant lui-même constitué de tâches ou de programme qui tournent tous ensemble. Il faut aussi faire attention au terme temps réel. Des fois, on entend "mon GPS m'affiche ma position en temps réel". Dans cette phrase, le terme prend en fait le sens de "avec un délai de rafraichissement suffisamment bref pour que j'ai l'impression que ça soit instantané". Ton GPS serait temps réel s'il te garantissait que ta position est mise à jour toutes les millisecondes, que quand tu appuies sur un bouton, il réagit au maximum en 2 millisecondes.Citation:
Envoyé par fusionfroide
Le temps réel est passé sur le respect des délais. Mais il y a des tonnes de paramètres pour que tous les délais de toutes les tâches soient respectées.
La première est bien sûr que le temps d'exécution d'une tâche soit plus bref que le délai entre deux exécutions périodiques de cette tâche. C'est ce qui est dit ici : http://fr.wikipedia.org/wiki/Syst%C3...tion_de_charge
C'est là que le développeur doit fournir un gros travail. Exemple : dans un avion, l'ordinateur de bord doit récupérer la valeur d'un capteur, faire plein de calculs dessus pour enfin commander l'avion. La tâche doit s'exécuter toutes les millisecondes. Si le temps pour la mesure et les calculs est de 1.1ms, tu ne pourras pas respecter les échéances de temps.
La seconde est aussi que l'OS soit capable de prioriser les tâches. Si où le programme d'acquisition et de calcul évoqué ci-dessus demande à l'OS à faire une acquisition, il ne faut pas que l'OS lui réponde "ouais, un instant, je suis en train de redessiner un logo qui sert juste à faire joli sur l'écran", ça ne peut pas marcher. L'OS doit dire, "ok, tu es prioritaire, je te donne la main".
Et tout un tas de règle comme ça, que je ne connais pas forcément ^^
Comme je l'ai dit plus haut, l'utilisation d'un OS temps réel n'est pas la seule condition pour rendre un système temps réel.Citation:
Envoyé par fusionfroide
Toujours trouver un exemple concret adapté au public visé :mouarf:Citation:
Envoyé par Bktero
Citation:
Envoyé par fusionfroide
Vous avez tous les deux raison. « temps réel » est une expression informelle au départ mais qui venait naturellement à l'esprit des développeurs parce que le besoin se faisait sentir, et qui a fini par être définie de façon plus précise pour les mêmes raisons.Citation:
Envoyé par Bktero
Il faut aussi souligner que jusqu'au milieu des années 1990, il n'était pas rare d'avoir des programmes déterministes au regard du temps d'exécution, parce qu'on travaillait principalement en mono-tâche (en particulier sous D.O.S.), qu'une bonne partie des programmes était encore écrite en assembleur et qu'on désactivait les interruptions, bien moins nécessaires alors qu'elles le sont aujourd'hui. Il était alors tout-à-fait concevable de compter le nombre de cycles qu'occupait une instruction ou une section entière, et ceci parce qu'on était à la fois limités en mémoire et en rapidité d'exécution, et parce le matériel était bien moins varié qu'il ne l'est aujourd'hui.
C'était encore plus vrai sur les huit bits des années 1980 durant lesquelles chaque gamme ne proposait trois à sept machines différentes. On était pratiquement sûr de tomber dans le même contexte à chaque fois et il était alors tout-à-fait pertinent d'écrire des programmes directement adaptés à l'architecture matérielle, et c'était d'autant plus vrai qu'on ne pourrait pas systématiquement s'appuyer sur des ordonnanceurs extérieurs et des interruptions pour faire le même travail. D'abord parce que ces circuits n'étaient pas forcément disponibles sur la machine concernée, ensuite parce que leur coût en temps machine était prohibitif, là où il passe pratiquement inaperçu aujourd'hui.
Par exemple, la synchronisation des accès aux disquettes se faisait avec de nombreuses attentes actives calibrées en nombre de cycles (c'est aussi pour cela qu'ils étaient aussi difficile à interrompre en cas de pépin). Dans d'autres domaines, quand on utilisait encore des palettes de couleurs, on changeait la teinte d'une couleur donnée avec une période égale à celle du tracé d'une ligne par le canon à électrons du tube cathodique. Ça marchait très bien, ça permettait de faire des effets style « Copper » de l'Amiga. Chaque départ de ligne était parfaitement aligné avec le précédent et donnait, par effet stroboscopique, une barre parfaitement verticale et qui ne se déplaçait jamais avec le temps, signe d'une grande stabilité et d'une grande précision temporelle.
Évidemment, aujourd'hui, ce n'est plus possible, parce que les processeurs sont tous différents, qu'un même processeur peut lui même varier en cadence selon la charge de travail, et qu'il est impossible de synchroniser de manière déterministe et au cycle près des programmes indépendants entre eux sur un système d'exploitation multitâche sophistiqué. Par contre, il est possible d'établir des limites strictes à l'intérieur desquelles le déroulement est libre et de garantir un résultat à une date donnée, quitte à s'y prendre légèrement à l'avance. Ce qui est intéressant, c'est que les machines sont suffisamment rapides aujourd'hui pour que les intervalles restent relativement courts.
À noter que ces considérations sont particulièrement pertinentes dans un cas assez répandu : les émulateurs ! Un émulateur fidèle est déjà très appréciable lorsque l'on veut faire fonctionner les vieux jeux sur console, il devient critique avec le développement des (fausses) machines virtuelles.
Du coup, pour répondre à la question initiale, le C n'est clairement adapté à la première méthode, mais aucun autre langage ne l'est vraiment non plus, à part l'assembleur de la machine cible. A contrario, la seconde méthode relève principalement de la programmation système et en ce sens, le C n'est pas non plus moins indiqué qu'un autre langage.
Aucun langage ne peut etre vraiment temps reel au sens ou tu l'entends (ou au sens ou le commun des mortels l'entend).Citation:
Envoyé par fusionfroide
Tu parles dans ton exemple de transfert de fichier temps reel. Ca veut dire quoi ? Que lorsque je modifie un fichier sur la machine 1 il est modifie en temps reel sur la machine B ? Si oui, alors ce n'est pas possible physiquement, ne serait-ce que parce que le temps de transfert de l'information entre les deux machines n'est pas nul.
En revanche, si l'information est transferee, systematiquement, en moins de 10 milliseconde (pour l'exemple), l'etre humain moyen considerera le systeme dans son ensemble comme temps reel (ce que je modifie sur la machine 1 est modifie en meme temps [a l'echelle humaine] sur la machine 2).
Bref, a mon avis, il faut voir quelles sont tes contraintes temps reel pour le transfert de fichier (100ms ? Plus ? Moins ?), et voir comment les mettre en oeuvre.
Pour la mise en oeuvre, tout langage bas niveau te permettant d'executer des choses au plus pres de la machine sera acceptable. Le C en fait partie.