TIMER MICROSECONDE PAS TRÉS PRECIS

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

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 mini= 400ns temps maxi =15ms 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

Merci pour ses précisions Jlen

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 )

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

la M.. sur la textbox évoluée recommence!!

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.

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