>on a 2 valeurs à aller pecher sur des ports differents.
>le probleme est que entre ces deux "acquisitions", le thread peut se fa
ire
>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 ri
en)
>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és
oudre
>d'une façon trés voisine. mais comment faire en sorte d'avoir les bonne
s
>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.
>
>
AMHA il n'y a que sur un Windows NT "customisée" temps réel qu'on peut e
nvisager de passer outre la préhemption dans certains cas (il y a des éd
iteurs qui sont spécialisés dans ce genre de modification du noyau).
Par contre je n'ai pas totalement compris ton problème :
- est-ce qu'il s'agit seulement de lire les données avec la contrainte d
e cohérence temporelle entre les deux ports (auquel cas c'est le dévelop
pement d'un driver -mode noyau- commun qui pourra garantir cette cohéren
ce)
OU
- est-ce qu'il s'agit plutôt de lire les données à intervalle régulier,
ou sans perdre chaque évolution (cas d'un port série) auquel cas la cont
rainte est beaucoup plus lourde?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Article poste via Voila News - http://www.news.voila.fr
Le : Tue Oct 14 19:08:04 2003 depuis l'IP : aste-genev-bois-105-2-1-18.w80-11.abo.wanadoo.fr [VIP 628736818521]
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ambassadeur Kosh
> AMHA il n'y a que sur un Windows NT "customisée" temps réel qu'on peut e nvisager de passer outre la préhemption dans certains cas (il y a des éd iteurs qui sont spécialisés dans ce genre de modification du noyau).
Par contre je n'ai pas totalement compris ton problème :
- est-ce qu'il s'agit seulement de lire les données avec la contrainte d e cohérence temporelle entre les deux ports (auquel cas c'est le dévelop pement d'un driver -mode noyau- commun qui pourra garantir cette cohéren ce)
oui. l'acquisition, c'est pecher un ensemble de valeurs issues de capteurs à un moment donné. ces valeurs sont lues sur une carte d'acquisition (TC32/16) et sur le COM.
OU - est-ce qu'il s'agit plutôt de lire les données à intervalle régulier, ou sans perdre chaque évolution (cas d'un port série) auquel cas la cont rainte est beaucoup plus lourde?
dans ce cas précis, l'arrivée de données sur le port série est un signal de départ qui sert à aller chercher les autres valeurs. il y a juste qu'entre le moment ou la donnée arrive physiquement sur le port et le moment ou le read du thread est debloqué avec la valeur résultat puis ou on va pecher les valeurs, il y a un temps un peu trop long / variable / imprevisible.
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 mesurant 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).
merci pour le temps que tu consacres à ma question.
> AMHA il n'y a que sur un Windows NT "customisée" temps réel qu'on peut e
nvisager de passer outre la préhemption dans certains cas (il y a des éd
iteurs qui sont spécialisés dans ce genre de modification du noyau).
Par contre je n'ai pas totalement compris ton problème :
- est-ce qu'il s'agit seulement de lire les données avec la contrainte d
e cohérence temporelle entre les deux ports (auquel cas c'est le dévelop
pement d'un driver -mode noyau- commun qui pourra garantir cette cohéren
ce)
oui. l'acquisition, c'est pecher un ensemble de valeurs issues de capteurs à
un moment donné.
ces valeurs sont lues sur une carte d'acquisition (TC32/16) et sur le COM.
OU
- est-ce qu'il s'agit plutôt de lire les données à intervalle régulier,
ou sans perdre chaque évolution (cas d'un port série) auquel cas la cont
rainte est beaucoup plus lourde?
dans ce cas précis, l'arrivée de données sur le port série est un signal de
départ qui sert à aller chercher les autres valeurs.
il y a juste qu'entre le moment ou la donnée arrive physiquement sur le port
et le moment ou le read du thread est debloqué avec la valeur résultat puis
ou on va pecher les valeurs, il y a un temps un peu trop long / variable /
imprevisible.
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 mesurant
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).
merci pour le temps que tu consacres à ma question.
> AMHA il n'y a que sur un Windows NT "customisée" temps réel qu'on peut e nvisager de passer outre la préhemption dans certains cas (il y a des éd iteurs qui sont spécialisés dans ce genre de modification du noyau).
Par contre je n'ai pas totalement compris ton problème :
- est-ce qu'il s'agit seulement de lire les données avec la contrainte d e cohérence temporelle entre les deux ports (auquel cas c'est le dévelop pement d'un driver -mode noyau- commun qui pourra garantir cette cohéren ce)
oui. l'acquisition, c'est pecher un ensemble de valeurs issues de capteurs à un moment donné. ces valeurs sont lues sur une carte d'acquisition (TC32/16) et sur le COM.
OU - est-ce qu'il s'agit plutôt de lire les données à intervalle régulier, ou sans perdre chaque évolution (cas d'un port série) auquel cas la cont rainte est beaucoup plus lourde?
dans ce cas précis, l'arrivée de données sur le port série est un signal de départ qui sert à aller chercher les autres valeurs. il y a juste qu'entre le moment ou la donnée arrive physiquement sur le port et le moment ou le read du thread est debloqué avec la valeur résultat puis ou on va pecher les valeurs, il y a un temps un peu trop long / variable / imprevisible.
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 mesurant 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).
merci pour le temps que tu consacres à ma question.
