on a 2 valeurs à aller pecher sur des ports differents.
le probleme est que entre ces deux "acquisitions", le thread peut se faire
prehempter.
c'est normal, l'ordonanceur fait son boulot.
la question est, comment faire en sorte de ne pas être prehempté. paske
sinon, ça cree un décalage énorme dans le temps (100ms, ça n'est pas rien)
et du coup, le couple de valeurs n'a pas de sens.
bon, c'est le même probleme que pour le port série, donc ça doit se résoudre
d'une façon trés voisine. mais comment faire en sorte d'avoir les bonnes
propriétés : cad pas de perte de donnée, pas d'attente active, pas de
prehemption au moment ou je pique mes deux valeurs pour avoir la
"simultaneité". en clair, comment écrire le Read.
j'ai un début d'idée, mais je voudrais bien un exposé technique des habitués
du forum avant de faire pencher la balance. ( Arnaud, Quentin ou Amcd pour
ne citer qu'eux :) )
-- "MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
Cyrille \cns\ Szymanski
> Bonjour,
Critical sections ?
Les critical sections sont par définition des mutex qui ne peuvent être partagés qu'au sein du même process.
Un mutex (mutually exclusive) sert à éviter que deux opérations aient lieu en même temps, l'exemple classique étant la modification d'une zone mémoire.
Les critical sections sont par définition des mutex qui ne peuvent être
partagés qu'au sein du même process.
Un mutex (mutually exclusive) sert à éviter que deux opérations aient lieu
en même temps, l'exemple classique étant la modification d'une zone
mémoire.
Les critical sections sont par définition des mutex qui ne peuvent être partagés qu'au sein du même process.
Un mutex (mutually exclusive) sert à éviter que deux opérations aient lieu en même temps, l'exemple classique étant la modification d'une zone mémoire.
on a 2 valeurs à aller pecher sur des ports differents. le probleme est que entre ces deux "acquisitions", le thread peut se faire prehempter. c'est normal, l'ordonanceur fait son boulot.
la question est, comment faire en sorte de ne pas être prehempté. paske sinon, ça cree un décalage énorme dans le temps (100ms, ça n'est pas rien) et du coup, le couple de valeurs n'a pas de sens.
Je ne comprends pas trop. tu veux lire exactement au même moment (ou en tout cas dnas un délai maitrisé) sur 2 ports différents, mais quels ports? Des ports série, des ports TCP (je vois pas trop le sens du schmilblick, mais on sait jamais), autre chose?
Sans en savoir plus, il me semble que la seul solution sur un Windows "normal" (sans noyau modifié temps réel) soit de faire les acquisitions dans un driver, durant une interruption. C'est le seul moment où tu es sûr de ne pas être interrompu, soit par le scheduler, soit par une autre interuption (sauf si elle a un IRQL plus important bien sûr), mais sans en savoir d'avantage, impossible de t'aider.
Encore une fois, Windows n'est pas concu pour ce genre de choses, et il est souvent plus simple et plus fiable de s'appuyer sur un petit bout de hardware dédié quand on a des contraintes temps réel fortes.
Arnaud
Ambassadeur Kosh wrote:
on a 2 valeurs à aller pecher sur des ports differents.
le probleme est que entre ces deux "acquisitions", le thread peut se
faire prehempter.
c'est normal, l'ordonanceur fait son boulot.
la question est, comment faire en sorte de ne pas être prehempté.
paske sinon, ça cree un décalage énorme dans le temps (100ms, ça
n'est pas rien) et du coup, le couple de valeurs n'a pas de sens.
Je ne comprends pas trop. tu veux lire exactement au même moment (ou en tout
cas dnas un délai maitrisé) sur 2 ports différents, mais quels ports? Des
ports série, des ports TCP (je vois pas trop le sens du schmilblick, mais on
sait jamais), autre chose?
Sans en savoir plus, il me semble que la seul solution sur un Windows
"normal" (sans noyau modifié temps réel) soit de faire les acquisitions dans
un driver, durant une interruption. C'est le seul moment où tu es sûr de ne
pas être interrompu, soit par le scheduler, soit par une autre interuption
(sauf si elle a un IRQL plus important bien sûr), mais sans en savoir
d'avantage, impossible de t'aider.
Encore une fois, Windows n'est pas concu pour ce genre de choses, et il est
souvent plus simple et plus fiable de s'appuyer sur un petit bout de
hardware dédié quand on a des contraintes temps réel fortes.
on a 2 valeurs à aller pecher sur des ports differents. le probleme est que entre ces deux "acquisitions", le thread peut se faire prehempter. c'est normal, l'ordonanceur fait son boulot.
la question est, comment faire en sorte de ne pas être prehempté. paske sinon, ça cree un décalage énorme dans le temps (100ms, ça n'est pas rien) et du coup, le couple de valeurs n'a pas de sens.
Je ne comprends pas trop. tu veux lire exactement au même moment (ou en tout cas dnas un délai maitrisé) sur 2 ports différents, mais quels ports? Des ports série, des ports TCP (je vois pas trop le sens du schmilblick, mais on sait jamais), autre chose?
Sans en savoir plus, il me semble que la seul solution sur un Windows "normal" (sans noyau modifié temps réel) soit de faire les acquisitions dans un driver, durant une interruption. C'est le seul moment où tu es sûr de ne pas être interrompu, soit par le scheduler, soit par une autre interuption (sauf si elle a un IRQL plus important bien sûr), mais sans en savoir d'avantage, impossible de t'aider.
Encore une fois, Windows n'est pas concu pour ce genre de choses, et il est souvent plus simple et plus fiable de s'appuyer sur un petit bout de hardware dédié quand on a des contraintes temps réel fortes.
Arnaud
AMcD
Salut.
Ambassadeur Kosh wrote:
Heu, j'ai pas bien compris ton problème. Cela étant, je pense que tu devrais descendre au niveau "genre" celui d'un driver pour ton truc ;o)...
PS : c'est AMcD ! Grrr
-- AMcD
http://arnold.mcdonald.free.fr/
Salut.
Ambassadeur Kosh wrote:
Heu, j'ai pas bien compris ton problème. Cela étant, je pense que tu devrais
descendre au niveau "genre" celui d'un driver pour ton truc ;o)...
Heu, j'ai pas bien compris ton problème. Cela étant, je pense que tu devrais descendre au niveau "genre" celui d'un driver pour ton truc ;o)...
PS : c'est AMcD ! Grrr
-- AMcD
http://arnold.mcdonald.free.fr/
Vincent Burel
"AMcD" wrote in message news:3f8c58cc$0$20173$
Salut.
Ambassadeur Kosh wrote:
Heu, j'ai pas bien compris ton problème. Cela étant, je pense que tu
devrais
descendre au niveau "genre" celui d'un driver pour ton truc ;o)...
je ne sais pas, mais 100ms de décalage entre deux acquisition de données sur deux ports différents, je ne vois pas comment c'est possible à moins de travailler sur du série à 100 baud ! :-)
A+ Vincent Burel
"AMcD" <arnold.mcdonald@free.fr> wrote in message
news:3f8c58cc$0$20173$626a54ce@news.free.fr...
Salut.
Ambassadeur Kosh wrote:
Heu, j'ai pas bien compris ton problème. Cela étant, je pense que tu
devrais
descendre au niveau "genre" celui d'un driver pour ton truc ;o)...
je ne sais pas, mais 100ms de décalage entre deux acquisition de données sur
deux ports différents, je ne vois pas comment c'est possible à moins de
travailler sur du série à 100 baud ! :-)
Heu, j'ai pas bien compris ton problème. Cela étant, je pense que tu
devrais
descendre au niveau "genre" celui d'un driver pour ton truc ;o)...
je ne sais pas, mais 100ms de décalage entre deux acquisition de données sur deux ports différents, je ne vois pas comment c'est possible à moins de travailler sur du série à 100 baud ! :-)
A+ Vincent Burel
Ambassadeur Kosh
> Je ne comprends pas trop. tu veux lire exactement au même moment (ou en
tout
cas dnas un délai maitrisé) sur 2 ports différents, mais quels ports? Des ports série, des ports TCP (je vois pas trop le sens du schmilblick, mais
on
sait jamais), autre chose?
bon, je vais essayer d'être un peu moins obscur.
on a un capteur de présence sur le port serie, et un codeur sur une carte qui augmente un compteur de 1 à chaque dz parcouru par un tapi roulant. le but est de mesurer la longueur d'objets qui passent sur le tapi en calculant z1 - z0. z1 étant la longueur codeur (lue sur la carte au moment t1) de début d'absence , et z0 étant la longueur codeur de début de présence (lue sur la carte au moment t0).
le bout de code qui mesure un objet ressemble(rait) à ceci :
(1) read(port_serie,bloquant) ; // hop, ca débloque le thread (2) z0 = read_carte_d'acquisition( ) ; (3) read(port_serie,bloquant) ; // hop, ca débloque le thread (4) z1 = read_carte_d'acquisition( ) ;
entre (1) et (2), le systeme peut décider de passer la main au voisin : résultat ça change considerablement la longueur de mon objet. entre le moment ou la donnée arrive physiquement sur le port et ou le read est debloqué (c'est à dire entre t0 et (1)) , il peut s'écouler un temps trés long, et plusieurs threads ont pu prendre la main (normal, y'a pas urgence, le systeme bufferise le COM). résultat identique au précedent.
pareil pour 3 et 4 bien entendu.
Sans en savoir plus, il me semble que la seule solution sur un Windows "normal" (sans noyau modifié temps réel) soit de faire les acquisitions
dans
un driver, durant une interruption. C'est le seul moment où tu es sûr de
ne
pas être interrompu, soit par le scheduler, soit par une autre interuption (sauf si elle a un IRQL plus important bien sûr), mais sans en savoir d'avantage, impossible de t'aider.
effectivement. bon, je n'ai aucune conaissance pratique du DDK et des outils qui vont avec. quelques references documentaires seraient les bienvenues (genre un tutorial pour effecuer une action sur chaque tick d'horloge ou un truc du genre je poulpe certains evenements de la souris)
sinon, pratiquement, sur un noyau RT, comment je vais pouvoir resoudre ce probleme ? de quel artillerie je dispose ? qu'est-ce qui change ?
Encore une fois, Windows n'est pas concu pour ce genre de choses, et il
est
souvent plus simple et plus fiable de s'appuyer sur un petit bout de hardware dédié quand on a des contraintes temps réel fortes.
on a fait ça chez un client. ça nous a couté 5000 ballles. ça va quand c'est sur un gros projet, mais quand il faut tirer les prix...
merci à tous du coup de pouce.
> Je ne comprends pas trop. tu veux lire exactement au même moment (ou en
tout
cas dnas un délai maitrisé) sur 2 ports différents, mais quels ports? Des
ports série, des ports TCP (je vois pas trop le sens du schmilblick, mais
on
sait jamais), autre chose?
bon, je vais essayer d'être un peu moins obscur.
on a un capteur de présence sur le port serie, et un codeur sur une carte
qui augmente un compteur de 1 à chaque dz parcouru par un tapi roulant. le
but est de mesurer la longueur d'objets qui passent sur le tapi en calculant
z1 - z0. z1 étant la longueur codeur (lue sur la carte au moment t1) de
début d'absence , et z0 étant la longueur codeur de début de présence (lue
sur la carte au moment t0).
le bout de code qui mesure un objet ressemble(rait) à ceci :
(1) read(port_serie,bloquant) ; // hop, ca débloque le thread
(2) z0 = read_carte_d'acquisition( ) ;
(3) read(port_serie,bloquant) ; // hop, ca débloque le thread
(4) z1 = read_carte_d'acquisition( ) ;
entre (1) et (2), le systeme peut décider de passer la main au voisin :
résultat ça change considerablement la longueur de mon objet.
entre le moment ou la donnée arrive physiquement sur le port et ou le read
est debloqué (c'est à dire entre t0 et (1)) , il peut s'écouler un temps
trés long, et plusieurs threads ont pu prendre la main (normal, y'a pas
urgence, le systeme bufferise le COM). résultat identique au précedent.
pareil pour 3 et 4 bien entendu.
Sans en savoir plus, il me semble que la seule solution sur un Windows
"normal" (sans noyau modifié temps réel) soit de faire les acquisitions
dans
un driver, durant une interruption. C'est le seul moment où tu es sûr de
ne
pas être interrompu, soit par le scheduler, soit par une autre interuption
(sauf si elle a un IRQL plus important bien sûr), mais sans en savoir
d'avantage, impossible de t'aider.
effectivement.
bon, je n'ai aucune conaissance pratique du DDK et des outils qui vont avec.
quelques references documentaires seraient les bienvenues (genre un tutorial
pour effecuer une action sur chaque tick d'horloge ou un truc du genre je
poulpe certains evenements de la souris)
sinon, pratiquement, sur un noyau RT, comment je vais pouvoir resoudre ce
probleme ? de quel artillerie je dispose ? qu'est-ce qui change ?
Encore une fois, Windows n'est pas concu pour ce genre de choses, et il
est
souvent plus simple et plus fiable de s'appuyer sur un petit bout de
hardware dédié quand on a des contraintes temps réel fortes.
on a fait ça chez un client. ça nous a couté 5000 ballles. ça va quand c'est
sur un gros projet, mais quand il faut tirer les prix...
> Je ne comprends pas trop. tu veux lire exactement au même moment (ou en
tout
cas dnas un délai maitrisé) sur 2 ports différents, mais quels ports? Des ports série, des ports TCP (je vois pas trop le sens du schmilblick, mais
on
sait jamais), autre chose?
bon, je vais essayer d'être un peu moins obscur.
on a un capteur de présence sur le port serie, et un codeur sur une carte qui augmente un compteur de 1 à chaque dz parcouru par un tapi roulant. le but est de mesurer la longueur d'objets qui passent sur le tapi en calculant z1 - z0. z1 étant la longueur codeur (lue sur la carte au moment t1) de début d'absence , et z0 étant la longueur codeur de début de présence (lue sur la carte au moment t0).
le bout de code qui mesure un objet ressemble(rait) à ceci :
(1) read(port_serie,bloquant) ; // hop, ca débloque le thread (2) z0 = read_carte_d'acquisition( ) ; (3) read(port_serie,bloquant) ; // hop, ca débloque le thread (4) z1 = read_carte_d'acquisition( ) ;
entre (1) et (2), le systeme peut décider de passer la main au voisin : résultat ça change considerablement la longueur de mon objet. entre le moment ou la donnée arrive physiquement sur le port et ou le read est debloqué (c'est à dire entre t0 et (1)) , il peut s'écouler un temps trés long, et plusieurs threads ont pu prendre la main (normal, y'a pas urgence, le systeme bufferise le COM). résultat identique au précedent.
pareil pour 3 et 4 bien entendu.
Sans en savoir plus, il me semble que la seule solution sur un Windows "normal" (sans noyau modifié temps réel) soit de faire les acquisitions
dans
un driver, durant une interruption. C'est le seul moment où tu es sûr de
ne
pas être interrompu, soit par le scheduler, soit par une autre interuption (sauf si elle a un IRQL plus important bien sûr), mais sans en savoir d'avantage, impossible de t'aider.
effectivement. bon, je n'ai aucune conaissance pratique du DDK et des outils qui vont avec. quelques references documentaires seraient les bienvenues (genre un tutorial pour effecuer une action sur chaque tick d'horloge ou un truc du genre je poulpe certains evenements de la souris)
sinon, pratiquement, sur un noyau RT, comment je vais pouvoir resoudre ce probleme ? de quel artillerie je dispose ? qu'est-ce qui change ?
Encore une fois, Windows n'est pas concu pour ce genre de choses, et il
est
souvent plus simple et plus fiable de s'appuyer sur un petit bout de hardware dédié quand on a des contraintes temps réel fortes.
on a fait ça chez un client. ça nous a couté 5000 ballles. ça va quand c'est sur un gros projet, mais quand il faut tirer les prix...
merci à tous du coup de pouce.
Ambassadeur Kosh
> Ambassadeur Kosh wrote: Heu, j'ai pas bien compris ton problème.
j'ai tout repris suite au post d'Arnaud. c'est vrai qu'en relisant, c'est un peu confu comme explications.
Cela étant, je pense que tu devrais descendre au niveau "genre" celui d'un driver pour ton truc ;o)...
effectivement, ça en prend le chemin.
PS : c'est AMcD ! Grrr
oups. :) bon, je ferai gaffe
> Ambassadeur Kosh wrote:
Heu, j'ai pas bien compris ton problème.
j'ai tout repris suite au post d'Arnaud.
c'est vrai qu'en relisant, c'est un peu confu comme explications.
Cela étant, je pense que tu devrais
descendre au niveau "genre" celui d'un driver pour ton truc ;o)...
> Ambassadeur Kosh wrote: Heu, j'ai pas bien compris ton problème.
j'ai tout repris suite au post d'Arnaud. c'est vrai qu'en relisant, c'est un peu confu comme explications.
Cela étant, je pense que tu devrais descendre au niveau "genre" celui d'un driver pour ton truc ;o)...
effectivement, ça en prend le chemin.
PS : c'est AMcD ! Grrr
oups. :) bon, je ferai gaffe
Vincent Burel
"Ambassadeur Kosh" wrote in message news:bmj171$f0r$
(1) read(port_serie,bloquant) ; // hop, ca débloque le thread (2) z0 = read_carte_d'acquisition( ) ; (3) read(port_serie,bloquant) ; // hop, ca débloque le thread (4) z1 = read_carte_d'acquisition( ) ;
entre (1) et (2), le systeme peut décider de passer la main au voisin : résultat ça change considerablement la longueur de mon objet.
et en mettant ca dans un thread TIME_CRITICAL...
entre le moment ou la donnée arrive physiquement sur le port et ou le read est debloqué (c'est à dire entre t0 et (1)) , il peut s'écouler un temps trés long, et plusieurs threads ont pu prendre la main (normal, y'a pas urgence, le systeme bufferise le COM). résultat identique au précedent.
Le système bufferise le COM si on veut. En principe le FileRead rend la main des que le nombre d'octet demandé est arrivé , sauf timeout... sa vitesse de réaction est fonction aussi du baudrate, à combien etes vous configuré !?
Peut être que dans votre cas , vous devriez utiliser le port com en événementiel... je fais un peu de remoting par COM , j'ai jamais constaté des 100ms de délai sur acquisition, même avec des thread de basse priorité, donc je ne crois pas que votre délai soit du au multitache windows (à moins que vous soyez en train de copier 4 fichiers de 30 Go en permanence sur le réseau évidemment)
Vincent Burel
"Ambassadeur Kosh" <yanapa@nospamnocry.fr> wrote in message
news:bmj171$f0r$1@news-reader3.wanadoo.fr...
(1) read(port_serie,bloquant) ; // hop, ca débloque le thread
(2) z0 = read_carte_d'acquisition( ) ;
(3) read(port_serie,bloquant) ; // hop, ca débloque le thread
(4) z1 = read_carte_d'acquisition( ) ;
entre (1) et (2), le systeme peut décider de passer la main au voisin :
résultat ça change considerablement la longueur de mon objet.
et en mettant ca dans un thread TIME_CRITICAL...
entre le moment ou la donnée arrive physiquement sur le port et ou le read
est debloqué (c'est à dire entre t0 et (1)) , il peut s'écouler un temps
trés long, et plusieurs threads ont pu prendre la main (normal, y'a pas
urgence, le systeme bufferise le COM). résultat identique au précedent.
Le système bufferise le COM si on veut. En principe le FileRead rend la main
des que le nombre d'octet demandé est arrivé , sauf timeout... sa vitesse de
réaction est fonction aussi du baudrate, à combien etes vous configuré !?
Peut être que dans votre cas , vous devriez utiliser le port com en
événementiel... je fais un peu de remoting par COM , j'ai jamais constaté
des 100ms de délai sur acquisition, même avec des thread de basse priorité,
donc je ne crois pas que votre délai soit du au multitache windows (à moins
que vous soyez en train de copier 4 fichiers de 30 Go en permanence sur le
réseau évidemment)
"Ambassadeur Kosh" wrote in message news:bmj171$f0r$
(1) read(port_serie,bloquant) ; // hop, ca débloque le thread (2) z0 = read_carte_d'acquisition( ) ; (3) read(port_serie,bloquant) ; // hop, ca débloque le thread (4) z1 = read_carte_d'acquisition( ) ;
entre (1) et (2), le systeme peut décider de passer la main au voisin : résultat ça change considerablement la longueur de mon objet.
et en mettant ca dans un thread TIME_CRITICAL...
entre le moment ou la donnée arrive physiquement sur le port et ou le read est debloqué (c'est à dire entre t0 et (1)) , il peut s'écouler un temps trés long, et plusieurs threads ont pu prendre la main (normal, y'a pas urgence, le systeme bufferise le COM). résultat identique au précedent.
Le système bufferise le COM si on veut. En principe le FileRead rend la main des que le nombre d'octet demandé est arrivé , sauf timeout... sa vitesse de réaction est fonction aussi du baudrate, à combien etes vous configuré !?
Peut être que dans votre cas , vous devriez utiliser le port com en événementiel... je fais un peu de remoting par COM , j'ai jamais constaté des 100ms de délai sur acquisition, même avec des thread de basse priorité, donc je ne crois pas que votre délai soit du au multitache windows (à moins que vous soyez en train de copier 4 fichiers de 30 Go en permanence sur le réseau évidemment)
Vincent Burel
Ambassadeur Kosh
j'ai trouvé pas mal de choses sur google concernant le ddk. mais je prefererais franchement une doc en français. quelqu'un dispose t'il d'une telle source d'information ? (html ou bouquin à la rigueur)
j'ai trouvé pas mal de choses sur google concernant le ddk.
mais je prefererais franchement une doc en français.
quelqu'un dispose t'il d'une telle source d'information ? (html ou bouquin à
la rigueur)
j'ai trouvé pas mal de choses sur google concernant le ddk. mais je prefererais franchement une doc en français. quelqu'un dispose t'il d'une telle source d'information ? (html ou bouquin à la rigueur)
AMcD
Ambassadeur Kosh wrote:
j'ai trouvé pas mal de choses sur google concernant le ddk. mais je prefererais franchement une doc en français. quelqu'un dispose t'il d'une telle source d'information ? (html ou bouquin à la rigueur)
En français, c'est vite vu : que dalle ;o).
En anglais, les livres de base sont ceux de Walter Oney et de Art Baker/Jerry Lozano. Quelques sites :
j'ai trouvé pas mal de choses sur google concernant le ddk.
mais je prefererais franchement une doc en français.
quelqu'un dispose t'il d'une telle source d'information ? (html ou
bouquin à la rigueur)
En français, c'est vite vu : que dalle ;o).
En anglais, les livres de base sont ceux de Walter Oney et de Art
Baker/Jerry Lozano. Quelques sites :
j'ai trouvé pas mal de choses sur google concernant le ddk. mais je prefererais franchement une doc en français. quelqu'un dispose t'il d'une telle source d'information ? (html ou bouquin à la rigueur)
En français, c'est vite vu : que dalle ;o).
En anglais, les livres de base sont ceux de Walter Oney et de Art Baker/Jerry Lozano. Quelques sites :
