Temps réel ou presque, plein de questions

Signaler
Messages postés
16
Date d'inscription
vendredi 11 mai 2012
Statut
Membre
Dernière intervention
4 juillet 2013
-
MB32
Messages postés
16
Date d'inscription
vendredi 11 mai 2012
Statut
Membre
Dernière intervention
4 juillet 2013
-
Bonsoir,

Je cherche à répliquer avec XE2/XE3 un programme écrit vers 1990 en C, qui n'utisait que quelques dizaines ou centaines de lignes à l'époque. En bref, c'était un programme qui mesurait des capacités mnésiques avec des temps de réaction vaguement complexes: en mode texte, un spot parmi 4 s'affichait 4 positions possibles à l'écran, et il fallait presser sur le bouton correspondant d'un boîtier externe, vite et surtout sans se tromper. Toujours à l'époque, le boîtier était connecté à un port série, dont 4 broches pouvaient être lues à l'état haut/bas; le 8250 était reprogrammé pour déclencher une IRQ, pendant que le timer était reprogrammé pour une mesure en gros à la milliseconde.
La dernière précaution était sur l'affichage, pour que le temps de balayage vertical assure que la visualisation du spot affiché se fasse avec certitude dans un temps répétitif sans incertitude en repartant depuis le point haut (sinon j'aurais eu une imprécision liée au temps de rafraîchissement, il faut une précision de 5-10ms au pire, les effets mesurés sont très discrets).

Mon compilateur Turbo-C a fini dans les poubelles de l'histoire, de toute façon sous Windows il n'est plus question de programmer ou lire directement les circuits comme je le faisais à l'époque, je ne maîtrise évidemment plus un temps réel même approximatif.

J'ai imprudemment promis à un professeur parisien à Saint-Antoine de lui réécrire ce programme pour qu'il puisse dupliquer les études faites à Strasbourg où il travaillait à l'époque et où je donnais parfois un coup de main. Comme j'habite à présent près de Nîmes ca ne facilite rien.

En première approche, j'ai refait 2 boîtiers avec des circuits Phidgets qui déclenchent une IRQ sur un port USB. Il me reste 2 problèmes, la mesure du temps écoulé, mais des appels système ou un appel de tâches parallèles pourraient y répondre; quant à l'affichage, je ne sais pas trop si la simple option de mémoire à simple et pas double accès assure un affichage homogène dans le temps, comme à présent le flickering n'est plus un problème.

Je suis dans un flou complet et preneur de toute aide, mieux encore, si un étudiant ou un groupe en région parisienne voulaient reprendre le problème avec un de ces boîtiers, pour l'amour de la coopération interuniversitaire avec une recherche en neurosciences, ca m'aiderait à tenir la promesse que j'ai inconsidérément donnée et qui me met mal à l'aise..

Merci,


MB32.

20 réponses

Messages postés
2233
Date d'inscription
mardi 10 décembre 2002
Statut
Modérateur
Dernière intervention
15 décembre 2014
5
Salut,

pour ce qui est du temps écoulé, évite les TTimers qui sont trop imprécis.
Tu peux par contre utiliser la fonction GetTickCount.

J' espère que tu vas trouver de l' aide ...

a+


Composants Cindy pour Delphi
Faites une donation.
Messages postés
2527
Date d'inscription
jeudi 15 janvier 2004
Statut
Membre
Dernière intervention
16 octobre 2019
13
Salut,

Y a t-il une raison pour utiliser un boîtier externe et non pas le clavier, ou le pavé numérique de celui-ci, ou même un pavé numérique indépendant (photo ci-dessous) ?

D'autant que si le nombre de touches de ce pavé est trop important il est facile d'y adapter un cache adéquat...
En effet, les temps de réponse d'un clavier et sa priorité sont toujours optimisés par le système.
Messages postés
16
Date d'inscription
vendredi 11 mai 2012
Statut
Membre
Dernière intervention
4 juillet 2013

Merci d'abord pour toutes vos réponses.

Je réponds à un message, mais considérez que je réponds à vous tous.

