Bonjour à tous,
Si j'ai bien compris c'est surtout la réception son problème, car pour
marquer la fin d'une trame dans le protocole qu'il utilise il n'y a pas de
caractère mais tout simplement un temps de non émission de l'ordre de 2ms.
Ainsi il peut recevoir 2 trames espacées de 10ms, et il faut êter capable de
détecter ces 10ms pour identifier que c'est 2 trames et non une seule...
Et sinon au niveau driver vous avez une idée sur ce que ça représente comme
travail ?
Merci pour votre aide.
Bonjour à tous,
Si j'ai bien compris c'est surtout la réception son problème, car pour
marquer la fin d'une trame dans le protocole qu'il utilise il n'y a pas de
caractère mais tout simplement un temps de non émission de l'ordre de 2ms.
Ainsi il peut recevoir 2 trames espacées de 10ms, et il faut êter capable de
détecter ces 10ms pour identifier que c'est 2 trames et non une seule...
Et sinon au niveau driver vous avez une idée sur ce que ça représente comme
travail ?
Merci pour votre aide.
Bonjour à tous,
Si j'ai bien compris c'est surtout la réception son problème, car pour
marquer la fin d'une trame dans le protocole qu'il utilise il n'y a pas de
caractère mais tout simplement un temps de non émission de l'ordre de 2ms.
Ainsi il peut recevoir 2 trames espacées de 10ms, et il faut êter capable de
détecter ces 10ms pour identifier que c'est 2 trames et non une seule...
Et sinon au niveau driver vous avez une idée sur ce que ça représente comme
travail ?
Merci pour votre aide.
Ca me paraît bien compliqué tout ça pour un cas assez banal.
Pas besoin de driver : Windows permet de gérer la détection de fin de
trame avec le membre ReadIntervalTimeout de la structure COMMTIMEOUTS.
Par exemple, en synchrone, ton ReadFile reste bloquant jusqu'à ce
qu'il se soit écoulé ReadIntervalTimeout ms depuis la réception du
dernier caractère.
S'il veut être capable d'émettre des caractères en même temps qu'il en
attend en réception, il faut absolument passer en asynchrone en
ouvrant le port en overlapped.
Ca me paraît bien compliqué tout ça pour un cas assez banal.
Pas besoin de driver : Windows permet de gérer la détection de fin de
trame avec le membre ReadIntervalTimeout de la structure COMMTIMEOUTS.
Par exemple, en synchrone, ton ReadFile reste bloquant jusqu'à ce
qu'il se soit écoulé ReadIntervalTimeout ms depuis la réception du
dernier caractère.
S'il veut être capable d'émettre des caractères en même temps qu'il en
attend en réception, il faut absolument passer en asynchrone en
ouvrant le port en overlapped.
Ca me paraît bien compliqué tout ça pour un cas assez banal.
Pas besoin de driver : Windows permet de gérer la détection de fin de
trame avec le membre ReadIntervalTimeout de la structure COMMTIMEOUTS.
Par exemple, en synchrone, ton ReadFile reste bloquant jusqu'à ce
qu'il se soit écoulé ReadIntervalTimeout ms depuis la réception du
dernier caractère.
S'il veut être capable d'émettre des caractères en même temps qu'il en
attend en réception, il faut absolument passer en asynchrone en
ouvrant le port en overlapped.
Hello,Ca me paraît bien compliqué tout ça pour un cas assez banal.
Pas besoin de driver : Windows permet de gérer la détection de fin de
trame avec le membre ReadIntervalTimeout de la structure COMMTIMEOUTS.
Est-ce précis à la ms, dans 100% des cas ?
Hello,
Ca me paraît bien compliqué tout ça pour un cas assez banal.
Pas besoin de driver : Windows permet de gérer la détection de fin de
trame avec le membre ReadIntervalTimeout de la structure COMMTIMEOUTS.
Est-ce précis à la ms, dans 100% des cas ?
Hello,Ca me paraît bien compliqué tout ça pour un cas assez banal.
Pas besoin de driver : Windows permet de gérer la détection de fin de
trame avec le membre ReadIntervalTimeout de la structure COMMTIMEOUTS.
Est-ce précis à la ms, dans 100% des cas ?
> certainement pas, windows n'est pas un OS temps réel, donc tu ne peux rien
prédire.
c'est pour ça qu'il y a encore des trucs qui tournent en dos pur, car
c'est du monotâche.
pour le temps réel prédictif, voir les OS prévus pour
> certainement pas, windows n'est pas un OS temps réel, donc tu ne peux rien
prédire.
c'est pour ça qu'il y a encore des trucs qui tournent en dos pur, car
c'est du monotâche.
pour le temps réel prédictif, voir les OS prévus pour
> certainement pas, windows n'est pas un OS temps réel, donc tu ne peux rien
prédire.
c'est pour ça qu'il y a encore des trucs qui tournent en dos pur, car
c'est du monotâche.
pour le temps réel prédictif, voir les OS prévus pour
certainement pas, windows n'est pas un OS temps réel, donc tu ne peux
rien
prédire.
c'est pour ça qu'il y a encore des trucs qui tournent en dos pur, car
c'est du monotâche.
pour le temps réel prédictif, voir les OS prévus pour
Et au niveau noyau (driver) on peut pas y arriver ?
Le truc c'est que ce mec développe un logiciel couplé à un matériel, et
que
ses utilisateurs sont tous sous Windows.
Moi je vois 2 solutions :
- arriver à faire ça en soft (driver ?).
- insérer un composant électronique entre le PC et le bidule, qu'on
pilote
aussi par liaison série, sauf que lui il faut pas le faire en temsp réel.
certainement pas, windows n'est pas un OS temps réel, donc tu ne peux
rien
prédire.
c'est pour ça qu'il y a encore des trucs qui tournent en dos pur, car
c'est du monotâche.
pour le temps réel prédictif, voir les OS prévus pour
Et au niveau noyau (driver) on peut pas y arriver ?
Le truc c'est que ce mec développe un logiciel couplé à un matériel, et
que
ses utilisateurs sont tous sous Windows.
Moi je vois 2 solutions :
- arriver à faire ça en soft (driver ?).
- insérer un composant électronique entre le PC et le bidule, qu'on
pilote
aussi par liaison série, sauf que lui il faut pas le faire en temsp réel.
certainement pas, windows n'est pas un OS temps réel, donc tu ne peux
rien
prédire.
c'est pour ça qu'il y a encore des trucs qui tournent en dos pur, car
c'est du monotâche.
pour le temps réel prédictif, voir les OS prévus pour
Et au niveau noyau (driver) on peut pas y arriver ?
Le truc c'est que ce mec développe un logiciel couplé à un matériel, et
que
ses utilisateurs sont tous sous Windows.
Moi je vois 2 solutions :
- arriver à faire ça en soft (driver ?).
- insérer un composant électronique entre le PC et le bidule, qu'on
pilote
aussi par liaison série, sauf que lui il faut pas le faire en temsp réel.
certainement pas, windows n'est pas un OS temps réel, donc tu ne peux rien
prédire.
c'est pour ça qu'il y a encore des trucs qui tournent en dos pur, car
c'est du monotâche.
pour le temps réel prédictif, voir les OS prévus pour
Et au niveau noyau (driver) on peut pas y arriver ?
Le truc c'est que ce mec développe un logiciel couplé à un matériel, et que
ses utilisateurs sont tous sous Windows.
Moi je vois 2 solutions :
- arriver à faire ça en soft (driver ?).
- insérer un composant électronique entre le PC et le bidule, qu'on pilote
aussi par liaison série, sauf que lui il faut pas le faire en temsp réel.
certainement pas, windows n'est pas un OS temps réel, donc tu ne peux rien
prédire.
c'est pour ça qu'il y a encore des trucs qui tournent en dos pur, car
c'est du monotâche.
pour le temps réel prédictif, voir les OS prévus pour
Et au niveau noyau (driver) on peut pas y arriver ?
Le truc c'est que ce mec développe un logiciel couplé à un matériel, et que
ses utilisateurs sont tous sous Windows.
Moi je vois 2 solutions :
- arriver à faire ça en soft (driver ?).
- insérer un composant électronique entre le PC et le bidule, qu'on pilote
aussi par liaison série, sauf que lui il faut pas le faire en temsp réel.
certainement pas, windows n'est pas un OS temps réel, donc tu ne peux rien
prédire.
c'est pour ça qu'il y a encore des trucs qui tournent en dos pur, car
c'est du monotâche.
pour le temps réel prédictif, voir les OS prévus pour
Et au niveau noyau (driver) on peut pas y arriver ?
Le truc c'est que ce mec développe un logiciel couplé à un matériel, et que
ses utilisateurs sont tous sous Windows.
Moi je vois 2 solutions :
- arriver à faire ça en soft (driver ?).
- insérer un composant électronique entre le PC et le bidule, qu'on pilote
aussi par liaison série, sauf que lui il faut pas le faire en temsp réel.
> je ne pense qu'on puisse y arriver au niveau driver, il faut passer au
niveau kernel ( bon, la distinction, je dis peut-être une c...., je ne
suis pas spécialiste).
il me semble qu'il existe une version de windows plus adaptée, mais
destinée à être incorporée dans des dispositifs, donc non installable sur
un pc.
ou alors être sûr que la machine ne fera que çà.
par exemple au boulot, on a une application qui fait de l'acquisition par
port série, le pc ne fait que çà, et l' autre dispositif dispose d'une
mémoire tampon.
en cas de perte de communication, il peut y a voir saturation du tampon et
perte de données
> je ne pense qu'on puisse y arriver au niveau driver, il faut passer au
niveau kernel ( bon, la distinction, je dis peut-être une c...., je ne
suis pas spécialiste).
il me semble qu'il existe une version de windows plus adaptée, mais
destinée à être incorporée dans des dispositifs, donc non installable sur
un pc.
ou alors être sûr que la machine ne fera que çà.
par exemple au boulot, on a une application qui fait de l'acquisition par
port série, le pc ne fait que çà, et l' autre dispositif dispose d'une
mémoire tampon.
en cas de perte de communication, il peut y a voir saturation du tampon et
perte de données
> je ne pense qu'on puisse y arriver au niveau driver, il faut passer au
niveau kernel ( bon, la distinction, je dis peut-être une c...., je ne
suis pas spécialiste).
il me semble qu'il existe une version de windows plus adaptée, mais
destinée à être incorporée dans des dispositifs, donc non installable sur
un pc.
ou alors être sûr que la machine ne fera que çà.
par exemple au boulot, on a une application qui fait de l'acquisition par
port série, le pc ne fait que çà, et l' autre dispositif dispose d'une
mémoire tampon.
en cas de perte de communication, il peut y a voir saturation du tampon et
perte de données
>> - arriver à faire ça en soft (driver ?).
Ca n'est pas suffisant pour faire du temps réél.
Autre possibilité : Utiliser RTX (www.vci.com). C'est un noyeau temps
réel, mais qui permet de continuer à faire tourner windows sur la même
machine (en fait, tout le scheduleur windows est considéré comme une tâche
peu prioritaire dans le scheduleur RTX). Il y a un coût de license de dev,
et un coût au runtime (genre 500€ par poste).
>> - arriver à faire ça en soft (driver ?).
Ca n'est pas suffisant pour faire du temps réél.
Autre possibilité : Utiliser RTX (www.vci.com). C'est un noyeau temps
réel, mais qui permet de continuer à faire tourner windows sur la même
machine (en fait, tout le scheduleur windows est considéré comme une tâche
peu prioritaire dans le scheduleur RTX). Il y a un coût de license de dev,
et un coût au runtime (genre 500€ par poste).
>> - arriver à faire ça en soft (driver ?).
Ca n'est pas suffisant pour faire du temps réél.
Autre possibilité : Utiliser RTX (www.vci.com). C'est un noyeau temps
réel, mais qui permet de continuer à faire tourner windows sur la même
machine (en fait, tout le scheduleur windows est considéré comme une tâche
peu prioritaire dans le scheduleur RTX). Il y a un coût de license de dev,
et un coût au runtime (genre 500€ par poste).
- arriver à faire ça en soft (driver ?).
Ca n'est pas suffisant pour faire du temps réél.
Voir mon autre réponse pour + d'infos. Par temps réel, c'est juste prendre
la main sur tout le reste quelques secondes dans une journée...
Autre possibilité : Utiliser RTX (www.vci.com). C'est un noyeau temps
réel, mais qui permet de continuer à faire tourner windows sur la même
machine (en fait, tout le scheduleur windows est considéré comme une tâche
peu prioritaire dans le scheduleur RTX). Il y a un coût de license de dev,
et un coût au runtime (genre 500€ par poste).
Seulement j'ai peur que 500€ ne soit pas loin du prix du kit qu'il compte
vendre...
Sans compter qu'il n'est pas question de toucher à l'OS du client.
Ca doit s'installer / se désisntaller en 2 clics. C'est une application
ultra light.
- arriver à faire ça en soft (driver ?).
Ca n'est pas suffisant pour faire du temps réél.
Voir mon autre réponse pour + d'infos. Par temps réel, c'est juste prendre
la main sur tout le reste quelques secondes dans une journée...
Autre possibilité : Utiliser RTX (www.vci.com). C'est un noyeau temps
réel, mais qui permet de continuer à faire tourner windows sur la même
machine (en fait, tout le scheduleur windows est considéré comme une tâche
peu prioritaire dans le scheduleur RTX). Il y a un coût de license de dev,
et un coût au runtime (genre 500€ par poste).
Seulement j'ai peur que 500€ ne soit pas loin du prix du kit qu'il compte
vendre...
Sans compter qu'il n'est pas question de toucher à l'OS du client.
Ca doit s'installer / se désisntaller en 2 clics. C'est une application
ultra light.
- arriver à faire ça en soft (driver ?).
Ca n'est pas suffisant pour faire du temps réél.
Voir mon autre réponse pour + d'infos. Par temps réel, c'est juste prendre
la main sur tout le reste quelques secondes dans une journée...
Autre possibilité : Utiliser RTX (www.vci.com). C'est un noyeau temps
réel, mais qui permet de continuer à faire tourner windows sur la même
machine (en fait, tout le scheduleur windows est considéré comme une tâche
peu prioritaire dans le scheduleur RTX). Il y a un coût de license de dev,
et un coût au runtime (genre 500€ par poste).
Seulement j'ai peur que 500€ ne soit pas loin du prix du kit qu'il compte
vendre...
Sans compter qu'il n'est pas question de toucher à l'OS du client.
Ca doit s'installer / se désisntaller en 2 clics. C'est une application
ultra light.
Aurelien REGAT-BARREL wrote:- arriver à faire ça en soft (driver ?).
Ca n'est pas suffisant pour faire du temps réél.
Voir mon autre réponse pour + d'infos. Par temps réel, c'est juste prendre
la main sur tout le reste quelques secondes dans une journée...
Vu l'utilisation de ce que tu en dis dans un autre post, les temps
impliqués, la fréquence d'utilisation, les conséquences en cas
d'échec... Je me dis qu'en se mettant en priorité maximale, en faisant
une attente active, et en mesurant le délai avec les performance
counters, il y a une bonne probabilité que ça passe. Après, il faut voir
s'il y a une procédue simple en cas d'échec (genre on demande au client
de cliquer une deuxième fois sur le bouton... ou encore si on n'a pas eu
ce qu'on attendais au bout de n secondes, on recommence nous même).
Par contre, je n'ai pas d'expérience de l'écriture de drivers pour
savoir si ça peut aider. Intuitivement, je n'y crois pas beaucoup.
Aurelien REGAT-BARREL wrote:
- arriver à faire ça en soft (driver ?).
Ca n'est pas suffisant pour faire du temps réél.
Voir mon autre réponse pour + d'infos. Par temps réel, c'est juste prendre
la main sur tout le reste quelques secondes dans une journée...
Vu l'utilisation de ce que tu en dis dans un autre post, les temps
impliqués, la fréquence d'utilisation, les conséquences en cas
d'échec... Je me dis qu'en se mettant en priorité maximale, en faisant
une attente active, et en mesurant le délai avec les performance
counters, il y a une bonne probabilité que ça passe. Après, il faut voir
s'il y a une procédue simple en cas d'échec (genre on demande au client
de cliquer une deuxième fois sur le bouton... ou encore si on n'a pas eu
ce qu'on attendais au bout de n secondes, on recommence nous même).
Par contre, je n'ai pas d'expérience de l'écriture de drivers pour
savoir si ça peut aider. Intuitivement, je n'y crois pas beaucoup.
Aurelien REGAT-BARREL wrote:- arriver à faire ça en soft (driver ?).
Ca n'est pas suffisant pour faire du temps réél.
Voir mon autre réponse pour + d'infos. Par temps réel, c'est juste prendre
la main sur tout le reste quelques secondes dans une journée...
Vu l'utilisation de ce que tu en dis dans un autre post, les temps
impliqués, la fréquence d'utilisation, les conséquences en cas
d'échec... Je me dis qu'en se mettant en priorité maximale, en faisant
une attente active, et en mesurant le délai avec les performance
counters, il y a une bonne probabilité que ça passe. Après, il faut voir
s'il y a une procédue simple en cas d'échec (genre on demande au client
de cliquer une deuxième fois sur le bouton... ou encore si on n'a pas eu
ce qu'on attendais au bout de n secondes, on recommence nous même).
Par contre, je n'ai pas d'expérience de l'écriture de drivers pour
savoir si ça peut aider. Intuitivement, je n'y crois pas beaucoup.
