Isochronous IN problem
Locked
12
12
 
|
|
|
|
|
|
|
|
|
|
|
|
|
On 11/27/2011 6:03 AM, Ekkehard wrote:
> Xiaofan Chen wrote >> Travis will be able to give you more details about the limitations of >> libusb-win32 >> in terms of high speed isochronous transfer. >> > Is Travis reading this thread? > Yes. I was only away for the holidays. ;) > Xiaofan Chen wrote >> One of the motivation to move to libusbK (based on KMDF) is to improve >> the isochronous transfer. >> > Sure, because it's not really working with LibUSB Win32 > > > Xiaofan Chen wrote >> Good to hear that it works for some cases. But for 45Mbit/sec, I think >> libusbK should able to work. What is the problem you are having? >> Are you using the libusb-win32 API or the libusbK API? >> > For the quick check with libusbK, I simply installed the new generated > driver, and left my SW unchanged. The major problem is that the data becomes > corrupted, when the data rate is higher than 10MBit/s. your are using the async API and always have 2 or more transfers pending. Make sure your test application is not writing gobs of text to std. Using an AVR UC3 Xplained demo board, We can sustain extremely high data rates. > With an unchange > LibUsb-Win32 this occours every time (my minimum data rate is 6-8MBit/s). > As explained above it is not easy to guess where valid packets are placed by > the driver in the transfer buffer. Using these basic transfer functions, libusbK.sys should be packing the valid bytes to the front of the transfer buffer. i.e. When the reap function returns the length, indexes 0 thru transferLength-1 contain your valid data. As you have noted, this is not necessarily true for libusb0.sys. Instead the data remains indexed in packet frames and you have no way of knowing which parts of the transfer buffer are valid. libusb-win32 does transfer splitting in the dll (libusb0.dll). This does not really work for ISO pipes on transfers larger than 64k (hard coded) because it waits for each batch to complete before submitting the next. i.e. There must always be multiple pending transfer requests. > I fill the buffer prior to the query with > $FF and my packets are clear to identify. But depending on the requested > size, one specific address becomes damaged. > > I am now busy to understand the native libusbK interface. Unfortunally there > exists no Delphi (Pascal) port, and the header file is huge, so I am > porting, and porting, ... on a lazy sunday afternoon :-) > Yes, There are C# and vb.net ports but no pascal yet. At any rate, I hope you will send me your codes when your done. I would like to include your pascal port in the distribution packages. If you run in to problems let me know. libusbK is in beta so I am still able to make public api changes. (not for much longer though) Reflector can auto-generate delphi code from .NET, but I'm not sure if it is any good. I've attached it, but if you want to use any of it, let me know and I will re-generate everything from the most up-to-date libusbK header files. Regards, Travis ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Libusb-win32-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel |
libusbK_delphi.txt (53K) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Loading...
| Powered by Nabble | Edit this page |