On Wed, September 25, 2013 11:23 am, Pete Batard wrote:
> On 2013.09.21 00:21, Kano wrote:
>> Hi,
>> I've been using usb for about a year on many devices but only using a
>> single interface.
>> Finally got some hardware that has 2 interfaces and the code I've
>> written
>> works on linux but fails on windows.
>> Anyone know if there are special rules required for windows?
>
> Please have a look at the xusb sample. Especially, if you replace the
> VID:PID for the -j option for the ones of your device, and for a device
> with 2 interfaces, you should get something like:
> --------------------------------------------------------------------------
> D:\libusbx\Win32\Debug\examples>xusb -j
Testing now - yes for me xusb claims and releases all 4 interfaces also
I checked the code, and see that it uses the same handle for all 4
interfaces
My question then I guess is: how do you do bulk transfers (read and write)
to all 4 interfaces? The method I use on Linux, fails on windows.
A control transfer is no problem since you effectively specify the
interface, but how do you do a bulk transfer?
In my linux code (which does work - it's been running for many days doing
I/Os non stop - at least 10 per second each, randomly, to all 4 interfaces)
To setup:
I open a handle then claim the interface 0 (as stated before)
Then I open a second handle and claim interface 1 on the 2nd handle
('claim' requires a handle)
... interface 2
... interface 3
Bulk I/O to the first handle successfully uses interface 0
Bulk I/O to the second handle successfully uses interface 1
...
...
I have 4 threads - each has it's own handle to talk to the interface it
is given.
Here's xusb
$ xusb 0403:8350
Using libusbx v1.0.17.10830
Opening device 0403:8350...
Reading device descriptor:
length: 18
device class: 0
S/N: 3
VID:PID: 0403:8350
bcdDevice: 0800
iMan:iProd:iSer: 1:2:3
nb confs: 1
Reading BOS descriptor: no descriptor
Reading first configuration descriptor:
nb interfaces: 4
interface[0]: id = 0
interface[0].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: FF.FF.FF
endpoint[0].address: 81
max packet size: 0200
polling interval: 00
endpoint[1].address: 02
max packet size: 0200
polling interval: 00
interface[1]: id = 1
interface[1].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: FF.FF.FF
endpoint[0].address: 83
max packet size: 0200
polling interval: 00
endpoint[1].address: 04
max packet size: 0200
polling interval: 00
interface[2]: id = 2
interface[2].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: FF.FF.FF
endpoint[0].address: 85
max packet size: 0200
polling interval: 00
endpoint[1].address: 06
max packet size: 0200
polling interval: 00
interface[3]: id = 3
interface[3].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: FF.FF.FF
endpoint[0].address: 87
max packet size: 0200
polling interval: 00
endpoint[1].address: 08
max packet size: 0200
polling interval: 00
Claiming interface 0...
Claiming interface 1...
Claiming interface 2...
Claiming interface 3...
Reading string descriptors:
String (0x01): "FTDI"
String (0x02): "Cairnsmore1"
String (0x03): "FTVJXSG1"
Releasing interface 0...
Releasing interface 1...
Releasing interface 2...
Releasing interface 3...
Closing device...
> --------------------------------------------------------------------------
>> Of course I'm using Zadig to set the windows driver to WinUSB.
>
> And your driver installation looks OK to me.
>
>> The first interface open is of course working.
>>
>> The code is basically:
>> For a single interface chip (that always works on many linux/windows) it
>> is:
>> libusb_get_device_list
>> libusb_get_device_descriptor
>> libusb_open
>> libusb_claim_interface 0
>>
>> Instead for a chip with multiple interfaces I am:
>> libusb_get_device_list
>> libusb_get_device_descriptor
>> libusb_open
>> libusb_claim_interface 0
>> libusb_get_device(interface 0 handle)
>> libusb_open
>> (libusb_claim_interface 1) <- never gets here
>
> I'd have to look at the code, but I seem to recall that we are trying to
> mimic Linux here and, despite having separate drivers installed for each
> interface (and the underlying OS seeing these as separate devices)
> pretend it is still a single device. Therefore, I agree with Xiaofan
> down below, and don't believe you should be attempting to open what is
> essentially the same device, as far as libusb is concerned, twice.
> Does the code above with the double open work on Linux?
Yes it works fine on linux - the failure is when I run the same libusb
calls on windows
As mentioned before, I also tried doing them in a different order,
Interface 1, then Interface 0 ...
Interface 1 succeeded, then the 2nd open failed (before claiming 0)
>> This works on linux but fails on windows on the 2nd open (before
>> claiming
>> the 2nd interface) with:
>> [ 1.209821] [00000f94] libusbx: debug [libusb_open] open 2.2
>> [ 1.209821] [00000f94] libusbx: error [winusbx_open] could not open
>> device
>> \\.\USB#VID_0403&PID_8350&MI_00#6&2CE4DD9F&0&0000#{C8D1AB34-4B5C-488A-8194-08C26C1A05DA}
>> (interface 0): [5] Access is denied.
>
> Access denied is pretty much what I'd expect if the above is correct.
> Please try to write your code as if you were dealing with a single
> device, instead of two, and see if that help.
>
> Regards,
>
> /Pete
-Thanks
-Kano
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