Effectivement, pour des raisons difficiles à développer en quelques lignes, un changement tel que choisir des pressions sur des touches clavier au lieu d'un boîtier externe pourrait rendre le test invalide. Les tests psychométriques sont sensibles à des différences minimes; ici il vaut mieux un boîtier avec seulement 4 touches, en dessous de l'écran où 4 emplacements du spot sont possibles. La description du test par l'auteur comprend même l'écart angulaire des spots affichés, la luminosité, etc.. cf bibliographie "Mari Jo Nissen", "serial test".

Pour la mesure des temps de réaction, j'ai choisi les fonctions ci-dessous:
.. initialisation..
QueryPerformanceFrequency(FFrequency);
QueryPerformanceCounter(FStart);
.. mesure ..
QueryPerformanceCounter(FStop);
FElapsed := (FStop - FStart) / FFrequency; // Durée captée, en secondes.
Result := FElapsed * 1000; // Durée finale, en ms avec n décimales.

Ces fonctions plantent si on mélange avec des 'sleep'.
Il semble que l'appel de 2 threads permette aussi une précision de l'ordre de la milliseconde sur un thread qui ne ferait que ça, mais je ne suis pas habitué du tout à ce type de programmation.

En fait j'ai surtout 2 - 3 problèmes:
- je ne sais pas comment faire pour afficher 1 spot parmi 4 emplacements de préférence sur un fond noir d'écran entier, et surtout que le balayage amène toujours la visualisation de ce spot au même moment, à 1/66 de seconde prêt (ou n'importe quelle fréquence de balayage, mais répétitive à l'identique, un écart de 1/66 de seconde risque de conduire à l'absence de résultat, alors que tel médicament ou maladie était handicapant - c'est très cher de faire une étude pour rien, alors qu'une différence réelle existe; et pire de croire qu'il n'y a pas de différence, pour les soins)
- des plantages que je ne comprend pas, j'ai XE2 Professional, donc distribuable, j'ai installé en essai XE3, les variables d'environnement ont débordé, j'ai désinstallé, mais XE2 plante à présent avec ce programme alors qu'il ne le faisait pas avant; XE3 académic marche très bien (acheté pour mon fils) mais l'usage est illégal, le support Embarcadero ne trouve rien de mieux que de me conseiller d'utliser Xe3 académic

Et surtout, je suis à Uzès, loin de Paris, de l'hôpital Saint-Antoine, avec sans doute une nécessité de faire beaucoup de va et vient pour la mise au point, que je ne pourrai faire, à moins que le programme ne soit quasiment fini: 2-3 déplacements au plus.

Je pense que le programme ferait un beau sujet de stage, ou de travail, pour des étudiants parisiens, le Pr de psychiatrie de Saint-Antoine le validerait sans aucun doute, tandis que depuis Uzès je risque, et le Pr aussi, d'être à la retraite tous les 2 avant que ca ne fonctionne..

Accessoirement, j'ai Visual C#10 professional, m'en sers peu, d'autant que son nettoyage mémoire pourrait comprommetre le "quasi temps réel", mais connais très mal ce language, et suis disposé à en faire don - via le service de psychiatrie - à celui qui prendrait ce programme en main.
Les sources Delphi actuelles sont achevées, disons aux 2/3, et feraient un base intéressante, mais nous savons tous que la finalisation d'un programme est ce qui prend le plus de temps.

Un amateur en recherche de stage ou de mention d'un travail original dans son CV ? Ca serait vraiment super.

Amitiés à tous,

MB32.

PS: j'envoie les sources Delphi à qui en veut pour approfondir la question. Et si +, les coordonnées du service de l'hôpital Saint-Antoine.
Messages postés
4200
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
2 janvier 2019
27
N'oublie pas également de passer le processus en haute priorité pour pas que d'autre threads viennent squatter le temps comme par exemple une mise à jours automatique ou connerie ralentissante de ce genre.

________________________________________________________
besoin de câbles audio, vidèo, informatique pas cher ?
Messages postés
16
Date d'inscription
vendredi 11 mai 2012
Statut
Membre
Dernière intervention
4 juillet 2013

