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
libusb_bulk_transfer.
Which bus analyser are you using? Can you expand the transfers and see
the timing of individual packets for that transfer?
If the host isn't sending a ZLP then the bus analyser (or it's software)
might be grouping all 4 out data packets into the same transfer as it
has no way of knowing that they were separate transfers.
Regards,
Toby
OK, I feel better, stupid, but better...
I'm using Ellisys Visual USB, I had transfer grouping turned on in the trace
display.
I assumed they would still be in chronological order. Looking closer at the
packet
times, I get:
OUT 512B
OUT 512B
IN 16B
OUT 512B
OUT 512B
IN 16B
Just as I sent them in my test code.
So the out-of-order mystery is solved because they aren't actually
out-of-order. Now
I just need to figure out how to inject a ZLP so my device will recognize the
transfers as complete.
Any advice on how to proceed?
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/en-us/library/windows/hardware/ff728833(v=vs.85).aspx
<http://msdn.microsoft.com/en-us/library/windows/hardware/ff728833%28v=vs.85%29.aspx>
This comes from
https://github.com/libusbx/libusbx/commit/578c50c99646e5ebbcfbea653524a519b843ebcd
but that's really just a move of code submitted here:
https://github.com/libusbx/libusbx/commit/9a4249f8a104b98a15a7e3ba7ecae9a385ed9027
So it looks like the Windows backend has always done it.
Some further reading which might help:
https://sourceforge.net/mailarchive/message.php?msg_id=28120716
https://sourceforge.net/mailarchive/message.php?msg_id=25571546
Linux does support control of if the zero length packet is sent:
https://github.com/libusbx/libusbx/blob/master/libusb/os/linux_usbfs.c#L1699
I was going to create a quick patch for this, but it's harder than it
first looks because the policy for WinUSB is per pipe, but on Linux it's
per URB.
Regards,
Toby
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
