WinUsb timing issue
in [Device Drivers]
|
From: Steve on 3 Dec 2009 19:11 Kenneth, Your post almost exactly describes what I am experiencing. I have been fighting this problem for a couple of days now to no avail. Did you find a solution? /Steve Kenneth Adelhorst Andersen wrote: WinUsb timing issue 25-Nov-09 Hi, We are trying to use WinUsb to communicate with our own hardware device. However, we are experiencing strange timing issues, where regularly the driver fails to retrieve the reply from the hardware device. The same code works fine with another driver, which is just a build of the bulk USB driver sample from the DDK. One difference between the two drivers is that WinUsb requires the handle to be created with the FILE_FLAG_OVERLAPPED attribute, while the other driver is not. This sounds like a good reason that we would get these timing issues, because that allowes multiple simultaneous pending read and write requests, but in our case we never make a new WinUsb_WritePipe() or WinUsb_ReadPipe() call before the previous one is complete. We are doing synchronous calls only. Seen from the application side, the WinUsb_ReadPipe() call just fails and GetLastError() returns 121, which is semaphore timeout, so I guess the request just times out. Any ideas as to what we can do differently or try to make the communcation stable with WinUsb? If you need additional information about our setup etc, please let me know :) /Kenneth Previous Posts In This Thread: Submitted via EggHeadCafe - Software Developer Portal of Choice ASP.NET Application-Page Lifecycle Redux http://www.eggheadcafe.com/tutorials/aspnet/98d177b4-c422-4a1d-90ab-50e54bcbc010/aspnet-applicationpage.aspx
From: Kenneth Adelhorst Andersen on 4 Dec 2009 04:29 Hi Steve, I'm not sure I would say that I've solved the problem, but I've found a workaround anyway... It turns out that instead of letting WinUsb split up the packages into 64 byte slices (which is the package size of the USB standard), if I split up the packages myself and never send anything bigger than 64 bytes to WinUsb, I don't get these timeout issues. I suspect that this is because the WinUsb driver uses overlapped I/O, so maybe it will actually make simulatenous concurrent requests to the device, if I pass it a big package, and my device is probably not capable of handling that correctly. Having said that, I still have some timing issues left in other cases, but I can easily retry my way out of these. I don't think we'll have time to figure out these last issues, since they do not appear to be show stoppers. Hope this helps, /Kenneth "Steve Floyd" wrote: > Kenneth, > > Your post almost exactly describes what I am experiencing. > > I have been fighting this problem for a couple of days now to no avail. > > Did you find a solution? > > /Steve > > > > Kenneth Adelhorst Andersen wrote: > > WinUsb timing issue > 25-Nov-09 > > Hi, > > We are trying to use WinUsb to communicate with our own hardware device. > However, we are experiencing strange timing issues, where regularly the driver > fails to retrieve the reply from the hardware device. > > The same code works fine with another driver, which is just a build of the > bulk USB driver sample from the DDK. > > One difference between the two drivers is that WinUsb requires the handle to > be created with the FILE_FLAG_OVERLAPPED attribute, while the other driver is > not. This sounds like a good reason that we would get these timing issues, > because that allowes multiple simultaneous pending read and write requests, > but in our case we never make a new WinUsb_WritePipe() or WinUsb_ReadPipe() > call before the previous one is complete. We are doing synchronous calls only. > > Seen from the application side, the WinUsb_ReadPipe() call just fails and > GetLastError() returns 121, which is semaphore timeout, so I guess the > request just times out. > > Any ideas as to what we can do differently or try to make the communcation > stable with WinUsb? > > If you need additional information about our setup etc, please let me know :) > > /Kenneth > > Previous Posts In This Thread: > > > Submitted via EggHeadCafe - Software Developer Portal of Choice > ASP.NET Application-Page Lifecycle Redux > http://www.eggheadcafe.com/tutorials/aspnet/98d177b4-c422-4a1d-90ab-50e54bcbc010/aspnet-applicationpage.aspx > . >
From: Doron Holan [MSFT] on 4 Dec 2009 13:06 winusb does not split transfers up into max packet sized transfers, the underlying usb host controller does that. winusb just sends the entire buffer as is to the device d -- This posting is provided "AS IS" with no warranties, and confers no rights. "Kenneth Adelhorst Andersen" <morpheus(a)nospam.dk> wrote in message news:F515D4E9-BD1E-4D79-BBB3-6CB78ED2679E(a)microsoft.com... > Hi Steve, > > I'm not sure I would say that I've solved the problem, but I've found a > workaround anyway... It turns out that instead of letting WinUsb split up > the > packages into 64 byte slices (which is the package size of the USB > standard), > if I split up the packages myself and never send anything bigger than 64 > bytes to WinUsb, I don't get these timeout issues. > > I suspect that this is because the WinUsb driver uses overlapped I/O, so > maybe it will actually make simulatenous concurrent requests to the > device, > if I pass it a big package, and my device is probably not capable of > handling > that correctly. > > Having said that, I still have some timing issues left in other cases, but > I > can easily retry my way out of these. I don't think we'll have time to > figure > out these last issues, since they do not appear to be show stoppers. > > Hope this helps, > /Kenneth > > > > "Steve Floyd" wrote: > >> Kenneth, >> >> Your post almost exactly describes what I am experiencing. >> >> I have been fighting this problem for a couple of days now to no avail. >> >> Did you find a solution? >> >> /Steve >> >> >> >> Kenneth Adelhorst Andersen wrote: >> >> WinUsb timing issue >> 25-Nov-09 >> >> Hi, >> >> We are trying to use WinUsb to communicate with our own hardware device. >> However, we are experiencing strange timing issues, where regularly the >> driver >> fails to retrieve the reply from the hardware device. >> >> The same code works fine with another driver, which is just a build of >> the >> bulk USB driver sample from the DDK. >> >> One difference between the two drivers is that WinUsb requires the handle >> to >> be created with the FILE_FLAG_OVERLAPPED attribute, while the other >> driver is >> not. This sounds like a good reason that we would get these timing >> issues, >> because that allowes multiple simultaneous pending read and write >> requests, >> but in our case we never make a new WinUsb_WritePipe() or >> WinUsb_ReadPipe() >> call before the previous one is complete. We are doing synchronous calls >> only. >> >> Seen from the application side, the WinUsb_ReadPipe() call just fails and >> GetLastError() returns 121, which is semaphore timeout, so I guess the >> request just times out. >> >> Any ideas as to what we can do differently or try to make the >> communcation >> stable with WinUsb? >> >> If you need additional information about our setup etc, please let me >> know :) >> >> /Kenneth >> >> Previous Posts In This Thread: >> >> >> Submitted via EggHeadCafe - Software Developer Portal of Choice >> ASP.NET Application-Page Lifecycle Redux >> http://www.eggheadcafe.com/tutorials/aspnet/98d177b4-c422-4a1d-90ab-50e54bcbc010/aspnet-applicationpage.aspx >> . >>
From: Morpheus on 4 Dec 2009 17:32 On Dec 4, 7:06 pm, "Doron Holan [MSFT]" <doron.ho...(a)online.microsoft.com> wrote: > winusbdoes not split transfers up into max packet sized transfers, the > underlying usb host controller does that. winusbjust sends the entire > buffer as is to the device > > d > > -- > > This posting is provided "AS IS" with no warranties, and confers no rights. > > "Kenneth Adelhorst Andersen" <morph...(a)nospam.dk> wrote in messagenews:F515D4E9-BD1E-4D79-BBB3-6CB78ED2679E(a)microsoft.com... > > > Hi Steve, > > > I'm not sure I would say that I've solved the problem, but I've found a > > workaround anyway... It turns out that instead of lettingWinUsbsplit up > > the > > packages into 64 byte slices (which is the package size of the USB > > standard), > > if I split up the packages myself and never send anything bigger than 64 > > bytes toWinUsb, I don't get these timeout issues. > > > I suspect that this is because theWinUsbdriver uses overlapped I/O, so > > maybe it will actually make simulatenous concurrent requests to the > > device, > > if I pass it a big package, and my device is probably not capable of > > handling > > that correctly. > > > Having said that, I still have sometimingissues left in other cases, but > > I > > can easily retry my way out of these. I don't think we'll have time to > > figure > > out these last issues, since they do not appear to be show stoppers. > > > Hope this helps, > > /Kenneth > > > "Steve Floyd" wrote: > > >> Kenneth, > > >> Your post almost exactly describes what I am experiencing. > > >> I have been fighting this problem for a couple of days now to no avail.. > > >> Did you find a solution? > > >> /Steve > > >> Kenneth Adelhorst Andersen wrote: > > >>WinUsbtimingissue > >> 25-Nov-09 > > >> Hi, > > >> We are trying to useWinUsbto communicate with our own hardware device. > >> However, we are experiencing strangetimingissues, where regularly the > >> driver > >> fails to retrieve the reply from the hardware device. > > >> The same code works fine with another driver, which is just a build of > >> the > >> bulk USB driver sample from the DDK. > > >> One difference between the two drivers is thatWinUsbrequires the handle > >> to > >> be created with the FILE_FLAG_OVERLAPPED attribute, while the other > >> driver is > >> not. This sounds like a good reason that we would get thesetiming > >> issues, > >> because that allowes multiple simultaneous pending read and write > >> requests, > >> but in our case we never make a new WinUsb_WritePipe() or > >> WinUsb_ReadPipe() > >> call before the previous one is complete. We are doing synchronous calls > >> only. > > >> Seen from the application side, the WinUsb_ReadPipe() call just fails and > >> GetLastError() returns 121, which is semaphore timeout, so I guess the > >> request just times out. > > >> Any ideas as to what we can do differently or try to make the > >> communcation > >> stable withWinUsb? > > >> If you need additional information about our setup etc, please let me > >> know :) > > >> /Kenneth > > >> Previous Posts In This Thread: > > >> Submitted via EggHeadCafe - Software Developer Portal of Choice > >> ASP.NET Application-Page Lifecycle Redux > >>http://www.eggheadcafe.com/tutorials/aspnet/98d177b4-c422-4a1d-90ab-5.... > >> . Aha, interesting...do you think it could be because the WinUsb driver is using overlapped I/O and hence uses the controller in another way than our proprietary driver does? /Kenneth
From: Tim Roberts on 6 Dec 2009 00:02 Morpheus <adelhorst(a)gmail.com> wrote: >On Dec 4, 7:06�pm, "Doron Holan [MSFT]" ><doron.ho...(a)online.microsoft.com> wrote: >> winusbdoes not split transfers up into max packet sized transfers, the >> underlying usb host controller does that. �winusbjust sends the entire >> buffer as is to the device Overlapped I/O makes no difference at all at the device level. All requests to a single endpoint are always serialized. The only thing that overlapped I/O changes is that you have another request ready to go just as soon as the first request completes, rather than waiting for a round trip. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
|
Pages: 1 Prev: Winusb composite device Next: CM_ENABLE_DEVNODE/CM_DISABLE_DEVNODE |