Pour le chronométrage, je pense que ca ne posera pas trop de problème; au pire et en multithreads, la question est asez rebattue pour trouver plein de conseils sur les priorités de tâche, surtout là où l'unique tâche d'un thread serait de faire l'équivalent d'un sleep(1).

Je crois que les fonctions que j'ai citées permettent des mesures quasiment à l'unité d'horloge - quasiment la microseconde - , sauf si j'ai bien compris, au cas où le nombre de coeurs utilisés changeraient entre l'initialisation et la mesure.

En fait, ma grosse question est toujours celle du balayage: comment faire pour garantir que quand j'envoie l'ordre d'affichage d'un spot, il se passe toujours le même temps avant que le sujet testé visualise ce spot ? Sans le problème du balayage à 66 ou 70 Hz ?

A vue de nez, ca fait 15 millisecondes d'incertitude, et ca fait bien trop pour les effets mesurés.

J'ai bien dans les propriétés des fenêtres Delphi une propriété "bibuffered" ou quelque chose comme ca pour éviter le flickering à l'époque où les cartes vidéo n'avaient pas de mémoire à double accès, mais ca ne me dit pas quand le spot sera affiché, ca donnera juste un délai d'affichage que je ne maîtriserai pas plus.

Quelqu'un a t-il vu les sources correspondantes à cette propriété, dont les détails montreraient peut-être comment éviter le flickering avec les vieilles cartes vidéo sous Windows, donc l'équivalent de la lecture des adresses ou ports vidéo sous Windows malgré le pseudo-multitâches ?

Merci pour votre aide,

MB32.
Messages postés
4200
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
2 janvier 2019
27
Le truc c'est qu'aujourd'hui il y a tellement de surcouche que c'est trés trés dur de passé outre.

A l’époque, c'etait "plus simple" pour faire ça puisque qu'un seul programme ne pouvait tourner sur le système.

tu n'aura pas de latence de 15ms pure, que l'affichage soit de 60, 70, 100Hz, les écran LCD ou Led sont a 2 ou 5ms de latence aujourd'hui.
c'est imperceptible.

Par contre oui, savoir quand est-ce que le spot s'affiche, ça pose un problème.
Il faudrait peut etre passé par du lourd style DirectX ou OpenGL pour avoir un maximum d'accélération matérielle.
Et la on pourra controller pas mal de chose point de vue affichage.

En GDI ou GDI+ avec la surcouche du bureau, ce sera, déjà en accélération logicielle donc pourri, et aucun moyen d'être sur du temps entre le spot et l'appuis sur une touche.

Je pense à DirectX ou OpenGL car ça reviens au principe d'un jeux type FPS. Quand on est sur une map avec 15 bourrins, pleins d'effets etc, malgré tout, les click souris et clavier sont précis et rapides, on peu esquiver, tirer sans être ralentis par la machine.
A voir ?


________________________________________________________
besoin de câbles audio, vidèo, informatique pas cher ?
Messages postés
16
Date d'inscription
vendredi 11 mai 2012
Statut
Membre
Dernière intervention
4 juillet 2013

Tu approches la réponse je crois..

XE2/3 a une plateforme Firemonkey à laquelle je ne comprends rien, mais qui semble de servir d'OpenGL ou autres.

Je n'ai aucune idée de la façon d'écrire pour Firemonkey, y trourvai t-on la réponse à l'affichage temps réel ?

Tout est là, à mon avis.

Merci pour tes conseils

MB32.
Messages postés
2527
Date d'inscription
jeudi 15 janvier 2004
Statut
Membre
Dernière intervention
16 octobre 2019
13
DirectX ou OpenGL pour allumer un spot à l'écran, c'est pas un peu démesuré ?

Un lien qui peut t'intéresser.
Messages postés
2527
Date d'inscription
jeudi 15 janvier 2004
Statut
Membre
Dernière intervention
16 octobre 2019
13
Messages postés
16
Date d'inscription
vendredi 11 mai 2012
Statut
Membre
Dernière intervention
4 juillet 2013

Merci encore de votre aide, mais je ne m'y retrouve toujours pas.

