Hi Tim,
Sorry for the delay in the replay was on something else ;)
On 2012-07-24, at 12:41 PM, Tim Roberts wrote:
> Kevyn-Alexandre Paré wrote:
>> Here's the code and output of my test. I'm trying to understand what's going
>> wrong! I mean that I'm expecting the callback function "cb_xfr" from my bulk
>> transfer to be called after libusb_submit_transfer is called. I'm
>> communicating to a FPGA through a Cypress USB (FX2) and It's working with
>> the synchronous API but not yet with the Asynchronous one??? I have put the
>> usbmon output that I'm still reading and learning about it. If you see
>> something let me know!
>> ...
>> static int benchmark_in(uint8_t ep)
>> {
>> static uint8_t buf[6] = {0x2,0xa0,0x3c,0x23,0x3,0x0};
>> static struct libusb_transfer *xfr;
>> int num_iso_pack = 0;
>>
>> xfr = libusb_alloc_transfer(num_iso_pack);
>> if (!xfr)
>> return -ENOMEM;
>>
>> libusb_fill_bulk_transfer(xfr, devh, ep, buf,
>> sizeof(buf), cb_xfr, NULL, 0);
>>
>> gettimeofday(&tv_start, NULL);
>> printf("-->SUBMIT length:%d\n", sizeof(buf));
>> return libusb_submit_transfer(xfr);
>> }
>
> When you are doing a bulk IN transfer, you always need to specify a
> buffer that is as large as your endpoint size. Remember that a USB
> device is never told how much data to send. It is merely given a signal
> that says "GO!".
k thx for reminding me this! But in that case I'm sending data, on the endpoint
only for the output to the FPGA. Do I also need to respect that rule?
> At that point, the device has the perfect right to
> send 512 bytes. However, the host controller will only have allocated
> enough bus time for 6 bytes. Your device steps on the next device's
> slot. That's a protocol violation called "babble".
babble, hmm k
Will retry with a fix 512 buffer...
>
>
>> int main(int argc, char **argv)
>> {
>> ...
>> rc = libusb_set_interface_alt_setting(devh, 1, 0);
>
> It is not useful to select an alternate setting unless you have more
> than one. If you only have bulk pipes, then you have no need for
> alternate settings.
hmm will validate this I think I need that...
>
>
>> libusb_clear_halt(devh, 0x06);
>> libusb_clear_halt(devh, 0x88);
>
> Why do you call clear_halt here? In virtually every case, that's
> unnecessary superstition.
This was legacy from a bug we have on OS X! It's true that I don't need that,
thx.
>
> Are you sure your device has queued up data to send? What is it that
> tells your device to put data in the FX2 FIFO?
I at least need to send 2 bytes to the FPGA to receive back a NAK in case of a
bad 2 first bytes. In case of a proper trame this will send a ACK or data
packet. So yes I'm sure.
Thx for the informations.
For know I went back to the synchronous API for libusb that is running inside a
thread and notify my event loop when data is ready! So I know that with the
SYNC API it's working. I just need to properly use the ASYNC API now!
- KA
>
> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> libusbx-devel mailing list
> libusbx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
