Salut les Zéros!!!
Je cherche à savoir comment récupérer, dans un programme en C de mon cru, un signal (3 en fait)
depuis un périphérique, genre détecteur de distance.
Ces signaux agiront en temps réel sur trois variables dans le programme.
Je me demande si je ne vais pas devoir développer un pilote pour permettre à mon prog d'utiliser
le périph...
Ca sent bien le taff...
Si vous avez une idée, ou si je n'ai pas été clair, répondez-moi!!!
Merci d'avance.
Je m'avance peut etre mais si jamais tu veux communiquer avec des peripheriques, les termcaps sont tes amis :).
Par contre si c'est pour recuperer des signaux, la fonction signal() pourrait t'aider.
PS; Merci Gwen-Haël pour la question sur l'OS, j'avais oublie. Donc effectivement pour les termcaps, c'est principalement sous Linux, Windows doit en posseder aussi mais je n'ai pas des connaissances assez pousse sur celui ci pour l'affirmer ou non.
Merci pour vos débuts de réponses!
En effet je manque à mes prérogatives...
Je suis sous Windôbe, je programme sous C::B et mon périph' sera
probablement en USB.
Pour le terme "temps réel", je voulais juste dire que j'aimerais recevoir
et utiliser mes signaux régulièrement et rapidement après détection...
je suis pas à 2o millisecondes près!
Gwen-Haël, tu entends quoi par "architecture"?
En effet je manque à mes prérogatives...
Je suis sous Windôbe, je programme sous C::B et mon périph' sera
probablement en USB.
Pour le terme "temps réel", je voulais juste dire que j'aimerais recevoir
et utiliser mes signaux régulièrement et rapidement après détection...
je suis pas à 2o millisecondes près!
Gwen-Haël, tu entends quoi par "architecture"?
Avant tout, quel est ton niveau (programmation sur PC et sur µC, et en électronique) ?
Tu es prêt à mettre quoi comme moyens dans ton projet (en gros est-ce ton sujet de mémoire, ou est-ce juste un TP) ?
Il existe des solutions plus ou moins rentable pour toi en fonction des questions que je viens de poser.
En ce qui est du temps réel, il n'est pas question de se demander si ton système répondra en quelques micro ou millisecondes ou même secondes, l'essentielle est que ton système soit déterministe. Certes un OS tel que windows (ou linux classique sans extension RT) ne sont pas déterministes et brisent donc ta chaine temps-réel, mais il existe des moyens pour contourner ça.
Dans tous les cas, tu seras obligé de coder un dit "driver", pas très compliqué il ne faut pas se fier à son nom (driver).
J'attends donc tes réponses pour développer d'avantage.
Merci uknow pour l'intérêt que tu portes à mon problème.
Mon niveau en programmation...
difficile à évaluer, j'ai commencé ya deux ans avec le tuto de Mateo,
et depuis j'avance tout seul avec des bouquins de Delannoy et le site France IoI...
Disons que je ne suis pas tout à fait à l'aise mais que je sais resoudre
mes problèmes (jusque là ^^).
En élec j'me suis arrêté en Terminale SI.
J'ai déjà pas mal de matos, a priori il ne me manque que lesdits détecteurs,
à ultrason peut-être.
Pour ton histoire de "driver", j'avais posté au début l'idée, ou la necessité
de coder un pilote...
Faut c'qui faut!
J'imagine que tu es conscient que câbler des détecteurs ultrason sur un port USB nécessite, dans le cas le plus simple, un microcontrôleur (type PIC ou AVR), avec le code embarqué en C, la sonde de programmation, un convertisseur USB série...
Je suis tenté de dire que le driver côté PC est absolument trivial en comparaison, c'est l'affaire de quelques lignes de code!
Merci uknow pour l'intérêt que tu portes à mon problème.
Mon niveau en programmation...
difficile à évaluer, j'ai commencé ya deux ans avec le tuto de Mateo,
et depuis j'avance tout seul avec des bouquins de Delannoy et le site France IoI...
Disons que je ne suis pas tout à fait à l'aise mais que je sais resoudre
mes problèmes (jusque là ^^).
En élec j'me suis arrêté en Terminale SI.
J'ai déjà pas mal de matos, a priori il ne me manque que lesdits détecteurs,
à ultrason peut-être.
Pour ton histoire de "driver", j'avais posté au début l'idée, ou la necessité
de coder un pilote...
Faut c'qui faut!
Maintenant c'est beaucoup plus clair, si tu ne maitrise pas la programmation sur composants électronique (type microcontroleur (PIC ou autres)), il vaudrait donc mieux prendre un module industriel déjà fait, qui communique, éventuellement en USB, ou aussi dans le cas le plus simple en RS232 (d'ailleur j'aurais choisi l'RS232 au lieu de l'USB).
Ainsi tu ne seras pas concerné directement par les signaux de ton capteur, il doit donc avoir une petite intelligence pour détecter ce qu'il a à detecter et l'envoyer par port série (RS232 (ou USB)) sous forme d'un code.
Si ce n'est pas le cas, et tu voudrais tout faire toi même, là ça devient un vrai projet. Il faut acheter le capteur, faire ta carte électronique avec un µC dessus (et tous les composant électroniques qui vont avec), le programmer en fonction de la nature de ton capteur pour qu'il envoie des codes à l'ordinateur.
Du coté de l'ordinateur maintenant, je suppose que tu n'es pas très à l'aise avec les threads ? (C'est une question), si c'est le cas, alors oublie le temps-réel (pour l'instant), tu devras coder un petit programme qui intercepte les codes venant de ton "module capteur" via le port série (RS232). et agit en conséquence (mettre le chauffage en marche, déclencher une alarme, allumer la machine à café...).
Son algorithme devrait ressembler à ceci :
- Attendre l'arrivée d'un code.
- éventuellement décodage (ou vérification par checksum, ou ce que tu veux).
- Exécution des actions associées au code reçu.
- éventuellement envoyer une réponse à ton module capteur.
(ce que j'appelle module capteur, c'est bien évidemment le capteur + le microcontroleur + le programme du microcontroleur.
Ce module sera branché sur le port série (USB ou RS232).)
Tu vois donc bien que ce n'est pas compliqué à coder, sauf si tu veux que ton système te trace un graphe (des températures par exemple) en temps réel.Là il faudra se pencher sur : les threads, les sémaphores, les piles de mémoire (type FIFO ou LIFO) pour gérer le temps réel, sans oublier la bibliothèque adéquat pour afficher des graphes.
Doucement avec "temps réel", c'est impossible sur un PC...
Ce n'est pas impossible!!
Il se peut que, son µC lui envoie des codes à une cadence précise (fréquence uniforme), il est donc obligé de les recevoir et ce sera une bidouille dans tous le sens du terme de faire ça avec un principe autre que le TR. L'OS lui n'étant pas TR, il se peut qu'il en rate quelques uns. d'où l'intérêt des piles de mémoire (pour mémoriser tous ce qui vient et ainsi l'OS "a" le temps de les traiter selon ses disponibilités). Tu remarqueras que nulle part je n'ai parlé de notion de temps (µs ou ms ou s ça n'a rien à avoir).
Citation : Gwen-Haël
L'auteur disant lui-même qu'il n'est pas à 20ms près, je pense pas que ça soit la peine de rajouter une complexité supplémentaire.
Je ne sais pas c'est quoi comme type d'application que tu as réalisée, ni à quel niveau de robustesse (ou de qualité) tu l'as géré. Donc je ne peux pas faire de commentaires.
Je sais que ce n'est pas donné à tout le monde de faire ce genre d'applications, ou même d'être sensibilisé au degré de difficulté que ça engendre.
En effet gwen, je cherche pas une gestion en temps réel, c'était une façon de parler
Etant donné le fonctionnement et la rapidité des procos actuels, je vais pas
compliquer la chose en m'imposant ça.
Et puis Einstein nous a appris que rien n'était perceptible en temps réel...
uknow, tu comfirmes l'idée que je m'étais faite de ce projet, qui a plus valeur de TP
pour l'instant. Comme je te disais je possède déjà toute sortes de composants et cartes
perforées, ne me manquera que les µC, leur programmeur et les détecteurs.
J'ai évoqué les ultrasons car je sais que c'est un moyen de détecter les distances,
en voyez-vous d'autre plus simples à mettre en œuvre, moins onéreux?
Et si j'ai pas le niveau je peux effectivement acheter le module capteur.
Quoi qu'il en soit merci, je vais me pencher sur les autres notions que vous avez abordé.
Grosse zone de flou pour moi malgré tout : comment faire pour récupérer un signal venant
d'un périph'? En l'occurance mon module, mais de n'importe quel périph'.
Autant souris/clavier c'est assez instinctif avec la pratique, autant là je ne sais
vraiment pas où aller pêcher mon signal.
Non mais à partir du moment où l'OS n'est pas temps réel, où le processeur n'est pas temps réel non plus, c'est pas du temps réel, point final et y'a pas d'ergotage possible, c'est une définition.
Citation
Je ne sais pas c'est quoi comme type d'application que tu as réalisée, ni à quel niveau de robustesse (ou de qualité) tu l'as géré. Donc je ne peux pas faire de commentaires.
Le programme auquel je fais référence permet de piloter la trajectoire d'un robot sur un terrain en passant par une liaison Zigbee. Coder ça avec Qt4 prend un peu de temps mais la partie affichage + liaison série c'est quand même relativement simple.
Citation
Grosse zone de flou pour moi malgré tout : comment faire pour récupérer un signal venant
d'un périph'? En l'occurance mon module, mais de n'importe quel périph'.
Il faut que tu fasse l'acquisition et le traitement de ton signal par un microcontrôleur programmé en C, que tu émette une chaîne de caractère contenant l'info sur une liaison série et que tu passes par un composant type FT232 pour le passer sur le bus USB.
A partir de là c'est comme si tu avais une liaison série directe avec ton PC et le "driver" sur PC se résume à recevoir des chaînes de caractère, code classique et déjà bien existant sur google.
Non mais à partir du moment où l'OS n'est pas temps réel, où le processeur n'est pas temps réel non plus, c'est pas du temps réel, point final et y'a pas d'ergotage possible, c'est une définition.
La réponse est dans mes posts précédents :
Citation : uknow
il est donc obligé de les recevoir et ce sera une bidouille dans tous le sens du terme de faire ça avec un principe autre que le TR. L'OS lui n'étant pas TR, il se peut qu'il en rate quelques uns. d'où l'intérêt des piles de mémoire (pour mémoriser tous ce qui vient et ainsi l'OS "a" le temps de les traiter selon ses disponibilités)
Comme je l'ai dit plus haut :
Citation : uknow
Certes un OS tel que windows (ou linux classique sans extension RT) ne sont pas déterministes et brisent donc ta chaine temps-réel, mais il existe des moyens pour contourner ça.
Je n'en dirai pas plus.
Citation : eXiLeD
comment faire pour récupérer un signal venant
d'un périph'? En l'occurance mon module, mais de n'importe quel périph'.
Autant souris/clavier c'est assez instinctif avec la pratique, autant là je ne sais
vraiment pas où aller pêcher mon signal.
La réponse est là :
Citation : Gwen-Haël
le "driver" sur PC se résume à recevoir des chaînes de caractère
La chaine de caractère reçue, est ce que j'ai appelé "code" dans mon explication.
Non mais tu peux bricoler autant que tu veux, ce n'est pas temps réel, ne serait-ce qu'à cause du processeur, donc faut arrêter de jouer sur les mots.
On est tous d'accord que c'est de toute façon inutile ici, mais il faut être clair sur les termes, quoi que tu fasses ce que tu feras sur un PC ne sera jamais du temps réel.
Que le programme ne rate aucun message grâce à un système de piles n'en fait absolument pas du temps réel, je sais pas pourquoi tu me sors ça... Commence donc par vérifier ta définition d'un STR parce que de toute évidence tu as pas la même que les autres.
He les gars vous prenez pas le chou pour une question de termes!!
On sait tous que la gestion en temps réel n'est pas possible dans l'absolu avec un pc,
avec quoi que ce soit d'autre d'ailleurs.
Mais l'être humain peut se satisfaire de la rapidité d'execution d'un programme, et
"l'apparenter" à du temps réel.
Ceci dit, à la limite je cherche un bouquin ou un cours sur le net qui me permettrai
d'apprendre ce dont j'ai besoin pour récupérer un signal venant d'un périphérique.
Les fonctions et bibliothèques requises, etc.
Mes recherches antérieurs n'ayant rien donnés, j'espère trouver du nouveau ici.
Le processeur est nativement déterministe, et c'est donc, dans son cas, suffisant pour qu'il soit TR!
Ton utilisation elle, peut ne pas l'être (comme ça l'est dans le cas d'un OS "standrd").
quoi que tu fasses ce que tu feras sur un PC ne sera jamais du temps réel.
Je parle en connaissance de cause, j'ai déjà réalisé (professionnelemnt) un projet, temps-réel sur un ordinateur de maison, équipé d'une carte PCI avec des I/O, pour commender 3 moteurs d'enroulement/déroulement d'un film et une vingtaine de capteurs. Qui tourne sur un noyau LINUX recompilé avec le noyau (serveur) Temps réel dur.
Avec une IHM (non-TR) qui trace la courbe de la vitesse, et qui envoie des consignes (de vitesse de rotation, de positions verrins...) à mon système TR.
Citation : Gwen-Haël
Que le programme ne rate aucun message grâce à un système de piles n'en fait absolument pas du temps réel, je sais pas pourquoi tu me sors ça...
Peux-tu me dire, comment gères-tu un échange d'information entre un système temps-réel déterministe, et un autre non-temps-réel (une IHM par exemple) ?
Ma solution est la pile de mémoire :
(TR) (non TR)
Système --------(Pile in)-------> IHM
(ou machine) <-------(Pile out)-------
Indépendemment à ce sujet, le principe (je l'explique car je vois que tu n'es pas un pro du domaine, ou que tu n'as pas saisi la portée de mes mots), d'un coté tu as un système (µC + capteur) qui récupère à une cadence précise et constante, des informations à partir d'un capteur, selon si ce dernier les envoie directement sans traitement ou s'il les traite avant, il sera temps-réel ou pas. La condition nécessaire serait que le temps de cet éventuel traitement soit déterministe et pértinent (qu'on soit capable de dire que je passe tant de temps à traiter avant d'envoyer mon information, et ceci entre deux aquisitions).
De l'autre coté on a un système (ou une IHM) complètement hasardeux (en terme de déterminisme), dans lequel les tâches s'intérrempent entre-elle "n'importe comment" et tu dois lui envoyer (voir même recevoir) des informations, et il est tout de même logique que ce dernier n'enrate aucune (sauf cas de tolérance).
Ce qui risque de se passer sans système de pile, est que STR envoies une information, l'IHM est occuppée ou ne s'est pas encore faite activée par l'ordonnanceur pour x raisons, si le STR envoie une nouvelle information, tu imagine bien (enfin j'espère) que la première sera écrasée s'il n'y a pas de pile.
Citation : Gwen-Haël
Commence donc par vérifier ta définition d'un STR parce que de toute évidence tu as pas la même que les autres.
Sois constructif dans tes propos. Autrement on n'avancera pas dans le dialgue.
Je ne fais pas de jeu de mots, mais je reprends des propos que j'ai avancé et que tu ne semble pas avoir compris, ou tu fais semblant de ne pas les comprendre histoire de dire quelque chose.
PS : relis mon post plusieurs fois avant de répondre pour éviter une réponse précipitée (comme précédemment).
Le processeur est nativement déterministe, et c'est donc, dans son cas, suffisant pour qu'il soit TR!
C'est faux, le processeur d'un PC est complètement non déterministe (pipeline, unité de prédiction, cache, t'en veux encore?)
Citation
Je parle en connaissance de cause, j'ai déjà réalisé (professionnelemnt) un projet, temps-réel sur un ordinateur de maison, équipé d'une carte PCI avec des I/O, pour commender 3 moteurs d'enroulement/déroulement d'un film et une vingtaine de capteurs. Qui tourne sur un noyau LINUX recompilé avec le noyau (serveur) Temps réel dur.
Avec un OS temps réel, sur des systèmes basse fréquence, on est d'accord: les petites variations de délais ne posent pas problème. Je persiste à dire qu'il ne s'agit pas de temps réel au sens strict.
Citation
(je l'explique car je vois que tu n'es pas un pro du domaine, ou que tu n'as pas saisi la portée de mes mots)
Ce genre de commentaire ne t'aidera pas, au sens technique je suis justement un pro du domaine. Je vois seulement les choses avec un peu plus de rigueur: le temps réel ce n'est pas l'OS seul mais toute la chaîne, du processeur jusqu'au code final.
Citation
snip sur la pile
Merci, mais je sais très bien comment interfacer un système non TR avec un TR, je le fais grosso merdo tous les jours. Simplement ça ne rend pas temps réel un système qui par essence ne l'est pas, bordel, je me tue à te dire que dès que tu es sur un OS classique avec un processeur classique, tu n'es plus en temps réel, point, c'est tout.
@PO:
Maintenant, pour récupérer un signal, il y a bien des façons de faire.
Pour moi la plus simple est celle qui a été exposée: passer par un microcontrôleur pour envoyer les données du capteur sur le bus USB (en passant sur un bus série d'abord si tu veux un code simple).
Tu peux aussi passer par le bus PCI et développer une carte d'extension, mais c'est un peu plus compliqué
C'est faux, le processeur d'un PC est complètement non déterministe (pipeline, unité de prédiction, cache, t'en veux encore?)
On est capable (en parlant du constructeur) de dire combien "exactement" prend de temps une interruption et/ou une instruction dans le µP, alors je ne vois pas pourquoi il ne serait pas déterministe. Le cahe, est justement un moyen d'interfaçage qui prouve que le µP lui est TR contrairement à quelques mémoires avec qui il échange des données.
Et je te rappelle que les pipeline, par principe, ont un temps de parcours détérminé. Les unités également.
Citation : Gwen-Haël
Citation
(je l'explique car je vois que tu n'es pas un pro du domaine, ou que tu n'as pas saisi la portée de mes mots)
Ce genre de commentaire ne t'aidera pas, au sens technique je suis justement un pro du domaine.
Encore une fois une réponse précipitée.
Citation : Gwen-Haël
Simplement ça ne rend pas temps réel un système qui par essence ne l'est pas, bordel, je me tue à te dire que dès que tu es sur un OS classique avec un processeur classique, tu n'es plus en temps réel, point, c'est tout.
Citation : uknow
mais il existe des moyens pour contourner ça.
Je n'ai pas dit que ça rendrait tout ton système TR, mais j'ai relevé le problème d'interfaçage TR/TP.
Je continuerai à le dire (sauf preuve du contraire) un µP est déterministe et son utilisation ne brise pas une chaine temps-réel. (Contrairement à la plupart des mémoires).
Ok Gwen, merci a vous!
Je potasse tout ca de mon coté, je vais plus me connecter avant un moment.
Je reviendrais surement dans le mois pour plus d'infos.
Pour ton projet je te conseil d'utiliser une carte type Arduino. Il y a plein d'exemple de code pour la programmer en C.
De plus elle apparait sur le PC comme un port RS232 virtuel et se programme donc facilement pour récupéré tes valeurs.
Pour le problème de fond à savoir le temps réel : il y a toujours un temps de propagation, d'échange/modification des données qui fait que ,pour moi, au sens strict, sa n'existe pas surtout vu la fréquence du proco et du µC...
Le temps réel ne veut pas dire non plus "propagation instantanée".
Temps réel ça veut dire que pour un évènement X, on doit savoir précisément combien de temps le système prend pour donner la réponse Y, parce que si le temps est faux, la réponse est fausse. Par exemple, dans un asservissement, si on donne la réponse 1ms plus tard, il y a une erreur qui se répercute physiquement dans le système.
La subtilité est que souvent ce sont des systèmes peu performants, justement (exemple type: microcontrôleur à 10MHz avec 10Ko de RAM).
D'une manière générale, plus on en demande plus c'est dur de faire du temps réel, ce qui fait que les processeurs "grand public" ne sont absolument pas adaptés à un usage temps réel.
Je continuerai à le dire (sauf preuve du contraire) un µP est déterministe et son utilisation ne brise pas une chaine temps-réel. (Contrairement à la plupart des mémoires).
J'avais lu il y a longtemps un entretien d'un architecte du Pentium 4. Il disait que le fonctionnement était chaotique, genre effet papillon: un minuscule changement quelque-part dans un coin du programme, peut (par le jeu des invalidations de cache, du réordonnancement des instructions, des prédictions de branchement, des chargements spéculatifs, etc) rendre 1000 fois plus lent l'exécution d'une fonction tout ailleurs. En pratique, le temps d'exécution d'un morceau de code donné est donc imprévisible sur un CPU complexe.
Sans parler du Pentium 4 qui était un cas extrême, rien qu'avec un cache L2, c'est terminé, les algos de recherche de page sont foncièrement non déterministes.
Ce qui fait qu'un simple ARM Cortex-A* n'est déjà plus prévisible
J'avais lu il y a longtemps un entretien d'un architecte du Pentium 4. Il disait que le fonctionnement était chaotique, genre effet papillon: un minuscule changement quelque-part dans un coin du programme, peut (par le jeu des invalidations de cache, du réordonnancement des instructions, des prédictions de branchement, des chargements spéculatifs, etc) rendre 1000 fois plus lent l'exécution d'une fonction tout ailleurs. En pratique, le temps d'exécution d'un morceau de code donné est donc imprévisible sur un CPU complexe.
Il n'y pas très longtemps (après la sortie du core 4), j'ai lu également qu'en terme de performances CPU, on n'a pas évolué vraiment depuis le P3.
(Quand je dis performances ça sous-entend le compromis consommation, vitesse et taille.) Les gens qui bossent dans la R&D chez Intel sont les plus informés.
Et depuis, on n'a pas arrêté de voire (P4, centrino, core 2, core 4, et core 5...) ce sont juste des noms plus ou moins commerciaux. Par contre tous ce qui est technologie des gammes militaires j'ignore où est-ce que ça en est, du fait qu'ils développent leurs propres CPUs (par ASICs) et qu'ils ne se mélangent pas au grand-publique.
(Pour le grand-publique on est pas loin des 20 nano dans la fabrication des ASICs.)
Pour revenir au TR, je pense comprendre où est-ce qu'on ne s'est pas compris.
J'ai l'impression que vous parlez point de vus algorithmique, contrairement à moi.
Vous avez parlé du cache, qui n'est autre qu'un moyen d'interfaçage TR/TP pour que le CPU ne soit pas bloqué par la lenteur (et le non-déterminisme) des accès aux mémoires externes et autres périphériques.
Et si je remonte dans la conception des CPU (je parle des anciennes technos, vu que celles de nos jours sont plus tordues que la planification des RER sur Paris) c'est en fin de compte un composant électronique, avec principalement (et historiquement) plusieurs milliards de bascules D et de portes logiques, câblés de façon statique. L'existence même d'algorithmes dits d'optimisation des branchements n'est qu'un concept et une pure vue d'esprit. Par définition un µP est un composant à fonctionnement programmable (et non à architecture programmable).
Si on a inventé un autre type de famille de composants (à architecture et fonctionnement programmables chose qui m'étonnerait), alors mes connaissances ne sont pas à jour.
Quand je dis un CPU est un composant déterministe, je pars du principe que si on lui demande de faire une tâche, il mettra un temps 'T' fixe (qui est, il faut le dire, lié certes de loin, mais reste lié aux temps de parcours des circuits électroniques, qui sont parfaitement déterminés).
Mais dés lors qu'il s'agit de communiquer avec d'autres composants tel que le disques durs ou autres composants ou algorithmes externes ou internes, l'aspect déterministe devient critique, ce qui peut justifier la position de Gwen-Haël .
C'est un grand débat discuté maintes fois sans aboutir à une réponse qui satisfasse à la définition même du Temps réel pour chacun.
Quand je dis un CPU est un composant déterministe, je pars du principe que si on lui demande de faire une tâche, il mettra un temps 'T' fixe
Et c'est bien là le problème: c'est faux.
Le temps d'exécution dépend non seulement de l'instruction en cours mais de la totalité de l'état du système (périphériques, état du cache, instructions précédentes, etc).
Citation
Vous avez parlé du cache, qui n'est autre qu'un moyen d'interfaçage TR/TP pour que le CPU ne soit pas bloqué par la lenteur (et le non-déterminisme) des accès aux mémoires externes et autres périphériques.
Ceci est faux aussi. Le cache est une mémoire fonctionnant à la fréquence coeur dont le rôle est de servir de RAM temporaire (la RAM classique est trop lente à cette échelle), ça n'a rien à voir avec du temps réel.
L'usage du cache permet d'accélérer le processeur en limitant les accès mémoire, mais il y a, physiquement un algorithme de recherche de page câblé dans le processeur, et cet algo est par définition non déterministe. Le temps dépend totalement de l'état de la machine avant ton instruction. L'usage d'un cache L1/L2 rend nécessairement le processeur imprévisible.
Citation
L'existence même d'algorithmes dits d'optimisation des branchements n'est qu'un concept et une pure vue d'esprit.
Encore faux. Ces algorithmes sont implémentés physiquement dans le processeur.
Ceci n'est pas un débat - tu as des idées fausses sur les processeurs, qui sont vraies sur des PIC, AVR ou même le bas de gamme ARM.
C'est en revanche totalement faux sur les monstres de complexité que sont les processeurs X86 ou même Cortex-A*.
Tu sous-estime la complexité de ces engins, c'est absolument inimaginable, et au moment du Pentium 4 ses propres créateurs ne comprenaient plus rien à leur propre architecture tellement c'était monstrueux.
Il n'y a nul débat à avoir - ces processeurs sont, physiquement, électroniquement, par nature complètement NON déterministes. Point, c'est tout. Tu peux faire ce que tu veux derrière, ton programme C n'a pas un temps d'exécution constant.
Quand je dis un CPU est un composant déterministe, je pars du principe que si on lui demande de faire une tâche, il mettra un temps 'T' fixe
Et c'est bien là le problème: c'est faux.
Le temps d'exécution dépend non seulement de l'instruction en cours mais de la totalité de l'état du système (périphériques, état du cache, instructions précédentes, etc).
Ne mélange pas tout, je te parle d'une seule instruction, indépendemment des périphériques et de machin bidule autour, ou de savori s'il est entrin de faire ses toilettes ou j'en sais quoi.
Pour dire qu'un système est déterministe on se place dans des cas où le système est dans son état dit "stable" (pas d'autres instructions à faire). Autrement tu mélanges tout (l'OS, le DD, la carte graphique... ça n'aura pas de fin) et ce n'est pas de cet aspect que je parle.
Citation : Gwen-Haël
Citation
Vous avez parlé du cache, qui n'est autre qu'un moyen d'interfaçage TR/TP pour que le CPU ne soit pas bloqué par la lenteur (et le non-déterminisme) des accès aux mémoires externes et autres périphériques.
Ceci est faux aussi. Le cache est une mémoire fonctionnant à la fréquence coeur dont le rôle est de servir de RAM temporaire (la RAM classique est trop lente à cette échelle), ça n'a rien à voir avec du temps réel.
Qu'est-ce qui est faux ?
Citation : Gwen-Haël
L'usage du cache permet d'accélérer le processeur en limitant les accès mémoire, mais il y a, physiquement un algorithme de recherche de page câblé dans le processeur, et cet algo est par définition non déterministe. Le temps dépend totalement de l'état de la machine avant ton instruction. L'usage d'un cache L1/L2 rend nécessairement le processeur imprévisible.
Es-tu entrain de faire référence à la manière dont tu utilises ton CPU (l'enchainement d'instructions en particulier) ?
Car ma réponse est plus haut dans ce sujet :
Citation : uknow
Ton utilisation elle, peut ne pas l'être (comme ça l'est dans le cas d'un OS "standrd").
Citation : Gwen-Haël
Citation
L'existence même d'algorithmes dits d'optimisation des branchements n'est qu'un concept et une pure vue d'esprit.
Encore faux. Ces algorithmes sont implémentés physiquement dans le processeur.
C'est ce que j'ai appelé "un concept et une vue de l'esprit", car c'est un montage physique de la logique séquentiel et non un algorithme au sens d'un programme.
Le processeur de mon PC est suffisant pour simuler du TR. Je ne cherche pas à faire décoler une fusée.
Citation : Gwen-Haël
Ceci n'est pas un débat - tu as des idées fausses sur les processeurs,
En tout cas touts tes argumets sont de travers, et peu convaincants.
Citation : Gwen-Haël
C'est en revanche totalement faux sur les monstres de complexité que sont les processeurs X86 ou même Cortex-A*.
Tu sous-estime la complexité de ces engins, c'est absolument inimaginable, et au moment du Pentium 4 ses propres créateurs ne comprenaient plus rien à leur propre architecture tellement c'était monstrueux.
Quelle diffamation
Tu peux citer un exemple, une citation ou une affirmation de un de ces gens ?
(Je n'ai pas encore entendu parler d'une architecture (design) qu'on a conçu et qu'on ne comprend pas, il se peut qu'on n'arrive pas à expliquer quelques phénomènes liés à la diaphonie, à une mauvaise conception ou ou ou mais pas un design qu'on ne comprend pas).
Je sais bien que c'est une usine à gaze, mais je trouve tes adjectifs exagérés.
Citation : Gwen-Haël
ton programme C n'a pas un temps d'exécution constant.
Tu semble l'oublier mais je n'ai jamais dit que ce sera le cas
Il n'y pas très longtemps (après la sortie du core 4), j'ai lu également qu'en terme de performances CPU, on n'a pas évolué vraiment depuis le P3.
Oui, la fréquence n'augmente plus depuis des années, et l'on ne sait plus très bien quoi faire des transistors supplémentaires offerts par la loi de Moore. On fait donc du multi-core faute de mieux.
Citation : uknow
Et depuis, on n'a pas arrêté de voire (P4, centrino, core 2, core 4, et core 5...) ce sont juste des noms plus ou moins commerciaux.
Pas tout à fait. Le P4 a une micro-architecture très différente du P3 et des Core2 et Core i.
Citation : uknow
ce sont juste des noms plus ou moins commerciaux. Par contre tous ce qui est technologie des gammes militaires j'ignore où est-ce que ça en est
Moi aussi, mais qui dit militaire dit en général rustique pour résister à de larges plages de températures, radiations, etc.
Citation : uknow
Vous avez parlé du cache, qui n'est autre qu'un moyen d'interfaçage TR/TP pour que le CPU ne soit pas bloqué par la lenteur (et le non-déterminisme) des accès aux mémoires externes et autres périphériques.
Malgré le cache, en cas de miss, le CPU se trouve bloqué des dizaines, centaines ou milliers de cyles. C'est pour ça que j'en parle. Et des caches, il y en a quelques-uns dans un CPU: L1, L2, parfois L3, TLB, branch...
Connais-tu le fonctionnement d'une mémoire cache (tag, associativité, collisions, cache miss, etc.)?
EDIT: Je complète
@uknow: quand tu écris «Ne mélange pas tout, je te parle d'une seule instruction» j'ai l'impression que tu considères qu'un CPU exécute les instructions atomiquement, les unes après les autres, dans l'ordre. C'était vrai il y a 30 ans, mais ce n'est pas du tout le cas dans un CPU moderne complexe.
@Gwen-Haël: Je ne vois pas bien en quoi le fait d'avoir des caches L1 & L2 rend le CPU fondamentalement non-déterministe. En quoi est-ce plus important que d'avoir un MMU, un branch cache ou autre?
Malgré le cache, en cas de miss, le CPU se trouve bloqué des dizaines, centaines ou milliers de cyles. C'est pour ça que j'en parle. Et des caches, il y en a quelques-uns dans un CPU: L1, L2, parfois L3, TLB, branch...
Connais-tu le fonctionnement d'une mémoire cache (tag, associativité, collisions, cache miss, etc.)?
On va dire que c'est une première interface. Je parlais des caches vue d'extérieur (leur principe) indépendemment de leurs types (direct mapped, fully associative...) ni de la nature de l'accès (encore moins de la lecture).
Citation : Marc Mongenet
@uknow: quand tu écris «Ne mélange pas tout, je te parle d'une seule instruction» j'ai l'impression que tu considères qu'un CPU exécute les instructions atomiquement, les unes après les autres, dans l'ordre. C'était vrai il y a 30 ans, mais ce n'est pas du tout le cas dans un CPU moderne complexe.
C'est l'avantage même d'une architecture en pipes (de pouvoir enchaîner les instructions) sans attendre l'arrivée de l'instruction d'avant au bout du pipe (dans le cas de deux instructions ou deux parties d'instructions empruntant le même parcours bien évidemment).
Je vouslais en venir avec ça, au fait de dire que par exemple pour telle interruption, le µP prend 15 nanoseconde pour aller lire l'entrée au pin x.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Objectif Zéro Bug - le test logiciel professionnel | L'électronique de zéro | Tableaux & pointeurs | Pointeurs sur fonctions | Lecture/écriture binaire
Objectif Zéro Bug - le test logiciel professionnel | L'électronique de zéro | Tableaux & pointeurs | Pointeurs sur fonctions | Lecture/écriture binaire
Objectif Zéro Bug - le test logiciel professionnel | L'électronique de zéro | Tableaux & pointeurs | Pointeurs sur fonctions | Lecture/écriture binaire
Objectif Zéro Bug - le test logiciel professionnel | L'électronique de zéro | Tableaux & pointeurs | Pointeurs sur fonctions | Lecture/écriture binaire
Objectif Zéro Bug - le test logiciel professionnel | L'électronique de zéro | Tableaux & pointeurs | Pointeurs sur fonctions | Lecture/écriture binaire
Objectif Zéro Bug - le test logiciel professionnel | L'électronique de zéro | Tableaux & pointeurs | Pointeurs sur fonctions | Lecture/écriture binaire
Objectif Zéro Bug - le test logiciel professionnel | L'électronique de zéro | Tableaux & pointeurs | Pointeurs sur fonctions | Lecture/écriture binaire
Objectif Zéro Bug - le test logiciel professionnel | L'électronique de zéro | Tableaux & pointeurs | Pointeurs sur fonctions | Lecture/écriture binaire
Objectif Zéro Bug - le test logiciel professionnel | L'électronique de zéro | Tableaux & pointeurs | Pointeurs sur fonctions | Lecture/écriture binaire