Je semble pinailler, mais quand la carte vidéo rafraîchit à 60-70Hz, ca fait bien un écart possible de 15ms.

J'"affiche" en mettant en mémoire un spot à afficher, avec le balayage, selon que le balayage est juste au-dessus de la ligne d'affichage - ca fera zéro milliseconde -, ou en dessous, ca en fera 15.
Soit une incertitude de +- 7.5 ms, ce qui est bien trop élevé pour le test ou les effets mesurés sont de l'ordre de 10-20ms pour les derniers blocs de 100 tests. Ca va produire un "bruit" statistique insupportable, la non-mise en évidence de l'effet réel serait bien trop dommageable.

Pour les écrans qui donnent des rémanences de 2 millisecondes ou n'importe, ils affichent ce que dicte la carte vidéo. Et je ne connais pas de carte vidéo qui rafraîchirait par exemple à 500Hz..

La question reste de trouver une librairie qui garantisse que la nouvelle image à visualiser sera vue dans un temps fixe à qq millisecondes près. Le lien donné donne une fluidité globale satisfaisante pour une séquence vidéo, ici il s'agit d'avoir une durée quasi garantie pour juste une image.

C'est vraiment dommage, avec MSDOS c'était quasi trivial en disposant juste du listing assembleur du BIOS et d'un peu de doc, le programme demandait à peine 100-200 heures d'écriture avec les vérifications, etc.. et maintenant on a des machines qui turbinent 10^3 plus vite et c'est inextricable..

Et si FireMonkey ne sert à rien, en changeant d'OS pour un real time sur une machine plus ou moins moderne ? Des conseils ?

Merci encore,

MB32.
Messages postés
4200
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
2 janvier 2019
27
Et si, vus que tu as l'air de t'y connaitre en éléctronique, tu faisais un pupitre composé de boutons et de Led strob (donc très rapide)
avec sa propre horloge et balancer les informations au PC qui se chargerais des stat ?

________________________________________________________
besoin de câbles audio, vidèo, informatique pas cher ?
Messages postés
2527
Date d'inscription
jeudi 15 janvier 2004
Statut
Membre
Dernière intervention
16 octobre 2019
13
« Et si FireMonkey ne sert à rien, en changeant d'OS pour un real time sur une machine plus ou moins moderne ? Des conseils ? »

-Un PC industriel mono-tâche.


Mais le mieux serait de changer le protocole car il y aura toujours le problème du balayage de l'écran et, sur les PC de bureau modernes, l'incertitude du sheduler du système qui donne la main aux Threads de façon despotique et non prévisible.

Comme f0xi, je verrais bien des leds branchées à une sortie du PC et s'allumant en même temps que le lancement d'une horloge externe...
Messages postés
16
Date d'inscription
vendredi 11 mai 2012
Statut
Membre
Dernière intervention
4 juillet 2013

Caribensila,

Merci pour ton lien sur le graphisme temps réel qui est captivant, je l'ai mis dans les favoris du navigateur pour mieux l'étudier.

