Réglage de timeout dans ReadFile() sur port USB

Le
Bertrand Lenoir-Welter
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);
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);

Merci d'avance pour tout tuyau.

Bertrand

  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
Vincent Burel
Le #9770441
"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
Le #9770381
"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
Le #9770371
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é).
Poster une réponse
Anonyme