TIMER MICROSECONDE PAS TRÉS PRECIS

Messages postés
1651
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
- - Dernière réponse : jlen100
Messages postés
1651
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
- 16 févr. 2006 à 13:46
salut à tous,

puisqu'un bug informatique m'empêche de répondre directement en commentaire de cette source je le fairais par cet intermediaire.

Il est pratiquement impossoble d'obtenir par soft un timer pécis
inférieur à la millisecond si l'on passe par la gestion Windows (il
doit traiter plusieurs dizaines de threads)

plusieurs solutions s'offre alors:

- faire des routines qui bloque windows pendant le traitement mais on
est malgré tout limité par la gestion de Windows pour ses processus
critiques : il lui devient impossible de récuperer le retard pris dans
le tritement--->plantage du systeme.

- faire des routines d'interruption mais là ce n'est pas possible
directement sous DELPHI. il faut passer par l'assembleur (à manipuler
avec précaution)

- passer par des cartes d'extension c'est du hard mais ça marche
beaucoup mieux.(la mise au point n'est pas une partie de plaisir!!)
soit on travaille en 'inside' et on génère des interruption dans ce cas
le traitement est mixte : la carte assure le timming et on place le
taritement dans le vecteur; soit on travaille en 'outside' te la
carte assure la totalité de l'opération on ajoute
simplement une communication entre l'application et la carte
(cela va de la rs232 à l'ethernet tout dépend du débit que l'on veut
assurer)

pour répondre à wolf heureusement que dans ton PC il y a des logiciels
qui travaille en dessous de la seconde sinon il deviendrait muet sourd
et aveugle: il faut savoir que le systeme de convertion travaille avec
des fréquences d'échantillonnage élevé (~44kHz pour le son à >100Mhz
pour l'image) une simple souris à 9600 bauds (soit <0,1ms par
bit)demande une fréquence de base de près de 1MHz . Sans parler de
certaines cartes spécialisée: dans mon cas j'utilise une carte oscillo
qui échatillonne à 400MHz et ce n'est pas la plus rapide du marché.

c'est aussi pour ces raisons que l'on fait appel à des circuit spécialisés



@+

jlen
Afficher la suite 

7 réponses

Messages postés
1651
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
6
0
Merci
pour le probléme du temps passé dans l'Application.ProcessMessage je ne sais pas s'il existe une routine permettant de le vérifier.
dans mon appli je m'étais livré à l'expérience suivante:
1) pour déterminer les temps de calcul propre aux routines j'envoie sur le port ethernet (facilement accessible et rapide pour ne pas perturber la mesure)une trame et je mets un analyseur sur le port ceci me permets de déterminer l'interval de temps entre chaque trame sachant que je n'attends pas de réponse c'est en quelque sorte une boucle ouverte
2) dans un premier temps je place cette trame dans une boucle for . Avec un processeur à 2,6Ghz l'interval est ~100ns ceci donne donc le temps pour efffectuer une iteration.
3) ensuite je place cette trame dans un thread en priorité haute et j'appelle l'Application.ProcessMessage à chaque itération.
résultat
temps mini400ns temps maxi15ms
conclusion les threads ne sont pas adaptés au processus rapides exigeant un timming précis
je n'ai pas testé mais l'on devrait peut etre obtenir une meilleure précision en gerant les events de windows (sorte d'interruption logiciel) je ne l'ai pas fait car meme 100ns était encore trop long pour moi.
@+
jlen
Commenter la réponse de jlen100
0
Merci
Merci pour ses précisions Jlen
Commenter la réponse de Utilisateur anonyme
Messages postés
44
Date d'inscription
vendredi 27 décembre 2002
Statut
Membre
Dernière intervention
15 février 2006
0
Merci
Ok, merci beaucoup, je pense que je vais garder le timer classique 1ms, si cela ne vas pas, je passerais par un microcontroleur (qui ne tourne pas sous windows, lui )
Commenter la réponse de Sylvainlefou
Messages postés
1651
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
6
0
Merci
c'est sur que dans ton cas le timer classique doit faire l'affaire car s'il n'est pas précis sur des petits intervals il présentent une bonne reproductibilité sur de longues périodes (en fait même s' il y a erreur sur une periode elle n'est pas cumulative tant qu'on le laisse enabled)
je l'uitlise reglé à 50ms pour faire des scans de process sans qu'il présente de problème les actions demandant des timing très courts étant réalisées par un carte à microcontroleur.
@+
jlen
Commenter la réponse de jlen100
Messages postés
1651
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
6
0
Merci
la M.. sur la textbox évoluée recommence!!
Commenter la réponse de jlen100
Messages postés
3982
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
9
0
Merci
Heu pardon, ça à m'a l'air très pro ce topic. Mais bon, je m'exprime quand même.

J'ai été confronté à ce probléme. La première solution que j'ai trouvé à été d'utiliser le compteur TSC du processeur, accessible via l'instruction assembleur RDTSC. Ce compteur s'incrémente à chaque front d'horloge du processeur.

Cependant, la régularité de ce compteur n'est pas garantit, sur certains processeurs de portables nottement.

Heureusement, windows permet d'accéder aux compteur hardware, via les API QueryPerformCounter et QueryPerformFrequency. Le premier renvoie la fréquence du compteur hardware, et la deuxième la valeur du compteur.

Je n'ai pas trouvé le source situé plus haut, donc désolé s'il utilisait déjà ces API.

Néanmoins, comme le dit jlen100, cette méthode est ultra précise, dans un certain nombre de cas (Boucler sur un Sleep(0) en attendant une certaine valeur du compteur).

Car si windows à la mauvaise idée de passer la main à un trhead un peu long, la valeur est dépassée. Donc on à généralement des résultat du style :

510 µs
504 µs
503 µs
13345 µs
505 µs

C'est les joies du multitâche, et comme le dit jlen100, carte d'extension ou instruction systèmes obligatoires pour passer outre.
Commenter la réponse de cs_rt15
Messages postés
1651
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
6
0
Merci
salut rt15

j'avais posté mes commentaires ici suite à quelques problèmes de post

tu peux trouver la source ici



il utilise effectivement ces API mais pur ne pas bloquer le process il
les a incluses dans un thread en association avec un
Application.ProcessMessage (pour résumer mais il vaut mieux voir
la source) ce qui à pour conséquence que la fin du thread n'est
effectivement donnée que quand Windows le traite avec le résultat que
tu as donné.

Une solution aurais été de le traiter en event mais même dans ce cas
c'est Windows qui traite l'event et la précision n'est pas garantie.

La véritable solution est de provoquer un interruption mais ceci n'est
accessible qu'en langage assembleur et XP n'aime pas trop ce genre de
manip: il faut que le traitement soit suffisament court pour ne pas
perturber la gestion de thread et c'est génarelement assez pour avoir
le resultat dans l'application (en général on met le traitement en DLL)

Pour les process rapides demandant des timing très précis on fait appel à de cartes d'extension ou des circuits spécialisés.

l'expérience montre que Windows n'est pas du tout adaptée à ce genre de
situation (d'ailleurs il n'a pas été développé pour cela) et que les
solutions logicielles finissent par couter plus chères que la carte
d'extension.



@+

jlen
Commenter la réponse de jlen100