Jusqu'ici, les graphismes ne m'intéressaient pas du tout (et toujours pas d'ailleurs), je ne m'occupais que de calculs statistiques ou de traitement de données; je n'ai que vaguement survolé les Canvas en lisant les manuels et mon embryon de programme n'utilise d'ailleurs que des dialogues, par paresse pour éviter de m'embêter avec des Paint et autres, et je ne savais même pas qu'un objet Screen et une méthode Monitors existaient.

C'est justement pour ça que je sollicitais de l'aide, pour proposer un stage ou autres, d'ici que je sois vraiment au point je serai à la retraite (dans 8 ans maintenant ).

D'accord, Canvas affiche plus vite un objet créé en mémoire, et je suis heureux que tu me l'apprennes, il faut l'utiliser.

Aurais-tu une idée sur une méthode qui permettrait de savoir que le balayage vertical est en train de revenir des lignes basses vers la plus haute, dans n'importe quelle interface ou objet que ce soit ? Si cette notion était accessible tout problème disparaîtrait.

MB32.
Messages postés
2527
Date d'inscription
jeudi 15 janvier 2004
Statut
Membre
Dernière intervention
16 octobre 2019
13
« Aurais-tu une idée sur une méthode qui permettrait de savoir que le balayage vertical est en train de revenir des lignes basses vers la plus haute, dans n'importe quelle interface ou objet que ce soit ? »


Pour Windows, l'interface dont tu parles est un Device Context.

Je ne pense pas que cette information soit disponible. D'ailleurs, même la carte graphique ne doit pas en disposer car je vois mal comment exploiter une telle information de façon pratique car elle est obsolète aussitôt fournie.

En revanche, il doit être possible (mais je n'ai jamais tenté) de synchroniser les affichages avec le rafraîchissement verticale de l'écran.
En effet, on peut connaître et éventuellement changer la fréquence de rafraîchissement verticale grâce à l'API ChangeDisplaySettings (avec le champ dmDisplayFrequency du record TDeviceMode).
Mais, sauf à fixer l'erreur de mesure à une valeur stable (mais inconnue!), je ne pense pas que cela te sera bien utile...

Franchement, je ne pense pas que les systèmes modernes soient bien pratiques pour faire le genre de manip que tu souhaites.



PS: Note que la synchronisation dont je parle doit être facilement accessible dans DirectX ou OpenGL.
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
10
salut,
vouloir faire du temps réel avec un PC est une aberration
la simple gestion des taches de Windows ne peut vous garantir une répétitivité meilleure que 7ms.

pour le problème que tu soumets une solution triviale serait d'utiliser un micro-contrôleur relier au PC.
le micro-contrôleur se chargeant d'allumer aléatoirement une diode parmi 4 en lançant un timer , de scruter le boitier et enfin d'envoyer le résultat au PC.
Avec une carte de test à une trentaine d'euros et 2 heures de programmation tu devrais obtenir le résultat demandé.
A+
JLEn
Messages postés
16
Date d'inscription
vendredi 11 mai 2012
Statut
Membre
Dernière intervention
4 juillet 2013

Merci pour vos réponses, que je lis avec du retard.

Pour les LED, ca changerait la valeur du test, j'indiquais dans le début du fil que les tests psychométriques sont très codifiés, dans le test cité, luminosité de la pièce et de l'écran, écart visuel angulaire entre emplacements du spot, distance boutons du boîtier, ..

@Caribensila: si un port ou un emplacement mémoire pouvait être lu, comme on pouvait le faire sous MSDOS, son changement d'état sur les "PC compatibles" de l'époque indiquait que le balayage a atteint le point le plus bas, et va reprendre en haut à gauche.
Bien sûr, c'est volatil, mais c'est comme ça qu'à l'époque on pouvait écrire dans la mémoire d'écran sans provoquer un scintillement.
Dans le cas du test que je rêve de transposer sous Windows, si on pouvait savoir quand cet évènement se produit, c'est le moment idéal pour "afficher" le spot: le temps du balayage étant répétitif, la mesure relative est identique et je n'ai plus les +- 7.5 ms d'erreur éventuelle.
- évidemment en supposant que les tâches ont une priorité maximale, et en enlevant tout ce qu'on peut d'autres programmes de la machine, qui est a priori dédiée et ne servirait qu'à ca. On peut la mettre hors réseau, etc..
- le plus simple serait d'y mettre MSDOS, mais Micro$oft n'en vend plus..


MB32.
Messages postés
16
Date d'inscription
vendredi 11 mai 2012
Statut
Membre
Dernière intervention
4 juillet 2013

Mes idées sont toujours rares, je ne vois toujours pas comment régler ou au moins minimiser ce problème du moment précis où le spot deviendra visible.

Pour l'anecdote, un exemple de programme qui pouvait être utilisé sous DOS avec une carte VGA:

mov dx,0x03DA
Debut:
in al,dx
and al,0x08
jz Debut
--> ici le balayage est fini et va reprendre depuis le haut, c'est le moment d'afficher en mémoire d'écran


Je continue en ignorant l'incertitude de l'écran, je verrai peut-être si le "bruit" du à cette erreur n'est malgré mes craintes pas trop important, même si en théorie il devrait l'être.

Comme l'affichage est graphique, donc pas d'un caractère "texte" à l'ancienne, mais d'un cercle, carré, .. j'aimerais avoir votre avis pour que le programme perde le moins de temps possible pour afficher ce dessin: dialogue ou canevas, methode à utiliser pour dessiner le cercle ou carré, peut-être peut-on dessiner dans une zone mémoire et switcher d'un coup le contrôleur vidéo d'une plan mémoire à l'autre, comme dans le temps avec les VGA ??

Merci de vos conseils pour un affichage ultra rapide avec Delphi (ou C++, ou FireMonkey si vous pensez que c'est nécessaire - j'en ai écrit un gros bout, mais je peux encore changer de plateforme).

MB32.
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
10
quelque soit la plateforme cela ne changera pas le problème qui est inhérent à windows qui n'est pas et ne sera pas un système temps réel; pas plus qu'il n'est réellement multitâche même en multicœur il doit partager ses ressources entre de nombreuses applications (compter entre 1000 et 3000 tâches(threads) tournant simultanément)
pour faire simple l'ensemble des tâches est mis en pile et est traité périodiquement; la périodicité peut être modifiée pas sa priorité.
Windows accorde un certains nombre de cycles machine et passe à la suivante sans garantie que la tâche soit terminée.
A une époque il a été fait des tests sur un système équipé de XP et qui vérifiait la synchronisation de 2 programmes qui avait démontrer qu'il était impossible de descendre en dessous de 10ms.
En plus dans votre application vous utilisez des ressources partagées (carte graphiques) ou peu performantes (clavier/souris)
Dans ce cas il serait recommandé d'utiliser les API DirectX sans que l'on puisse garantir la mesure du temps de réaction.
Messages postés
16
Date d'inscription
vendredi 11 mai 2012
Statut
Membre
Dernière intervention
4 juillet 2013

Bonjour,

Les sections critiques en temps sont l'affichage, et un circuit Phidget avec une librairie qui déclenche une interruption quand un bouton ferme une entrée binaire.

Par contre elles ne se servent ni de la souris ni du clavier.

Il est possible que l'interruption Phidget ne fasse que placer l'évènement dans un buffer circulaire, puis passe un message dans la boucle Windows; ou bien qu'elle appelle directement la routine du programme greffée sur le hook, au risque de perdre quelque chose si plusieurs entrées sont fermées en succession rapide, je ne sais pas quelle option Phidget utilise dans la librairie.

Je n'ai pas trop le choix de toute façon, à moins qu'il soit possible de faire tourner une machine sous DOS: j'ai vu qu'on peut se procurer TP7 gratuitement, si c'était aussi le cas pour le DOS, en bricolant des routines IRQ pour le port série (qui a 4 broches pouvant être lues et déclencher une interruption), en bricolant le timer il n'y aurait pas de souci.

Les API DirectX permettent elles d'afficher avec un meilleur contrôle de la vitesse d'écriture et de la visualisation effective ?

MB32.
Messages postés
16
Date d'inscription
vendredi 11 mai 2012
Statut
Membre
Dernière intervention
4 juillet 2013

Bonsoir,

J'ai trouvé en cherchant mieux:

- E-Prime qui sert justement à écrire des test psychologiques, synchro avec les rafraîchissement, se réclamant de la milliseconde.. Mais à 800$, en simili VB, donc très cher pour une synchro d'écran et un timer accélère. 15000 utilisateurs prétendus.
- OpenSesame, je ne sais pas trop s'il est gratuit, apparemment multiplateformes et Open GL, synchro écran aussi ?
- et un article utilisant SDK et ActiveX pour se synchroniser, et un timer rapide, avec des appels pas toujours de fonctions officielles, utilisant le port sus-cité et sur le ring zéro, touffu à comprendre. Pas forcément pour toutes versions >= XP, NT cité, donc portage ne marchant pas forcément; et exemples pour vidéo. Une fonction intéressante d'écriture en buffer avec bascule rapide, et d'autres choses encore.

Qu'en pensez-vous ? Je serais content d'avoir votre avis.

Merci,


MB32.