Re: [Libusb-devel] Using control end-point to send data

[Tim R. <ti...@pr...>]

Ali Asad wrote:
> Now to make is ecstatic, perhaps you can give me some pointers on why reading data from interrup endpoint is not working as expected.
>
> Here is the dataflow from a single threaded application.
>
> 1. Linux host sends HID report to control end-point on device
> 2. the device responds with 14 bytes of data
> 3. Linux host sends another Hid report to control end-point on device
> 4. the device responds with 19 bytes of data
>
> >From the USB bus analyser, I see that all these data are transmitted and ACK'd correctly.
>
> To read data in step 2 and 4, I make a call to
>
> char bytes[128]
> int ep = 0x04;
>   

Should be 0x84 for an input pipe, although since you're using the old
0.1 library, it handles that for you.

> rv = usb_interrupt_read(dev_handle, ep, bytes, 14, 5000);
> and
> rv = usb_interrupt_read(dev_handle, ep, bytes, 19, 5000);
> respectively.
>
> In both cases the return value is 0, indicating that it did not read any data.
>   

Generally, you'll want to submit the read request to match the packet
size of your interrupt endpoint.  Remember that the device is not told
how much data you want.  It's just told "GO".  It sends whatever it has
to send, up to the max packet size.  If you ask for 14 bytes, the host
controller only allows room for 14 bytes.  If device sends 15, that's
called "babble", and it can actually interfere with succeeding
transactions on the bus.

> Howerver, for the first call to usb_interrupt_read() if I look into the buffer 'bytes' it does have the expected 14 bytes from device. So I did receive the data even though the return value is 0. The second call to usb_interrupt_read() does not put the new 19 bytes in the buffer, but returns the same 14 bytes from the first call.
>   

Hmmm.  Sounds like it might be necessary to trace into the libusb code
and figure out who is confused here.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.