Timer < 1 ms

Arnold McDonald $AMcD$

01/06/2006 à 22:20

Bertrand Lenoir-Welter wrote:

Négatif. Si c'est pour ajouter un PIC externe, autant acheter une
carte de contrôle existante.

Certes.

Pour le ring0, sous XP heu, ça risque d'être chaud.

J'y connais rien. Pourquoi chaud ?

Ben le ring0 c'est pour passer en mode dit privilégié, genre tu a accès à
n'importe quelle instruction du mode protégé du processeur. Avec Win9x,
c'était assez amusant et plutôt facile (cherche AMcD + ring0 sur des forums
de virus, tu devrais trouver des trucs). Enfin, facile... fallait magouiller
une entrée dans l'IDT, mais bon, il y a plus compliqué. Bref, on utilisait
un hack quoi. Le problème des hack, c'est qu'ils sont susceptibles de
changer à chaque patch, SP, etc.

Sous XP, c'est sacrément mieux protégé. Le plus rapide est d'écrire un
driver. Il existe aussi des hack mais bon, c'est pas du simple. De mémoire,
il y a une magouille avec les callgate, ou avec les SEH. Si vraiment ça
t'intéresse je pourrai chercher un peu plus dans mes docs et mon cerveau,
mais bon, je te conseille plutôt un driver (voir le Oney déjà cité).

Sinon, je pense que sur Winternals et cie tu dois avoir des trucs.

--
Arnold McDonald (AMcD) - Help #41/2006

http://arnold.mcdonald.free.fr/

Vincent Burel

01/06/2006 à 22:20

"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in
message news:447f4994$0$29225$

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.

