|
From: geo <sha...@ya...> - 2012-11-14 10:05:26
|
Hi all, Thanks for all the ideas, Here are my comments, tried to do this in a single email @Alan Stern >Are you careful to submit new requests as old ones complete? That is, >do you make sure the request pipeline never empties out? Yes, in the rx callback ( cb_xfr ) I submit each time a new transfer, 8/16Kbytes in size. I'm using sam3u_benchmark.c as starting example, libusb async API @Alan Stern >> I do not know the cause of close to 19 transfers per frame instead of close to 33 transfers / frame. >> Is it possible that if I leave only 2 bulk endpoint 1in and 1out that I will get the full bandwidth on one endpoint ? >Do you use all four endpoints? From your description above, it sounds >like you use only one of them. Endpoints that aren't used won't steal >any bandwidth. 2 bulk endpoints + 1interrupt are used for a CDC console 2 bulk endpoints are used for real time data, my problem is the direction from uC -> PC. please see the descriptor below @Tim Roberts > Are you quite sure your endpoint descriptors show 32 bytes and not 64? Yes, please see the full descriptor below. @Tim Roberts >How is the endpoint buffer filled? In a single-buffered device, you >can't put more data into the device's FIFO while it is writing data out >to the USB. That means after a packet is sent, there will be a delay >while the FIFO fills again. You probably need to sketch out the >timeline at a microscopic level. It takes 20µs to send 32 bytes out to >USB. If it takes 20µs to refill your FIFO, then that's the problem -- >you're only getting a 50% duty cycle. The endpoints are filled on the USB TX ISR with EP transfer re-enabled at the end of isr. Too bad I do not have access to an USB analyzer ... I tried to measure the USB TX ISR length ... Here is what I got with a logic analyzer and gpio debug ... 10.63us 10.63us __________ __________ | | | | ^ | ^ | | | | | _______________| |_____________________________| |______ | | A B figure looks good on plain editor ... sorry for the mess The USB TX ISR is always 10.63us, less than 20us ... The distance between the rising edges ( distance between points A and B in the figure ) is always one of these 3 values: 73us, 52us, 113us I do not understand the source of this variation ... From the figure looks like there is enough room for more transfers but in 1ms I only get 16 or 17 transfers ( corresponding to 512kB/s or 544kB/s ) and this is correlated with the average transfer of about 520kB/s that can be seen on host. >You MIGHT be able to overcome this by using two bulk pipes in a >ping-pong scheme, so one can empty while the other fills, but then you >have the problem of reconstructing those packets in the application. Nice idea, I will do this if nothing else helps. There will be a problem with reconstruction of data on host. I think that I need to sacrifice 1 bytes on each 32byte buffer as index in order to reorder the data, I do not expect the delay between endpoints to be more than 256. Any other ideas on this @Peter Stuge >> with usb1.1 >Note that USB 1.1 is *NOT* the same thing as "a full speed device". >This is an amazingly common mistake. USB 2.0 devices may only do low >speed or full speed. >In fact, I expect that this is the case for the vast majority of low >and full speed USB peripherals found in todays microcontrollers. The device registers as usb full speed device on linux. I can achieve 500kbytes/second , I do not think this is possible with a low speed device. >> I will be happy with any sw patch if possible, uC code, libusb, >> kernel patch ... >I think you'll have to fix the real problem rather than look for a >random patch to cover it up with. :\ By "patch" I mean I'm open to make any change to uC SW, libusb or linux kernel that will fix the real problem Thanks for your time and comments, George --------------------------- Below is the usb descriptor for this device : lsusb -vvv EP 3,4,10 are used for a CDC console EP 1,2 are used for data, EP 2 is the one used to get the data out of uC Bus 002 Device 008: ID 1234:5678 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 2 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x1234 idProduct 0x5678 bcdDevice 0.01 iManufacturer 1 A iProduct 2 B iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 90 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 10mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 5 Console CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x01 call management bDataInterface 1 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface 0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8a EP 10 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 42 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 5 Console Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 6 Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Device Status: 0x0001 Self Powered |