On 2013.05.30 14:44, Toby Gray wrote:
> The current libusbx windows backend deliberately turns off sending a ZLP
> at the end of a transfer:
> https://github.com/libusbx/libusbx/blob/master/libusb/os/windows_usb.c#L2651
> It's the disabling of the SHORT_PACKET_TERMINATE:
> http://msdn.microsoft.com
On 29/05/13 18:18, qse drf wrote:
That's the problem. The supposedly synchronous function calls each return
success
as I call them in order: OUT 1KB, IN 16B, OUT 1KB, IN 16B
But the bus trace shows: OUT 2KB, IN 16B, IN 16B
This is the case even if I add a 5 second delay after each call to
libus
>> That's the problem. The supposedly synchronous function calls each return
>> success
>> as I call them in order: OUT 1KB, IN 16B, OUT 1KB, IN 16B
>> But the bus trace shows: OUT 2KB, IN 16B, IN 16B
>> This is the case even if I add a 5 second delay after each call to
>> libusb_bulk_transfer.
>
On 29/05/13 01:17, qse drf wrote:
>
> That's the problem. The supposedly synchronous function calls each return
> success
> as I call them in order: OUT 1KB, IN 16B, OUT 1KB, IN 16B
> But the bus trace shows: OUT 2KB, IN 16B, IN 16B
> This is the case even if I add a 5 second delay after each call
On Tue, 28 May 2013, qse drf wrote:
> > It's still hard for me to figure out understand how this could happen.
> > If you don't SEND the second buffer until you have RECEIVED the first
> > result, how could you even get the first result unless the first buffer
> > was already gone?
>
> That's the
>>> WinUsb_GetAssociatedInterface should be the magic you need.
>> Thanks, I'll try that.
That was what I was missing! The call didn't appear any where in the
Microsoft example. Thanks!
> I'm also curious with the results you'll get from bypassing libusbx
> altogether.
I implemented my test wi
On 2013.05.29 01:17, qse drf wrote:
>> WinUsb_GetAssociatedInterface should be the magic you need.
> Thanks, I'll try that.
I'm also curious with the results you'll get from bypassing libusbx
altogether.
As you may expect, the fact that you seem to be seeing the same
behaviour with very differe
>> I checked the inf created by Zadig, and it claims the entire device. I
>> assumed this had to be the case, since libusbx is able to acces both
>> interfaces.
>
> You can modify that INF...
But it works as-is with libusbx.
>
>> I'm going to keep trying to figure out how to use WinUSB directly.
>
qse drf wrote:
> I checked the inf created by Zadig, and it claims the entire device. I
> assumed this had to be the case, since libusbx is able to acces both
> interfaces.
You can modify that INF...
> I'm going to keep trying to figure out how to use WinUSB directly.
WinUsb_GetAssociatedInter
>>> So this seems like a bug in libusbx that it doesn't seem to honor the
>>> synchronous API expectations in this case, as evidenced by the
>>> concatenating of the
>>> buffers from multiple calls. Or am I missing something?
>>
>> Can you try using the libusb-win32 or libusbK driver instead of Wi
>> So this seems like a bug in libusbx that it doesn't seem to honor the
>> synchronous API expectations in this case, as evidenced by the concatenating
>> of the
>> buffers from multiple calls. Or am I missing something?
>
> Can you try using the libusb-win32 or libusbK driver instead of WinUSB?
On 2013.05.25 02:33, qse drf wrote:
> So this seems like a bug in libusbx that it doesn't seem to honor the
> synchronous API expectations in this case, as evidenced by the concatenating
> of the
> buffers from multiple calls. Or am I missing something?
Can you try using the libusb-win32 or libu
>> I just installed the driver with Zadig. Yes there are two interfaces,
>> interface 0 has a single endpoint and interface 1 has the two bulk end
>> points. What confused me was that using libusbx I am able to use the
>> bulk endpoints, but with the WinUSB API I can't.
>
> I don't know how Zadig
qse drf wrote:
> I just installed the driver with Zadig. Yes there are two interfaces,
> interface 0 has a single endpoint and interface 1 has the two bulk end
> points. What confused me was that using libusbx I am able to use the bulk
> endpoints, but with the WinUSB API I can't.
I don't know
> Well, wait a minute here. If you are waiting for the "bulk in" in the
> middle, how could you possibly get the sequence you just described?
> You wouldn't even send the second 1KB until you'd read the first
> response. Are you sending the two "bulk out" calls consecutively,
> without waiting for
qse drf wrote:
>
> I am trying to communicate with a device via a simple bulk transfer
> protocol under 64-bit Win7, it doesn't require high bandwidth. I
> don't have access to to the device firmware, but I know it is working
> properly because I have some software that communicates with it
> co
16 matches
Mail list logo