non, le principe du streaming , (si c'est possible avec le port parallèle)
c'est que c'est le port qui s'occupe de faire sortir les données à débit
constant. Le client (l'utilisateur : vous) n'a qu'à fournir des buffer d'une
taille fixe (appelé latence) qui vont s'empiler dans la stack du port.

L'intéret est justement d'éviter d'avoir des coupures sur le flux,
puisqu'avec cette méthode il s'uffit d'envoyer quelque buffer par seconde
pour gérer des débit beaucoup plus gros. En audio, on peut par exemple
envoyer 10 buffer par seconde pour faire sortir 192 000 échantillons dans le
même laps de temps. Evidemment il ne faut pas perdre de temps dans l'envoi
des buffer, mais 10 buffer par seconde ca laisse 100 ms par buffer, et comme
on s'arrange pour avoir au moins un buffer d'avance (soit 200ms), ca fait un
flux très difficile à corrompre (même sous windows).

VB

"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in
message news:447f4994$0$29225$ba4acef3@news.orange.fr...

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.

non, le principe du streaming , (si c'est possible avec le port parallèle)
c'est que c'est le port qui s'occupe de faire sortir les données à débit
constant. Le client (l'utilisateur : vous) n'a qu'à fournir des buffer d'une
taille fixe (appelé latence) qui vont s'empiler dans la stack du port.

L'intéret est justement d'éviter d'avoir des coupures sur le flux,
puisqu'avec cette méthode il s'uffit d'envoyer quelque buffer par seconde
pour gérer des débit beaucoup plus gros. En audio, on peut par exemple
envoyer 10 buffer par seconde pour faire sortir 192 000 échantillons dans le
même laps de temps. Evidemment il ne faut pas perdre de temps dans l'envoi
des buffer, mais 10 buffer par seconde ca laisse 100 ms par buffer, et comme
on s'arrange pour avoir au moins un buffer d'avance (soit 200ms), ca fait un
flux très difficile à corrompre (même sous windows).

VB

Vous avez filtré cet utilisateur ! Consultez son message

"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in
message news:447f4994$0$29225$

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.

non, le principe du streaming , (si c'est possible avec le port parallèle)
c'est que c'est le port qui s'occupe de faire sortir les données à débit
constant. Le client (l'utilisateur : vous) n'a qu'à fournir des buffer d'une
taille fixe (appelé latence) qui vont s'empiler dans la stack du port.

L'intéret est justement d'éviter d'avoir des coupures sur le flux,
puisqu'avec cette méthode il s'uffit d'envoyer quelque buffer par seconde
pour gérer des débit beaucoup plus gros. En audio, on peut par exemple
envoyer 10 buffer par seconde pour faire sortir 192 000 échantillons dans le
même laps de temps. Evidemment il ne faut pas perdre de temps dans l'envoi
des buffer, mais 10 buffer par seconde ca laisse 100 ms par buffer, et comme
on s'arrange pour avoir au moins un buffer d'avance (soit 200ms), ca fait un
flux très difficile à corrompre (même sous windows).

VB

Arnold McDonald $AMcD$

01/06/2006 à 22:38

Vincent Burel wrote:

non, le principe du streaming , (si c'est possible avec le port
parallèle) c'est que c'est le port qui s'occupe de faire sortir les
données à débit constant. Le client (l'utilisateur : vous) n'a qu'à
fournir des buffer d'une taille fixe (appelé latence) qui vont
s'empiler dans la stack du port.

L'intéret est justement d'éviter d'avoir des coupures sur le flux,
puisqu'avec cette méthode il s'uffit d'envoyer quelque buffer par
seconde pour gérer des débit beaucoup plus gros. En audio, on peut
par exemple envoyer 10 buffer par seconde pour faire sortir 192 000
échantillons dans le même laps de temps. Evidemment il ne faut pas
perdre de temps dans l'envoi des buffer, mais 10 buffer par seconde
ca laisse 100 ms par buffer, et comme on s'arrange pour avoir au
moins un buffer d'avance (soit 200ms), ca fait un flux très difficile
à corrompre (même sous windows).

Ouaip, c'est une bonne technique ça. À une époque, je sais plus pour quel
problème à résoudre, j'avais fait comme ça. Comme je ne pouvais pas compter
sur la fiabilité du dispatcher, j'envoyais des flux de données au buffer
bien plus gros que ce requis par le recepteur. Comme ça, si le recepteur lit
le buffer à des moments ou le dispatcher n'est pas disponible pour lui
envoyer des données, il a quelque chose à lire.

Après quelques tests, on trouve la valeur "supplémentaire" à envoyer pour
passer outre les sautes d'humeur des timers ou du dispatcher. En général, 2
ou 3 fois le total normal. Par exemple, si le buffer doit être alimenté
toutes les secondes, on lui envoie pour 2 ou 3 secondes de données.

Le problème est ensuite celui du buffer du recepteur qui peut-être n'accepte
pas plus qu'un total d'octets correspondant à un traitement. Ensuite, il
faut bien sûr que le total envoyé ne mette pas plus de temps à être reçu
qu'un cycle de timer du dispatcher. Il faut également que le buffer du
recepteur soit capable de gérer le surplus, c a d qu'il faut faire en sorte
qu'il soit impossible qu'un envoi du dispatcher ne puisse pas être stocké
dans le buffer, sinon, faut se cogner des files d'attentes et tout le
toutim. Il faut également que le taux d'erreur de transmission soit
quasi-nul, sinon, pour calculer les données à renvoyer, on va perdre les
avantage de la bufferisation par streaming.

Bref, faut faire pas mal de test pour trouver les bonnes valeurs. Cela
étant, ce principe est présent un peu partout. Il suffit de regarder les
mémoires "antichoc" des baladeurs mp3 et autres, c'est la même chose.

--
Arnold McDonald (AMcD) - Help #42/2006

http://arnold.mcdonald.free.fr/

Vincent Burel wrote:

non, le principe du streaming , (si c'est possible avec le port
parallèle) c'est que c'est le port qui s'occupe de faire sortir les
données à débit constant. Le client (l'utilisateur : vous) n'a qu'à
fournir des buffer d'une taille fixe (appelé latence) qui vont
s'empiler dans la stack du port.

L'intéret est justement d'éviter d'avoir des coupures sur le flux,
puisqu'avec cette méthode il s'uffit d'envoyer quelque buffer par
seconde pour gérer des débit beaucoup plus gros. En audio, on peut
par exemple envoyer 10 buffer par seconde pour faire sortir 192 000
échantillons dans le même laps de temps. Evidemment il ne faut pas
perdre de temps dans l'envoi des buffer, mais 10 buffer par seconde
ca laisse 100 ms par buffer, et comme on s'arrange pour avoir au
moins un buffer d'avance (soit 200ms), ca fait un flux très difficile
à corrompre (même sous windows).

Ouaip, c'est une bonne technique ça. À une époque, je sais plus pour quel
problème à résoudre, j'avais fait comme ça. Comme je ne pouvais pas compter
sur la fiabilité du dispatcher, j'envoyais des flux de données au buffer
bien plus gros que ce requis par le recepteur. Comme ça, si le recepteur lit
le buffer à des moments ou le dispatcher n'est pas disponible pour lui
envoyer des données, il a quelque chose à lire.

Après quelques tests, on trouve la valeur "supplémentaire" à envoyer pour
passer outre les sautes d'humeur des timers ou du dispatcher. En général, 2
ou 3 fois le total normal. Par exemple, si le buffer doit être alimenté
toutes les secondes, on lui envoie pour 2 ou 3 secondes de données.

Le problème est ensuite celui du buffer du recepteur qui peut-être n'accepte
pas plus qu'un total d'octets correspondant à un traitement. Ensuite, il
faut bien sûr que le total envoyé ne mette pas plus de temps à être reçu
qu'un cycle de timer du dispatcher. Il faut également que le buffer du
recepteur soit capable de gérer le surplus, c a d qu'il faut faire en sorte
qu'il soit impossible qu'un envoi du dispatcher ne puisse pas être stocké
dans le buffer, sinon, faut se cogner des files d'attentes et tout le
toutim. Il faut également que le taux d'erreur de transmission soit
quasi-nul, sinon, pour calculer les données à renvoyer, on va perdre les
avantage de la bufferisation par streaming.

Bref, faut faire pas mal de test pour trouver les bonnes valeurs. Cela
étant, ce principe est présent un peu partout. Il suffit de regarder les
mémoires "antichoc" des baladeurs mp3 et autres, c'est la même chose.

--
Arnold McDonald (AMcD) - Help #42/2006

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

Vincent Burel wrote:

non, le principe du streaming , (si c'est possible avec le port
parallèle) c'est que c'est le port qui s'occupe de faire sortir les
données à débit constant. Le client (l'utilisateur : vous) n'a qu'à
fournir des buffer d'une taille fixe (appelé latence) qui vont
s'empiler dans la stack du port.

L'intéret est justement d'éviter d'avoir des coupures sur le flux,
puisqu'avec cette méthode il s'uffit d'envoyer quelque buffer par
seconde pour gérer des débit beaucoup plus gros. En audio, on peut
par exemple envoyer 10 buffer par seconde pour faire sortir 192 000
échantillons dans le même laps de temps. Evidemment il ne faut pas
perdre de temps dans l'envoi des buffer, mais 10 buffer par seconde
ca laisse 100 ms par buffer, et comme on s'arrange pour avoir au
moins un buffer d'avance (soit 200ms), ca fait un flux très difficile
à corrompre (même sous windows).

Ouaip, c'est une bonne technique ça. À une époque, je sais plus pour quel
problème à résoudre, j'avais fait comme ça. Comme je ne pouvais pas compter
sur la fiabilité du dispatcher, j'envoyais des flux de données au buffer
bien plus gros que ce requis par le recepteur. Comme ça, si le recepteur lit
le buffer à des moments ou le dispatcher n'est pas disponible pour lui
envoyer des données, il a quelque chose à lire.

Après quelques tests, on trouve la valeur "supplémentaire" à envoyer pour
passer outre les sautes d'humeur des timers ou du dispatcher. En général, 2
ou 3 fois le total normal. Par exemple, si le buffer doit être alimenté
toutes les secondes, on lui envoie pour 2 ou 3 secondes de données.

Le problème est ensuite celui du buffer du recepteur qui peut-être n'accepte
pas plus qu'un total d'octets correspondant à un traitement. Ensuite, il
faut bien sûr que le total envoyé ne mette pas plus de temps à être reçu
qu'un cycle de timer du dispatcher. Il faut également que le buffer du
recepteur soit capable de gérer le surplus, c a d qu'il faut faire en sorte
qu'il soit impossible qu'un envoi du dispatcher ne puisse pas être stocké
dans le buffer, sinon, faut se cogner des files d'attentes et tout le
toutim. Il faut également que le taux d'erreur de transmission soit
quasi-nul, sinon, pour calculer les données à renvoyer, on va perdre les
avantage de la bufferisation par streaming.

Bref, faut faire pas mal de test pour trouver les bonnes valeurs. Cela
étant, ce principe est présent un peu partout. Il suffit de regarder les
mémoires "antichoc" des baladeurs mp3 et autres, c'est la même chose.

--
Arnold McDonald (AMcD) - Help #42/2006

http://arnold.mcdonald.free.fr/

Arnaud Debaene

02/06/2006 à 08:24

"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> a écrit dans
le message de news: 447f435b$0$20148$

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.

D'accord, mais tu dois réaliser qu'aucun OS généraliste (Windows, Linux,
etc....) n'est concu pour ce genre de choses, et que tu n'obitendras au
mieux que du bricolage. Entre autres choses, je m'interdirais formellement
de faire ce genre de pilotage directement par un PC si le moteur a un
équipement de sécurité (ou susceptible d'êter dangereux) derrière.

Sinon, AMcD t'a donné la bonne piste : un driver WDM, mais si tu ne connais
pas du tout l'environnement Windows, la courbe d'apprentissage pour réaliser
ce genre de projets risque d'être "rude".... Windows n'est tout simplement
pas conçu pour faire ce genre de choses...

Arnaud
MVP - VC

Bertrand Lenoir-Welter

02/06/2006 à 08:52

Arnaud Debaene :

D'accord, mais tu dois réaliser qu'aucun OS généraliste (Windows, Linux,
etc....) n'est concu pour ce genre de choses, et que tu n'obitendras au
mieux que du bricolage. Entre autres choses, je m'interdirais formellement
de faire ce genre de pilotage directement par un PC si le moteur a un
équipement de sécurité (ou susceptible d'êter dangereux) derrière.

Bigre, non ! Si c'était pour une appli vraiment sérieuse avec éléments
de sécurité, j'utiliserais une carte de contrôle externe sur port série
ou USB, propre sur elle et dont le fabricant endosserait la responsabilité.

Sinon, AMcD t'a donné la bonne piste : un driver WDM, mais si tu ne connais
pas du tout l'environnement Windows, la courbe d'apprentissage pour réaliser
ce genre de projets risque d'être "rude".... Windows n'est tout simplement
pas conçu pour faire ce genre de choses...

En fait, c'est pas moi qui suis chargé de réaliser le truc, mais mon
collègue qui, lui, est un spécialiste du temps-réel... sous Linux
(apparemment, les limites dues au scheduling sont assez semblables) et
assez rodé aux bricolages dans les basses couches d'un OS. Moi, je me
contente de coder la partie en amont, et c'est déjà bien assez.

Merci, en tout cas.

Thierry

02/06/2006 à 09:12

"Arnaud Debaene" écrivait
news:447fd9b1$0$30306$:

Sinon, AMcD t'a donné la bonne piste : un driver WDM, mais si tu ne
connais pas du tout l'environnement Windows, la courbe d'apprentissage
pour réaliser ce genre de projets risque d'être "rude".... Windows
n'est tout simplement pas conçu pour faire ce genre de choses...

Peut-etre en partant d'un sample de driver modem et l'adapter au besoins.
Moins rude que de partir "from scratch".

Vincent Burel

02/06/2006 à 09:41

"Arnold McDonald (AMcD)" wrote in message
news:447f5027$0$6184$

Bref, faut faire pas mal de test pour trouver les bonnes valeurs. Cela
étant, ce principe est présent un peu partout.

C'est la base de tous les flux. Et la plupart des carte ou controleur de
transmission de données synchrones ou asynchrones fonctionnent selon une
stratégie de flux (donc avec une possibilité de savoir quand le port en
question aura besoin de donnée pour assurer un streaming continu).
ceci dit, je fais aussi du streaming de latence courte, actuellement sous
XP, 1 à 5ms sur des débits atteignant 20Mb/s...
même un celeron fait ca les doigts dans le nez. (mais y'a les drivers
spécifiques pour ce faire).

VB

Bertrand Lenoir-Welter

02/06/2006 à 15:43

Vincent Burel :

C'est la base de tous les flux. Et la plupart des carte ou controleur de
transmission de données synchrones ou asynchrones fonctionnent selon une
stratégie de flux (donc avec une possibilité de savoir quand le port en
question aura besoin de donnée pour assurer un streaming continu).

Oui mais je pense qu'on est dans un cas de figure différent. Dans mon
appli, il ne s'agit pas de bufferiser et transmettre des octets à un
périphérique vorace, mais positionner les bits du port parallèle selon
une trame dont la fréquence est décidée par l'appli, pas par le
périphérique. Le streaming est la fourniture d'octets sans rupture de
buffer. Dans mon cas, ce n'est pas le buffer le problème : il faut
fournir des octets selon une cadence précise. Mon périphérique ne
demande pas d'octet suivant ; il prend les bits du port en l'état.

A moins qu'il y ait possibilité d'avoir un timer spécifique indépendant
du scheduler sur le port parallèle, je ne vois pas de solution de ce
côté. Et si c'est pour mettre une horloge sur le bit Busy, tant qu'à
bricoler du hard, autant mettre un peu plus malin qu'un simple timer.

Merci quand même pour toutes ces suggestions.

Vincent Burel

02/06/2006 à 16:59

"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in
message news:44804073$0$20184$

Vincent Burel :
>
> C'est la base de tous les flux. Et la plupart des carte ou controleur de
> transmission de données synchrones ou asynchrones fonctionnent selon une
> stratégie de flux (donc avec une possibilité de savoir quand le port en
> question aura besoin de donnée pour assurer un streaming continu).

Oui mais je pense qu'on est dans un cas de figure différent. Dans mon
appli, il ne s'agit pas de bufferiser et transmettre des octets à un
périphérique vorace, mais positionner les bits du port parallèle selon
une trame dont la fréquence est décidée par l'appli, pas par le
périphérique.

Vous utilisez la fréquence MAX du port (qui est fixe ou la même que eclle du
périphe connecté) et vous positionnez vos event dans vos buffer,
temporellement où vous voulez... Le streaming est à byterate constant , mais
ce qui a dans le stream, c'est vous qui le définissez...

Le streaming est la fourniture d'octets sans rupture de
buffer. Dans mon cas, ce n'est pas le buffer le problème : il faut
fournir des octets selon une cadence précise. Mon périphérique ne
demande pas d'octet suivant ; il prend les bits du port en l'état.

ben oui, je ne vois pas le problème...
c'est vous qui voyez.
VB

Bertrand Lenoir-Welter

02/06/2006 à 19:57

Vincent Burel :

Vous utilisez la fréquence MAX du port (qui est fixe

Ok, je pensais pas qu'il y avait une fréquence max définie côté PC. Je
suppose que c'est le signal STROBE qui est associé à un timer local.
C'est effectivement une idée intéressante. Si en plus ce timer est
paramétrable, c'est Byzance.

Merci pour ce tuyau. Je sais pas si ça aboutira à quelque chose de
concret, mais ça vaut le coup de creuser de ce côté.

ou la même que eclle du périphe connecté)

Oui mais lui n'a pas de fréquence max. C'est un simple slave et il ne
donne pas de synchro. Le bit BUSY n'est pas significatif. Quand le
pattern des bits change d'état, la carte de puissance fait avancer les
moteurs d'un pas sur un front montant (ou descendant, c'est selon).

Timer < 1 ms

10 réponses

Veuillez sélectionner un problème