J'ai un petit souci avec un périphérique sur port USB, auquel j'accède
avec les classiques CreateFile(), ReadFile(), WriteFile() comme pour
d'autres périphériques de même métal communiquant par port série. Ca
marche bien pour l'essentiel, mais dans certains cas ReadFile() reste
bloqué parce qu'il n'y a pas de données retournées sur le port USB.
Avec les ports série, j'appelle GetCommeTimeouts() / SetCommTimeouts()
pour régler un timeout de lecture, mais lorsque j'ai un handle sur un
port USB, GetCommTimeouts() et SetCommTimeouts() retournent toutes deux
FALSE, GetLastError() retourne 1 et le FormatMessage() correspondant
indique "Fonction incorrecte", c'est à dire avec un décodeur
"Démerde-toi pour trouver ce qui cloche".
Question stupide, donc : comment fait-on pour avoir un timeout non
infini dans une opération ReadFile() sur un handle de port USB ?
Pour info, le handle est créé de la façon suivante :
hUsbRead=CreateFile(UsbDeviceName,
GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
NULL);
Je passe sur les détails d'obtention de UsbDeviceName... La lecture de
données en provenance du port est faite avec :
ReadFile(hUsbRead,
UsbMsgData,
UsbMsgLen,
&NbRead,
NULL);
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
Vincent Burel
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in message news:44ffcac5$0$25947$
Bonjour
J'ai un petit souci avec un périphérique sur port USB, auquel j'accède avec les classiques CreateFile(), ReadFile(), WriteFile() comme pour d'autres périphériques de même métal communiquant par port série. Ca marche bien pour l'essentiel, mais dans certains cas ReadFile() reste bloqué parce qu'il n'y a pas de données retournées sur le port USB.
Avec les ports série, j'appelle GetCommeTimeouts() / SetCommTimeouts() pour régler un timeout de lecture, mais lorsque j'ai un handle sur un port USB, GetCommTimeouts() et SetCommTimeouts() retournent toutes deux FALSE, GetLastError() retourne 1 et le FormatMessage() correspondant indique "Fonction incorrecte", c'est à dire avec un décodeur "Démerde-toi pour trouver ce qui cloche".
Question stupide, donc : comment fait-on pour avoir un timeout non infini dans une opération ReadFile() sur un handle de port USB ?
Pour info, le handle est créé de la façon suivante : hUsbRead=CreateFile(UsbDeviceName, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
perso, j'enlèverai les flag xxx_SHARE_xxx... après le mode OVERLAPPED (asynchrone) permet d'anuler une opération disque donc d'éviter le blocage ...
VB
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in
message news:44ffcac5$0$25947$ba4acef3@news.orange.fr...
Bonjour
J'ai un petit souci avec un périphérique sur port USB, auquel j'accède
avec les classiques CreateFile(), ReadFile(), WriteFile() comme pour
d'autres périphériques de même métal communiquant par port série. Ca
marche bien pour l'essentiel, mais dans certains cas ReadFile() reste
bloqué parce qu'il n'y a pas de données retournées sur le port USB.
Avec les ports série, j'appelle GetCommeTimeouts() / SetCommTimeouts()
pour régler un timeout de lecture, mais lorsque j'ai un handle sur un
port USB, GetCommTimeouts() et SetCommTimeouts() retournent toutes deux
FALSE, GetLastError() retourne 1 et le FormatMessage() correspondant
indique "Fonction incorrecte", c'est à dire avec un décodeur
"Démerde-toi pour trouver ce qui cloche".
Question stupide, donc : comment fait-on pour avoir un timeout non
infini dans une opération ReadFile() sur un handle de port USB ?
Pour info, le handle est créé de la façon suivante :
hUsbRead=CreateFile(UsbDeviceName,
GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
NULL);
perso, j'enlèverai les flag xxx_SHARE_xxx... après le mode OVERLAPPED
(asynchrone) permet d'anuler une opération disque donc d'éviter le blocage
...
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> wrote in message news:44ffcac5$0$25947$
Bonjour
J'ai un petit souci avec un périphérique sur port USB, auquel j'accède avec les classiques CreateFile(), ReadFile(), WriteFile() comme pour d'autres périphériques de même métal communiquant par port série. Ca marche bien pour l'essentiel, mais dans certains cas ReadFile() reste bloqué parce qu'il n'y a pas de données retournées sur le port USB.
Avec les ports série, j'appelle GetCommeTimeouts() / SetCommTimeouts() pour régler un timeout de lecture, mais lorsque j'ai un handle sur un port USB, GetCommTimeouts() et SetCommTimeouts() retournent toutes deux FALSE, GetLastError() retourne 1 et le FormatMessage() correspondant indique "Fonction incorrecte", c'est à dire avec un décodeur "Démerde-toi pour trouver ce qui cloche".
Question stupide, donc : comment fait-on pour avoir un timeout non infini dans une opération ReadFile() sur un handle de port USB ?
Pour info, le handle est créé de la façon suivante : hUsbRead=CreateFile(UsbDeviceName, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
perso, j'enlèverai les flag xxx_SHARE_xxx... après le mode OVERLAPPED (asynchrone) permet d'anuler une opération disque donc d'éviter le blocage ...
VB
johann.d
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> a écrit dans le message de news:44ffcac5$0$25947$
Bonjour
Bonjour aussi.
Avec les ports série, j'appelle GetCommeTimeouts() / SetCommTimeouts() pour régler un timeout de lecture, mais lorsque j'ai un handle sur un port USB, GetCommTimeouts() et SetCommTimeouts() retournent toutes deux FALSE, GetLastError() retourne 1 et le FormatMessage() correspondant indique "Fonction incorrecte", c'est à dire avec un décodeur "Démerde-toi pour trouver ce qui cloche".
J'ai déjà rencontré le même genre de problèmes sur un bridge SDIO <-> COMM sur un Windows CE. Ce n'est peut-être pas le cas chez toi, mais ça venait tout bêtement du driver fourni par le fabricant qui n'implémentait pas les timeouts (ensuite ça a été encore plus débile, ils ont fait en sorte que GetCommTimeouts et SetCommTimeouts renvoient TRUE, sans pour autant les implémenter ! Mais bon je m'égare).
Question stupide, donc : comment fait-on pour avoir un timeout non infini dans une opération ReadFile() sur un handle de port USB ?
Ben en l'occurence j'utilise tous les jours des bridges USB <-> COMM de chez FTDI, avec le driver de chez FTDI, et je n'ai jamais eu le moindre soucis. Faudrait demander au fournisseur du driver s'il a déjà rencontré le problème (à moins que ça soit un driver générique ?)
Pour info, le handle est créé de la façon suivante : hUsbRead=CreateFile(UsbDeviceName, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); Je passe sur les détails d'obtention de UsbDeviceName...
Ca permettrait cependant de savoir d'où vient le driver ?
-- Johann.D
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> a écrit dans
le message de news:44ffcac5$0$25947$ba4acef3@news.orange.fr...
Bonjour
Bonjour aussi.
Avec les ports série, j'appelle GetCommeTimeouts() / SetCommTimeouts()
pour régler un timeout de lecture, mais lorsque j'ai un handle sur un
port USB, GetCommTimeouts() et SetCommTimeouts() retournent toutes deux
FALSE, GetLastError() retourne 1 et le FormatMessage() correspondant
indique "Fonction incorrecte", c'est à dire avec un décodeur
"Démerde-toi pour trouver ce qui cloche".
J'ai déjà rencontré le même genre de problèmes sur un bridge SDIO <-> COMM
sur un Windows CE. Ce n'est peut-être pas le cas chez toi, mais ça venait
tout bêtement du driver fourni par le fabricant qui n'implémentait pas les
timeouts (ensuite ça a été encore plus débile, ils ont fait en sorte que
GetCommTimeouts et SetCommTimeouts renvoient TRUE, sans pour autant les
implémenter ! Mais bon je m'égare).
Question stupide, donc : comment fait-on pour avoir un timeout non
infini dans une opération ReadFile() sur un handle de port USB ?
Ben en l'occurence j'utilise tous les jours des bridges USB <-> COMM de chez
FTDI, avec le driver de chez FTDI, et je n'ai jamais eu le moindre soucis.
Faudrait demander au fournisseur du driver s'il a déjà rencontré le problème
(à moins que ça soit un driver générique ?)
Pour info, le handle est créé de la façon suivante :
hUsbRead=CreateFile(UsbDeviceName,
GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
NULL);
Je passe sur les détails d'obtention de UsbDeviceName...
Ca permettrait cependant de savoir d'où vient le driver ?
"Bertrand Lenoir-Welter" <bertrand-dot-2006-at-galaad-dot-net> a écrit dans le message de news:44ffcac5$0$25947$
Bonjour
Bonjour aussi.
Avec les ports série, j'appelle GetCommeTimeouts() / SetCommTimeouts() pour régler un timeout de lecture, mais lorsque j'ai un handle sur un port USB, GetCommTimeouts() et SetCommTimeouts() retournent toutes deux FALSE, GetLastError() retourne 1 et le FormatMessage() correspondant indique "Fonction incorrecte", c'est à dire avec un décodeur "Démerde-toi pour trouver ce qui cloche".
J'ai déjà rencontré le même genre de problèmes sur un bridge SDIO <-> COMM sur un Windows CE. Ce n'est peut-être pas le cas chez toi, mais ça venait tout bêtement du driver fourni par le fabricant qui n'implémentait pas les timeouts (ensuite ça a été encore plus débile, ils ont fait en sorte que GetCommTimeouts et SetCommTimeouts renvoient TRUE, sans pour autant les implémenter ! Mais bon je m'égare).
Question stupide, donc : comment fait-on pour avoir un timeout non infini dans une opération ReadFile() sur un handle de port USB ?
Ben en l'occurence j'utilise tous les jours des bridges USB <-> COMM de chez FTDI, avec le driver de chez FTDI, et je n'ai jamais eu le moindre soucis. Faudrait demander au fournisseur du driver s'il a déjà rencontré le problème (à moins que ça soit un driver générique ?)
Pour info, le handle est créé de la façon suivante : hUsbRead=CreateFile(UsbDeviceName, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); Je passe sur les détails d'obtention de UsbDeviceName...
Ca permettrait cependant de savoir d'où vient le driver ?
-- Johann.D
Bertrand Lenoir-Welter
johann.d :
J'ai déjà rencontré le même genre de problèmes sur un bridge SDIO <-> COMM sur un Windows CE. Ce n'est peut-être pas le cas chez toi, mais ça venait tout bêtement du driver fourni par le fabricant qui n'implémentait pas les timeouts (ensuite ça a été encore plus débile, ils ont fait en sorte que GetCommTimeouts et SetCommTimeouts renvoient TRUE, sans pour autant les implémenter ! Mais bon je m'égare).
Argh, je vois le genre... Le problème, c'est que le driver m'a été fourni par le gars qui a développé la carte et que j'ai pas cette info. A mon avis, il a utilisé un truc générique fourni avec le microchip ARM présent sur sa carte. Je pense pas qu'il ait développé lui-même son driver.
La curiosité, en fait, c'est que de temps en temps, j'ai un WriteFile qui bloque. SnoopyPro me dit que le paquet est parti, mais mon appli reste bloquée dans le WriteFile (timeout infini ?). De toute façon, même en tuant l'appli, la carte devient sourde et muette à partir de ce moment, et plus moyen de communiquer.
Bon, je vais voir ces histoires de driver avec le développeur de la carte. Merci pour les tuyaux, en tout cas. Merci aussi à Vincent, ses remarques m'ont fait simplifier les CreateFile() associés (faut toujours regarder de plus près le code copié-collé).
johann.d :
J'ai déjà rencontré le même genre de problèmes sur un bridge SDIO <-> COMM
sur un Windows CE. Ce n'est peut-être pas le cas chez toi, mais ça venait
tout bêtement du driver fourni par le fabricant qui n'implémentait pas les
timeouts (ensuite ça a été encore plus débile, ils ont fait en sorte que
GetCommTimeouts et SetCommTimeouts renvoient TRUE, sans pour autant les
implémenter ! Mais bon je m'égare).
Argh, je vois le genre... Le problème, c'est que le driver m'a été
fourni par le gars qui a développé la carte et que j'ai pas cette info.
A mon avis, il a utilisé un truc générique fourni avec le microchip ARM
présent sur sa carte. Je pense pas qu'il ait développé lui-même son driver.
La curiosité, en fait, c'est que de temps en temps, j'ai un WriteFile
qui bloque. SnoopyPro me dit que le paquet est parti, mais mon appli
reste bloquée dans le WriteFile (timeout infini ?). De toute façon, même
en tuant l'appli, la carte devient sourde et muette à partir de ce
moment, et plus moyen de communiquer.
Bon, je vais voir ces histoires de driver avec le développeur de la
carte. Merci pour les tuyaux, en tout cas. Merci aussi à Vincent, ses
remarques m'ont fait simplifier les CreateFile() associés (faut toujours
regarder de plus près le code copié-collé).
J'ai déjà rencontré le même genre de problèmes sur un bridge SDIO <-> COMM sur un Windows CE. Ce n'est peut-être pas le cas chez toi, mais ça venait tout bêtement du driver fourni par le fabricant qui n'implémentait pas les timeouts (ensuite ça a été encore plus débile, ils ont fait en sorte que GetCommTimeouts et SetCommTimeouts renvoient TRUE, sans pour autant les implémenter ! Mais bon je m'égare).
Argh, je vois le genre... Le problème, c'est que le driver m'a été fourni par le gars qui a développé la carte et que j'ai pas cette info. A mon avis, il a utilisé un truc générique fourni avec le microchip ARM présent sur sa carte. Je pense pas qu'il ait développé lui-même son driver.
La curiosité, en fait, c'est que de temps en temps, j'ai un WriteFile qui bloque. SnoopyPro me dit que le paquet est parti, mais mon appli reste bloquée dans le WriteFile (timeout infini ?). De toute façon, même en tuant l'appli, la carte devient sourde et muette à partir de ce moment, et plus moyen de communiquer.
Bon, je vais voir ces histoires de driver avec le développeur de la carte. Merci pour les tuyaux, en tout cas. Merci aussi à Vincent, ses remarques m'ont fait simplifier les CreateFile() associés (faut toujours regarder de plus près le code copié-collé).
