[thread] exemple de "timer microseconde pas trés precis"

Soyez le premier à donner votre avis sur cette source.

Vue 12 037 fois - Téléchargée 845 fois

Description

J'ai besoin d'un timer assez précis pour gérer un afficheur à persistance rétinniene, c'est ainsi que l'ai codé ce truc (il est probable d'en trouver des semblables sur internet).
Ce petit timer est basé sur le code de rylryl : http://www.delphifr.com/codes/PETITE-PAUSE-MICROSECONDE_30901.aspx
Ce timer est censé étre précis à la microseconde, cependant, sur mon Athlon 2100Mhz (476 nanoseconde/front) les résultats semblent médiocres : en de créant un signale carré sur le port //, d'une periode d'une milliseconde, on voit a l'oscilloscope qu'une periode foire de temps en temps, alors qu' avec un timer Windows, le signale est impecable.
J'aimerais trouver la cause de ce probleme, vous pourez peut-etre m'aider :
- Mon code bug ?
- QueryPerformanceCounter pas assez fiable ?
- Le rapport (Frequence processeur)/(periode esperée) est trop faible ? (pourtant, 1000 microsecondes <=> 2000 fronts, ce qui est pas mal je pense)

Source / Exemple :


Code complétement commenté dans le ZIP !

Conclusion :


Merci de critiquer au maximum mon code pour l'améliorer (et moi aussi par la méme occasion) :-)

Codes Sources

A voir également

Ajouter un commentaire Commentaires
Messages postés
20
Date d'inscription
mardi 30 août 2005
Statut
Membre
Dernière intervention
8 mai 2010

SALUT MES AMIS: j'ai un probleme avec le timer de Delphi je voudrer ajouter une parametre dans timer et j'arrive pas a ajouter alors aider moi svp, mon problem c'est a chaque fois on clic sur la form un nouveau boutton doit etre creer et la valaur 100 est affecter au caption de ce button j'usqua se mement c'est simple mais le probleme qui se pose: j'ai associe a chaque button une timer qui creer de meme principe de button maintenat je voudrer décrementer la valeur de chaque button indepondament au autres button jusqu'a arrivé a 0. merci d'avance et j'attend votre reponse.
Messages postés
3
Date d'inscription
dimanche 5 mars 2006
Statut
Membre
Dernière intervention
18 juin 2006

ce programme n'existe pas ??????????????
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
12
ACHP132--> à condition de pas travailler sous XP puisque dans ce cas il n'y a pas de dos mais seulement une émulation du dos gérer par Windows et il reprend la main régulièrement pour traiter les messages.
Comme tu travailles en temps partagé tu ne garantiras pas la durée du traitement (ni à la milliseconde et encore moins à la microseconde)
Messages postés
50
Date d'inscription
mercredi 2 avril 2003
Statut
Membre
Dernière intervention
9 mai 2009

y'a pu qu'a sortir le free pascal ou le TP7 et faire un programme sous DOS... lol
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
12
pour éviter l'appel a application.ProcessMessage il faudrait passer par une gestion évènementielle (comme le fait le timer) et ne gérer que l'évènement. Mais même dans ce cas la précision n'est pas garantie en effet Windows place l'évènement dans une file de traitement et il ne sera traité que lorsque les précédents auont été traité. La réaction est meilleure que le traitement du thread seul mais il n'est pas "en temps réel" mais en batch (par exemple si un évènement comme un ontimer est en court de traitement l'évenement ne sera traité qu'après et cela peut prendre des millisecondes) l'avantage est que le thread continue d'être traité et qu'on ne cumule pas les erreurs, enfin dans la limite de charge du processeur. Comme il n'y a qu'un seul processeur il faut bien qu'il traite toutes les demandes!
On rencontre d'ailleurs le même problème quand on gère des interruptions: on donne des priorités mais il y a toujours des taches favorisées et d'autres qui attendent; quand on travaille en assembleur et qu'il n'y a pas trop de processus en cours on arrive à s'en sortir mais dans le cas de window s'est pratiquement impossible (le nombre et la priorité des processus peut varier)
Afficher les 18 commentaires

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.