Je suis à la recherche d'un timer pouvant descendre en-dessous de la
milliseconde, typiquement 100 µs. Dans l'aide de l'API, je vois bien des
trucs genre QueryPerformanceCounter() et QueryPerformanceFrequency(),
mais je connais pas ce domaine. Le but est d'avoir un cycle d'attente
variable entre 100 µs et 10 ms avec une précision de l'ordre de 10%.
Quelqu'un aurait des idées, des liens ou même un bout de code ?
AMHA en cherchant dans les archives de ce NG tu devrais avoir des pistes. Notament quelques discussions avec Vincent Burel (VB) ou même moi.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Vincent Burel
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in message news:447eea0f$0$20164$
Bonjour
Je suis à la recherche d'un timer pouvant descendre en-dessous de la milliseconde, typiquement 100 µs. Dans l'aide de l'API, je vois bien des trucs genre QueryPerformanceCounter() et QueryPerformanceFrequency(), mais je connais pas ce domaine. Le but est d'avoir un cycle d'attente variable entre 100 µs et 10 ms avec une précision de l'ordre de 10%. Quelqu'un aurait des idées, des liens ou même un bout de code ?
qu'est ce que vous cherchez à faire en fait ?
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in
message news:447eea0f$0$20164$ba4acef3@news.orange.fr...
Bonjour
Je suis à la recherche d'un timer pouvant descendre en-dessous de la
milliseconde, typiquement 100 µs. Dans l'aide de l'API, je vois bien des
trucs genre QueryPerformanceCounter() et QueryPerformanceFrequency(),
mais je connais pas ce domaine. Le but est d'avoir un cycle d'attente
variable entre 100 µs et 10 ms avec une précision de l'ordre de 10%.
Quelqu'un aurait des idées, des liens ou même un bout de code ?
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in message news:447eea0f$0$20164$
Bonjour
Je suis à la recherche d'un timer pouvant descendre en-dessous de la milliseconde, typiquement 100 µs. Dans l'aide de l'API, je vois bien des trucs genre QueryPerformanceCounter() et QueryPerformanceFrequency(), mais je connais pas ce domaine. Le but est d'avoir un cycle d'attente variable entre 100 µs et 10 ms avec une précision de l'ordre de 10%. Quelqu'un aurait des idées, des liens ou même un bout de code ?
qu'est ce que vous cherchez à faire en fait ?
Bertrand Lenoir-Welter
Arnold McDonald (AMcD) :
AMHA en cherchant dans les archives de ce NG tu devrais avoir des pistes. Notament quelques discussions avec Vincent Burel (VB) ou même moi.
Ok, merci. Je tiens ton fil avec VB.
Arnold McDonald (AMcD) :
AMHA en cherchant dans les archives de ce NG tu devrais avoir des pistes.
Notament quelques discussions avec Vincent Burel (VB) ou même moi.
AMHA en cherchant dans les archives de ce NG tu devrais avoir des pistes. Notament quelques discussions avec Vincent Burel (VB) ou même moi.
Ok, merci. Je tiens ton fil avec VB.
Bertrand Lenoir-Welter
Vincent Burel :
qu'est ce que vous cherchez à faire en fait ?
Sortir des impulsions sur les bits du port parallèle, jusqu'à 5 ou 10 KHz grand maxi. Assez classique, semble-t-il. Ca me dérange pas que la fréquence ne soit pas trop précise, mais par contre, l'éternel problème est la préemption du scheduler. S'il me fait un trop gros trou au milieu d'une trame, je serai embêté.
Bon, je viens de me plonger dans le "Windows Internals" et je pense avoir déjà quelques bons tuyaux.
Vincent Burel :
qu'est ce que vous cherchez à faire en fait ?
Sortir des impulsions sur les bits du port parallèle, jusqu'à 5 ou 10
KHz grand maxi. Assez classique, semble-t-il. Ca me dérange pas que la
fréquence ne soit pas trop précise, mais par contre, l'éternel problème
est la préemption du scheduler. S'il me fait un trop gros trou au milieu
d'une trame, je serai embêté.
Bon, je viens de me plonger dans le "Windows Internals" et je pense
avoir déjà quelques bons tuyaux.
Sortir des impulsions sur les bits du port parallèle, jusqu'à 5 ou 10 KHz grand maxi. Assez classique, semble-t-il. Ca me dérange pas que la fréquence ne soit pas trop précise, mais par contre, l'éternel problème est la préemption du scheduler. S'il me fait un trop gros trou au milieu d'une trame, je serai embêté.
Bon, je viens de me plonger dans le "Windows Internals" et je pense avoir déjà quelques bons tuyaux.
Arnold McDonald \(AMcD\)
Bertrand Lenoir-Welter wrote:
Sortir des impulsions sur les bits du port parallèle, jusqu'à 5 ou 10 KHz grand maxi.
À partir de quel matériel/générateur, etc ? Je connais pas grand-chose dans ce domaine, c'est juste histoire d'apprendre hein.
l'éternel problème est la préemption du scheduler.
Oui. Quand on veux faire du timing de précision , faut pas beaucoup de threads qui tournent sur ta machine. Enfin bon, pas d'emule, serveurs, hooks, keyloggers, applis à 12.000 thread ou, pire, 10 timers et tout ce type d'applis quoi...
Bon, je viens de me plonger dans le "Windows Internals" et je pense avoir déjà quelques bons tuyaux.
La 4th edition est la plus complète sur le sujet. Mais comme dit ailleurs, je te souhaite du courage, c'est pas simple.
Tiens nous au courant, ça peut déboucher sur des problèmes/solutions cools à résoudre. Et puis, ça meublera ce forum.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Bertrand Lenoir-Welter wrote:
Sortir des impulsions sur les bits du port parallèle, jusqu'à 5 ou 10
KHz grand maxi.
À partir de quel matériel/générateur, etc ? Je connais pas grand-chose dans
ce domaine, c'est juste histoire d'apprendre hein.
l'éternel
problème est la préemption du scheduler.
Oui. Quand on veux faire du timing de précision , faut pas beaucoup de
threads qui tournent sur ta machine. Enfin bon, pas d'emule, serveurs,
hooks, keyloggers, applis à 12.000 thread ou, pire, 10 timers et tout ce
type d'applis quoi...
Bon, je viens de me plonger dans le "Windows Internals" et je pense
avoir déjà quelques bons tuyaux.
La 4th edition est la plus complète sur le sujet. Mais comme dit ailleurs,
je te souhaite du courage, c'est pas simple.
Tiens nous au courant, ça peut déboucher sur des problèmes/solutions cools à
résoudre. Et puis, ça meublera ce forum.
Sortir des impulsions sur les bits du port parallèle, jusqu'à 5 ou 10 KHz grand maxi.
À partir de quel matériel/générateur, etc ? Je connais pas grand-chose dans ce domaine, c'est juste histoire d'apprendre hein.
l'éternel problème est la préemption du scheduler.
Oui. Quand on veux faire du timing de précision , faut pas beaucoup de threads qui tournent sur ta machine. Enfin bon, pas d'emule, serveurs, hooks, keyloggers, applis à 12.000 thread ou, pire, 10 timers et tout ce type d'applis quoi...
Bon, je viens de me plonger dans le "Windows Internals" et je pense avoir déjà quelques bons tuyaux.
La 4th edition est la plus complète sur le sujet. Mais comme dit ailleurs, je te souhaite du courage, c'est pas simple.
Tiens nous au courant, ça peut déboucher sur des problèmes/solutions cools à résoudre. Et puis, ça meublera ce forum.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Bertrand Lenoir-Welter
Arnold McDonald (AMcD) :
À partir de quel matériel/générateur, etc ? Je connais pas grand-chose dans ce domaine, c'est juste histoire d'apprendre hein.
C'est en sortie, pas en entrée. Je veux produire des impulsions qui seront utilisées par un bout de hard derrière. L'idée, c'est de faire tourner des moteurs pas-à-pas. Les variations de fréquence/vitesse, c'est pas trop grave. Mais si le scheduler saucissonne mon temps CPU, ça va hacher le mouvement.
Oui. Quand on veux faire du timing de précision , faut pas beaucoup de threads qui tournent sur ta machine. Enfin bon, pas d'emule, serveurs, hooks, keyloggers, applis à 12.000 thread ou, pire, 10 timers et tout ce type d'applis quoi...
Ben même sans ça, suffit que Windows décide de faire un peu de ménage dans la mémoire pour que je perde des blocs de millisecondes.
Dans le fil de l'année dernière avec VB, Pierre Maurette parle de "ruses immondes à base de passage sauvage en ring0". Pour le coup, ça m'intéresse, ben tiens ! Quelqu'un dans la salle peut m'en dire plus ?
La 4th edition est la plus complète sur le sujet.
Bonne nouvelle, c'est celle que j'ai. Même pas fait exprès.
Arnold McDonald (AMcD) :
À partir de quel matériel/générateur, etc ? Je connais pas grand-chose dans
ce domaine, c'est juste histoire d'apprendre hein.
C'est en sortie, pas en entrée. Je veux produire des impulsions qui
seront utilisées par un bout de hard derrière. L'idée, c'est de faire
tourner des moteurs pas-à-pas. Les variations de fréquence/vitesse,
c'est pas trop grave. Mais si le scheduler saucissonne mon temps CPU, ça
va hacher le mouvement.
Oui. Quand on veux faire du timing de précision , faut pas beaucoup de
threads qui tournent sur ta machine. Enfin bon, pas d'emule, serveurs,
hooks, keyloggers, applis à 12.000 thread ou, pire, 10 timers et tout ce
type d'applis quoi...
Ben même sans ça, suffit que Windows décide de faire un peu de ménage
dans la mémoire pour que je perde des blocs de millisecondes.
Dans le fil de l'année dernière avec VB, Pierre Maurette parle de "ruses
immondes à base de passage sauvage en ring0". Pour le coup, ça
m'intéresse, ben tiens ! Quelqu'un dans la salle peut m'en dire plus ?
La 4th edition est la plus complète sur le sujet.
Bonne nouvelle, c'est celle que j'ai. Même pas fait exprès.
À partir de quel matériel/générateur, etc ? Je connais pas grand-chose dans ce domaine, c'est juste histoire d'apprendre hein.
C'est en sortie, pas en entrée. Je veux produire des impulsions qui seront utilisées par un bout de hard derrière. L'idée, c'est de faire tourner des moteurs pas-à-pas. Les variations de fréquence/vitesse, c'est pas trop grave. Mais si le scheduler saucissonne mon temps CPU, ça va hacher le mouvement.
Oui. Quand on veux faire du timing de précision , faut pas beaucoup de threads qui tournent sur ta machine. Enfin bon, pas d'emule, serveurs, hooks, keyloggers, applis à 12.000 thread ou, pire, 10 timers et tout ce type d'applis quoi...
Ben même sans ça, suffit que Windows décide de faire un peu de ménage dans la mémoire pour que je perde des blocs de millisecondes.
Dans le fil de l'année dernière avec VB, Pierre Maurette parle de "ruses immondes à base de passage sauvage en ring0". Pour le coup, ça m'intéresse, ben tiens ! Quelqu'un dans la salle peut m'en dire plus ?
La 4th edition est la plus complète sur le sujet.
Bonne nouvelle, c'est celle que j'ai. Même pas fait exprès.
Arnold McDonald \(AMcD\)
Bertrand Lenoir-Welter wrote:
L'idée, c'est de faire tourner des moteurs pas-à-pas. Les variations de fréquence/vitesse, c'est pas trop grave. Mais si le scheduler saucissonne mon temps CPU, ça va hacher le mouvement.
Peut-être te faudrait-il un matériel spécial ? Genre :
http://www.lextronic.fr/Comfile/golden.htm
Pour le ring0, sous XP heu, ça risque d'être chaud. AMHA, pour un timer précis doit mieux valoir passer par un driver. Je viens de farfouiller dans ma doc, peut-être devrais-tu jeter un oeil sur le bouquin de Walter Oney (programming the microsoft windows driver model). La seconde edition. Chapitre 4, sur la synchronization, il parle des timers kernel, des notifications pour les timers qui utilisent le DPC, etc.
Sinon, cherche peut-être dans des domaines comme (step-by)step motors coding/programmation/synchronisation sur le Net. J'ai d'ailleurs l'impression que, dans ce domaine, pas mal de trucs utilisent du matos externe (RTC aditionnels par exemple).
-- Arnold McDonald (AMcD) - Help #40/2006
http://arnold.mcdonald.free.fr/
Bertrand Lenoir-Welter wrote:
L'idée, c'est de faire
tourner des moteurs pas-à-pas. Les variations de fréquence/vitesse,
c'est pas trop grave. Mais si le scheduler saucissonne mon temps CPU,
ça va hacher le mouvement.
Peut-être te faudrait-il un matériel spécial ? Genre :
http://www.lextronic.fr/Comfile/golden.htm
Pour le ring0, sous XP heu, ça risque d'être chaud. AMHA, pour un timer
précis doit mieux valoir passer par un driver. Je viens de farfouiller dans
ma doc, peut-être devrais-tu jeter un oeil sur le bouquin de Walter Oney
(programming the microsoft windows driver model). La seconde edition.
Chapitre 4, sur la synchronization, il parle des timers kernel, des
notifications pour les timers qui utilisent le DPC, etc.
Sinon, cherche peut-être dans des domaines comme (step-by)step motors
coding/programmation/synchronisation sur le Net. J'ai d'ailleurs
l'impression que, dans ce domaine, pas mal de trucs utilisent du matos
externe (RTC aditionnels par exemple).
L'idée, c'est de faire tourner des moteurs pas-à-pas. Les variations de fréquence/vitesse, c'est pas trop grave. Mais si le scheduler saucissonne mon temps CPU, ça va hacher le mouvement.
Peut-être te faudrait-il un matériel spécial ? Genre :
http://www.lextronic.fr/Comfile/golden.htm
Pour le ring0, sous XP heu, ça risque d'être chaud. AMHA, pour un timer précis doit mieux valoir passer par un driver. Je viens de farfouiller dans ma doc, peut-être devrais-tu jeter un oeil sur le bouquin de Walter Oney (programming the microsoft windows driver model). La seconde edition. Chapitre 4, sur la synchronization, il parle des timers kernel, des notifications pour les timers qui utilisent le DPC, etc.
Sinon, cherche peut-être dans des domaines comme (step-by)step motors coding/programmation/synchronisation sur le Net. J'ai d'ailleurs l'impression que, dans ce domaine, pas mal de trucs utilisent du matos externe (RTC aditionnels par exemple).
-- Arnold McDonald (AMcD) - Help #40/2006
http://arnold.mcdonald.free.fr/
Bertrand Lenoir-Welter
Arnold McDonald (AMcD) :
Peut-être te faudrait-il un matériel spécial ? Genre : http://www.lextronic.fr/Comfile/golden.htm
Négatif. Si c'est pour ajouter un PIC externe, autant acheter une carte de contrôle existante. Mais le but est d'attaquer directement une carte de puissance pour moteurs pas-à-pas sans aucun intermédiaire. Ces cartes se ressemblent toutes plus ou moins et ont en commun de demander pour chaque moteur un signal Clock qui fait avancer d'un pas et un signal Direction pour faire tourner dans un sens ou dans l'autre. Les deux sont du TTL donc compatible port parallèle.
Pour le ring0, sous XP heu, ça risque d'être chaud.
J'y connais rien. Pourquoi chaud ?
Arnold McDonald (AMcD) :
Peut-être te faudrait-il un matériel spécial ? Genre :
http://www.lextronic.fr/Comfile/golden.htm
Négatif. Si c'est pour ajouter un PIC externe, autant acheter une carte
de contrôle existante. Mais le but est d'attaquer directement une carte
de puissance pour moteurs pas-à-pas sans aucun intermédiaire. Ces cartes
se ressemblent toutes plus ou moins et ont en commun de demander pour
chaque moteur un signal Clock qui fait avancer d'un pas et un signal
Direction pour faire tourner dans un sens ou dans l'autre. Les deux sont
du TTL donc compatible port parallèle.
Pour le ring0, sous XP heu, ça risque d'être chaud.
Peut-être te faudrait-il un matériel spécial ? Genre : http://www.lextronic.fr/Comfile/golden.htm
Négatif. Si c'est pour ajouter un PIC externe, autant acheter une carte de contrôle existante. Mais le but est d'attaquer directement une carte de puissance pour moteurs pas-à-pas sans aucun intermédiaire. Ces cartes se ressemblent toutes plus ou moins et ont en commun de demander pour chaque moteur un signal Clock qui fait avancer d'un pas et un signal Direction pour faire tourner dans un sens ou dans l'autre. Les deux sont du TTL donc compatible port parallèle.
Pour le ring0, sous XP heu, ça risque d'être chaud.
J'y connais rien. Pourquoi chaud ?
Vincent Burel
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in message news:447f1d6d$0$20159$
Vincent Burel : > > qu'est ce que vous cherchez à faire en fait ?
Sortir des impulsions sur les bits du port parallèle, jusqu'à 5 ou 10 KHz grand maxi. Assez classique, semble-t-il. Ca me dérange pas que la fréquence ne soit pas trop précise, mais par contre, l'éternel problème est la préemption du scheduler. S'il me fait un trop gros trou au milieu d'une trame, je serai embêté.
Je genre de chose se fait en faisant du streaming. On sort une quantité de donnée à un débit fixe, exemple 10 50 ou 100 Khz (comme dans l'audio), et on approvisionne le port par buffer (de 10 , 30, 50 ou meme 100ms). Ainsi controle t'on le flux complet, c'est ce qui a de plus précis.
VB
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in
message news:447f1d6d$0$20159$ba4acef3@news.orange.fr...
Vincent Burel :
>
> qu'est ce que vous cherchez à faire en fait ?
Sortir des impulsions sur les bits du port parallèle, jusqu'à 5 ou 10
KHz grand maxi. Assez classique, semble-t-il. Ca me dérange pas que la
fréquence ne soit pas trop précise, mais par contre, l'éternel problème
est la préemption du scheduler. S'il me fait un trop gros trou au milieu
d'une trame, je serai embêté.
Je genre de chose se fait en faisant du streaming.
On sort une quantité de donnée à un débit fixe, exemple 10 50 ou 100 Khz
(comme dans l'audio),
et on approvisionne le port par buffer (de 10 , 30, 50 ou meme 100ms).
Ainsi controle t'on le flux complet, c'est ce qui a de plus précis.
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in message news:447f1d6d$0$20159$
Vincent Burel : > > qu'est ce que vous cherchez à faire en fait ?
Sortir des impulsions sur les bits du port parallèle, jusqu'à 5 ou 10 KHz grand maxi. Assez classique, semble-t-il. Ca me dérange pas que la fréquence ne soit pas trop précise, mais par contre, l'éternel problème est la préemption du scheduler. S'il me fait un trop gros trou au milieu d'une trame, je serai embêté.
Je genre de chose se fait en faisant du streaming. On sort une quantité de donnée à un débit fixe, exemple 10 50 ou 100 Khz (comme dans l'audio), et on approvisionne le port par buffer (de 10 , 30, 50 ou meme 100ms). Ainsi controle t'on le flux complet, c'est ce qui a de plus précis.
VB
Bertrand Lenoir-Welter
Vincent Burel :
Je genre de chose se fait en faisant du streaming. On sort une quantité de donnée à un débit fixe, exemple 10 50 ou 100 Khz (comme dans l'audio), et on approvisionne le port par buffer (de 10 , 30, 50 ou meme 100ms). Ainsi controle t'on le flux complet, c'est ce qui a de plus précis.
Je suis pas sûr d'avoir compris. Empiler les trames dans un buffer plutôt que les sortir directement sur le port, ça pose pas de problème. Mais le vrai souci, c'est comment vider ensuite le buffer vers le port à une fréquence donnée sans se faire préempter par le scheduler ?
Mon problème, c'est pas la fréquence, c'est d'éviter d'avoir des trous dans la trame quand le scheduler préempte du temps CPU pendant quelques millisecondes. J'ai alors une rupture de la continuité de la trame.
Si le truc c'est de mettre une horloge externe ou recomposer la trame sur un chip externe, négatif. Le but est de connecter le port parallèle directement à une carte standard qui n'est pas modifiée. Pas d'intermédiaire.
Ou alors y'a un truc qui m'a échappé ? Désolé, je connais rien au streaming.
Vincent Burel :
Je genre de chose se fait en faisant du streaming.
On sort une quantité de donnée à un débit fixe, exemple 10 50 ou 100 Khz
(comme dans l'audio),
et on approvisionne le port par buffer (de 10 , 30, 50 ou meme 100ms).
Ainsi controle t'on le flux complet, c'est ce qui a de plus précis.
Je suis pas sûr d'avoir compris. Empiler les trames dans un buffer
plutôt que les sortir directement sur le port, ça pose pas de problème.
Mais le vrai souci, c'est comment vider ensuite le buffer vers le port à
une fréquence donnée sans se faire préempter par le scheduler ?
Mon problème, c'est pas la fréquence, c'est d'éviter d'avoir des trous
dans la trame quand le scheduler préempte du temps CPU pendant quelques
millisecondes. J'ai alors une rupture de la continuité de la trame.
Si le truc c'est de mettre une horloge externe ou recomposer la trame
sur un chip externe, négatif. Le but est de connecter le port parallèle
directement à une carte standard qui n'est pas modifiée. Pas
d'intermédiaire.
Ou alors y'a un truc qui m'a échappé ? Désolé, je connais rien au streaming.
Je genre de chose se fait en faisant du streaming. On sort une quantité de donnée à un débit fixe, exemple 10 50 ou 100 Khz (comme dans l'audio), et on approvisionne le port par buffer (de 10 , 30, 50 ou meme 100ms). Ainsi controle t'on le flux complet, c'est ce qui a de plus précis.
Je suis pas sûr d'avoir compris. Empiler les trames dans un buffer plutôt que les sortir directement sur le port, ça pose pas de problème. Mais le vrai souci, c'est comment vider ensuite le buffer vers le port à une fréquence donnée sans se faire préempter par le scheduler ?
Mon problème, c'est pas la fréquence, c'est d'éviter d'avoir des trous dans la trame quand le scheduler préempte du temps CPU pendant quelques millisecondes. J'ai alors une rupture de la continuité de la trame.
Si le truc c'est de mettre une horloge externe ou recomposer la trame sur un chip externe, négatif. Le but est de connecter le port parallèle directement à une carte standard qui n'est pas modifiée. Pas d'intermédiaire.
Ou alors y'a un truc qui m'a échappé ? Désolé, je connais rien au streaming.
