USB device access via DeviceIoControl and WriteFile / ReadFile
in [Device Drivers]
|
From: Manfred Wilner on 14 Sep 2005 12:01 Sure, the problem was before too that sometimes the read came back OK and sometimes not and this behavior hasn't changed with the WritePort/ReadPort but the ReadPort comes back and I can retry. I believe this is a WXP booting issue since there are soo many things happening that sometimes the read isn't succeeding and therefore has to be repeated. This works now and after the second try I have my results. \Manfred "Bobby Mattappally [MS]" <bobbym(a)online.microsoft.com> wrote in message news:hWHpqWMuFHA.932(a)TK2MSFTNGXA01.phx.gbl... > > -------------------- > From: "Manfred Wilner" <manfred.w(a)swecoinus.com> > References: <#zRStcrnFHA.1048(a)tk2msftngp13.phx.gbl> > <KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl> > <eBrff6WtFHA.2540(a)TK2MSFTNGP09.phx.gbl> > <41BRkwYtFHA.780(a)TK2MSFTNGXA01.phx.gbl> > <uEWOiu6tFHA.596(a)TK2MSFTNGP12.phx.gbl> > <eujtPn9tFHA.2328(a)TK2MSFTNGXA01.phx.gbl> > Subject: Re: USB device access via DeviceIoControl and WriteFile / > ReadFile > Date: Tue, 13 Sep 2005 15:27:20 -0400 > Lines: 188 > >>Thank you Bobby this did it! > > Can you clarify? > Did the WritePort/ReadPort sequence succeed in this case (during reboot) > ? > Or did you get the ReadPort to fail (timeout) and you had to redo it? > > > > Thank you, > Bobby Mattappally > Microsoft > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > > > "Bobby Mattappally [MS]" <bobbym(a)online.microsoft.com> wrote in message > news:eujtPn9tFHA.2328(a)TK2MSFTNGXA01.phx.gbl... >> Hi Manfred, >>>I didn't realize that the ReadPort/WritePort functions would work since >>>it >>>is the USB I am talking to but I will give it a try. How would you >>>suggest >>>canceling after timeout? >> >> If you are using ReadPort/WritePort, you don't need to do any cancelling, >> the port monitor will cancel the operation on timeout and will return >> false. >> So you can decide whether to redo the Read/Write or something else. >> >> >> Hope this helps. >> >> Thank you, >> Bobby Mattappally >> Microsoft >> >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> >> >> >> >> >> >> -------------------- >> From: "Manfred Wilner" <manfred.w(a)swecoinus.com> >> References: <#zRStcrnFHA.1048(a)tk2msftngp13.phx.gbl> >> <KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl> >> <eBrff6WtFHA.2540(a)TK2MSFTNGP09.phx.gbl> >> <41BRkwYtFHA.780(a)TK2MSFTNGXA01.phx.gbl> >> Subject: Re: USB device access via DeviceIoControl and WriteFile / >> ReadFile >> Date: Mon, 12 Sep 2005 11:06:59 -0400 >> >> >> Hi Bobby thank you for your reply, >> I didn't realize that the ReadPort/WritePort functions would work since >> it >> is the USB I am talking to but I will give it a try. How would you >> suggest >> canceling after timeout? >> >> Yes I have implemented the vendor commands but need the >> ReadPort/WritePort >> functions for backwards compatibility during first intialization. >> >> \Manfred >> >> >> >> "Bobby Mattappally [MS]" <bobbym(a)online.microsoft.com> wrote in message >> news:41BRkwYtFHA.780(a)TK2MSFTNGXA01.phx.gbl... >>> Hi Manfred, >>> >>> One solution to avoid the hang would be to do an asynchronous >>> (Overlapped >>> IO) Read/Write operation and Cancel the IO after a predefined time out >>> and >>> retry the operations. >>> Is there a reason you are opening the device on your own to do the the >>> Read >>> and Write instead of using the ReadPort/WritePort functions exposed by >>> the >>> port monitor? The inbox USB port monitor does its Read and Write using >>> Asynchronous IO with settable timeout values. You can also modify the >>> timeout value by using pfnSetPortTimeout method exposed by the port >>> monitor. >>> >>> Also have you investigated whether you could use the below I/O control >>> codes instead of the Write/Read option? >>> >>> IOCTL_USBPRINT_VENDOR_GET_COMMAND >>> IOCTL_USBPRINT_VENDOR_SET_COMMAND >>> >>> >>> >>> Hope this helps. >>> >>> Thank you, >>> Bobby Mattappally >>> Microsoft >>> >>> This posting is provided "AS IS" with no warranties, and confers no >>> rights. >>> >>> >>> >>> -------------------- >>> From: "Manfred Wilner" <manfred.w(a)swecoinus.com> >>> References: <#zRStcrnFHA.1048(a)tk2msftngp13.phx.gbl> >>> <KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl> >>> Subject: Re: USB device access via DeviceIoControl and WriteFile / >>> ReadFile >>> Date: Fri, 9 Sep 2005 14:45:15 -0400 >>> >>> Hello Martin, >>> >>> Here is what I am doing. >>> >>> I open a file handle >>> >>> hDevice = CreateFile ( pTmpPort->DevicePath, >>> >>> GENERIC_WRITE | GENERIC_READ, // read/write access >>> >>> FILE_SHARE_READ | FILE_SHARE_WRITE, >>> >>> NULL, // no SECURITY_ATTRIBUTES structure >>> >>> OPEN_EXISTING, // No special create flags >>> >>> 0,//FILE_FLAG_OVERLAPPED, // No special attributes >>> >>> NULL); // No template file >>> >>> I send an IOCTL_USBPRINT_GET_1284_ID >>> >>> IoctlResult = DeviceIoControl( hDevice, IOCTL_USBPRINT_GET_1284_ID, >>> NULL, >>> 0, >>> >>> pszLPID,255, &ReturnedLength, NULL); >>> >>> and then a WriteFile to the same device handle. >>> >>> if ((IoctlResult = WriteFile(hDevice, inBuf, inBufSize, &ReturnedLength, >>> >>> NULL)) == 0) >>> >>> Once the write is done and came back OK I am trying to do a ReadFile >>> >>> IoctlResult = ReadFile(hDevice, myBuf, outBufSize, &ReturnedLength, >>> NULL); >>> >>> This ReadFile sometimes never comes back. >>> >>> but it works on other times. >>> >>> As you can see in the case that it is not working the printer sends the >>> >>> result immediately (300 ms) but the PC never reads it and is continuing >>> to >>> >>> read which gets NAK'ed out. >>> >>> What can I do? >>> >>> This happens in the Language Monitor during boot time, can it be that >>> >>> Windows is flushing the buffer inadvertainly and that is messing me up? >>> Can >>> >>> I control this somehow? >>> >>> Thanks for your help, >>> >>> \Manfred >>> >>> ""Martin Borve [MSFT]"" <martinbo(a)online.microsoft.com> wrote in message >>> news:KTz7GVfoFHA.944(a)TK2MSFTNGXA01.phx.gbl... >>>> Manfred, >>>> >>>> I assume you are using the standard USBPRINT driver that ships in >>>> Windows >>>> for your printer, correct? >>>> >>>> In that case, USBPRINT will simply submit an async (bulk or interrupt) >>>> request to the device. If this request is not completing, it's likely >>>> that >>>> the device is simply NAKing the transfer request. You can use a bus >>>> analyzer such as a CATC to verify this. >>>> >>>> >>>> Martin Borve >>>> Windows DDK Support >>>> This posting is provided "AS IS" with no warranties, and confers no >>>> rights. >>>> >>>> >>> >>> >> >> >> > > > > > Thank you, > Bobby Mattappally > Microsoft > > This posting is provided "AS IS" with no warranties, and confers no > rights. >
First
|
Prev
|
Pages: 1 2 3 Prev: Please HELP - Analyzing IRQL_NOT_LESS_OR_EQUAL Next: PcCardConfig M Option |