Menu
▾
▴
libusb-win32-devel
|
From: Ekkehard <edo...@ad...> - 2011-11-24 13:12:30
|
Hello,
still not perfectly working my isochronous IN transfer.
The current problem is that usb_reap_async returns very fast and returns
length of data which is much too small (eg. 8K instead of 64K)
My approach is in a thread and the functions works as follow (psedo-code,
catching errors not shown)
BufCount = 8;
TSEndPoint = $84;
PacketSize = 5*188;
QueryReadCount = 64*PacketSize;
for i := 0 to BufCount-1
usb_isochronous_setup_async(FDeviceHandle, pcontexts[i], TSEndPoint,
PacketSize);
for i := 0 to BufCount-1
usb_submit_async(pcontexts[i], @(bufs[i,0]), QueryReadCount);
while not Terminated {
for i := 0 to BufCount-1 {
len := usb_reap_async(pcontexts[i], FTimeOutMs);
if len > 0
ProcessData(xxx)
usb_submit_async(pcontexts[i], @bufs[i,0], QueryReadCount);
}
}
If I use a USB logger (like SnoopyPro), than I can see that the USB
Isochronous transfer, contains 64 packets with PacketSize data, contiously
filled with the expected data, but in the program len indicates usually less
than 10 packets.
I have to use isochronous transfer.
Any ideas?
Best regards
Ekkehard
--
View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5020128.html
Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.
|
|
From: Ekkehard <edo...@ad...> - 2011-11-25 12:28:49
|
Some news on the problem.
I filled the transfer buffer prior the call of usb_submit_async with 0xFF,
and found that the driver scatter the received data in the whole buffer. The
length returned by usb_reap_async is the netto sum of received data. These
amount of bytes are now laying in the buffer, but where? I logged the
transfer in parallel with USB SnoopyPro and found that the data are well
organized in offset and length.
Example: you have a Packetsize of 1024 and a Buffer size of 4 Packets (4096
bytes in total), and the device has not so much data to send, so it fills
the transfered Packets only half than your usb_reap_async returns 2048 but
the data may be organized as follow
Address Content ("xx" = 256 bytes of unchanged data, "data" 256 bytes
received data
0000 xx
0100 data
0200 data
0300 xx
0400 data
0500 xx
0600 data
0700 xx
0800 xx
0900 xx
0A00 data
0B00 data
0C00 xx
0D00 data
0E00 xx
0F00 data
So you see 8*256 bytes received data = 2048. Unfortunally if your data are
not different from the "underground" you can not identify (Of course the
data is alligned to the packetsize which is helpful)
So the questions to the developers, where can I access the list of received
bytes and there location?
Best regards and have a nice weekend
Ekkehard
--
View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5022681.html
Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.
|
|
From: Ekkehard <edo...@ad...> - 2011-11-25 14:06:27
|
Bad news, something still not working. I am able to locate my data, but if the scattered data is located on a specific address in the buffer, the values are corrupted. In parallel the SnoopyPro shows uncorrupted data. I am near to thingk, that I am the first person who uses this isochronous stuff under Windows. Ekkehard -- View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5022863.html Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
|
From: Xiaofan C. <xia...@gm...> - 2011-11-25 16:32:05
|
On Friday, November 25, 2011, Ekkehard <edo...@ad...> wrote: > Bad news, something still not working. I am able to locate my data, but if > the scattered data is located on a specific address in the buffer, the > values are corrupted. In parallel the SnoopyPro shows uncorrupted data. > I am near to thingk, that I am the first person who uses this isochronous > stuff under Windows. Is this a high speed USB device? Libusb-win32 may not work well for high speed isochronous device. You might try libusbk.sys and see if that helps, just change the driver without changing your device first. Or you can look at the native libusbk API. libusbk website: http://code.google.com/p/usb-travis/ -- Xiaofan |
|
From: Ekkehard <edo...@ad...> - 2011-11-26 13:35:09
|
Yes it is an high-speed device, and I want to reach rougly 45MBit/s transferrate. I am not amused to hear, that this LibUSB Win32, will not work. Esspecially at this stage of development, but thats "open source" :-) I tested your approach with libusbK and this stuff changes something, but is (using the same API) not the final solution. For example the buffer could now increaded above 64K. For lower data rates (less than 10MBit/s) the stuff is working (in High-Speed Mode). Thanx. Ekkehard -- View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5024861.html Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
|
From: Xiaofan C. <xia...@gm...> - 2011-11-27 02:11:33
|
On Sat, Nov 26, 2011 at 9:35 PM, Ekkehard <edo...@ad...> wrote: > Yes it is an high-speed device, and I want to reach rougly 45MBit/s > transferrate. That should be possible. > I am not amused to hear, that this LibUSB Win32, will not work. Esspecially > at this stage of development, but thats "open source" :-) Travis will be able to give you more details about the limitations of libusb-win32 in terms of high speed isochronous transfer. One of the motivation to move to libusbK (based on KMDF) is to improve the isochronous transfer. > I tested your approach with libusbK and this stuff changes something, but is > (using the same API) not the final solution. > For example the buffer could now increaded above 64K. For lower data rates > (less than 10MBit/s) the stuff is working (in High-Speed Mode). 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? -- Xiaofan |
|
From: Ekkehard <edo...@ad...> - 2011-11-27 14:03:12
|
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? 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. 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. 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 :-) Best regards Ekkehard -- View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5026500.html Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
|
From: Travis <lib...@gm...> - 2011-11-27 17:22:05
Attachments:
libusbK_delphi.txt
|
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 data rate should not be limited in any way by libusbK. Make sure 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 |
|
From: Ekkehard <edo...@ad...> - 2011-11-27 18:50:27
|
Hello Travis, just short, because I am late and have to run home. I will give you some code, as soon as it runs. Thanx for the header translation, I will take a look, but I have translated a lot of stuff so far. Probably I have to ask you several things - but not today. BTW I hope you enjoyed your holdays! Greetings Ekkehard -- View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5027009.html Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
|
From: Damos <Dam...@po...> - 2011-11-27 19:05:05
|
Hi ! >----- Original Message ----- >From: Travis >To: lib...@li... >Sent: Sunday, November 27, 2011 6:21 PM >Subject: Re: [Libusb-win32-devel] Isochronous IN problem > > [...] >Using an AVR UC3 Xplained demo board, We can sustain extremely high data >rates. Sorry for the off-topic, is this firmare for UC3 available somwhere? Kind regards ! |
|
From: Travis <lib...@gm...> - 2011-11-28 01:15:25
|
On 11/27/2011 11:05 AM, Damos wrote: > Hi ! > >> ----- Original Message ----- >> From: Travis >> To: lib...@li... >> Sent: Sunday, November 27, 2011 6:21 PM >> Subject: Re: [Libusb-win32-devel] Isochronous IN problem >> >> [...] >> Using an AVR UC3 Xplained demo board, We can sustain extremely high data >> rates. > Sorry for the off-topic, is this firmare for UC3 available somwhere? > Yes, It is the Benchmark firmware for the AVR UC3. You can use it with kBench.exe to run a variety of tests. All endpoint types are supported, but the AVR firmware is focused more on isochronous transfers. http://code.google.com/p/usb-travis/source/browse/#svn%2Ftrunk%2FBmFW%2FAVR%2FASF If you have configuration questions, let me know and I will try to help. Regards, Travis |
|
From: Ekkehard <edo...@ad...> - 2011-11-29 10:47:34
|
Hello Travis, hello Xiaofan, I have done some more investigation in my problem, which also existst with libUsbK. My latest impression is, that the maximum packet size, declared in the descriptor, causes the trouble. To disclose thirdparty problems, I create (or modify) a small firmware for my Cypress FX2 based test board. This firmware does nothing else than prepare the send buffer with some data (marker, packet counter), and arm them as fast as possible. This allows 45..62 MBit/s transfer speed, which is less than expected, but enough for my purpose. If I declare the maximum packet size to 0x400 (1024d) in the decriptor than everything run smooth. The transmitted data seems to be uncorrupted, since the marker are in place and the counters are contious. If I declare the maximum packet size to 0x3AC (940d) in the descriptor, the trouble starts. If I use only less than 320 bytes per packet (roughly 20MBit/s) the stuff is running, if I increase the actual packetsize the data becomes corrupted (overwritten with zeros, 0xFFs or random data). This behaviour is data rate independend, because if I only send larger packets in larger time steps, they are still corrupted. Just to block the question: No I can not change the 940 Byte maximum packet size, since it is fixed in my target device. I become now really desperated, and hope that you can help me. Best regards Ekkehard -- View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5031911.html Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
|
From: Travis <lib...@gm...> - 2011-11-29 13:38:04
|
On 11/29/2011 2:47 AM, Ekkehard wrote: > Hello Travis, hello Xiaofan, > I have done some more investigation in my problem, which also existst with > libUsbK. > My latest impression is, that the maximum packet size, declared in the > descriptor, causes the trouble. > To disclose thirdparty problems, I create (or modify) a small firmware for > my Cypress FX2 based test board. > This firmware does nothing else than prepare the send buffer with some data > (marker, packet counter), and arm them as fast as possible. This allows > 45..62 MBit/s transfer speed, which is less than expected, but enough for my > purpose. Interesting, would this firmware work with this board? http://www.cutedigi.com/product_info.php?products_id=4515 I have one of these but I have never used it. I cannot test this 940 byte packet size with my current hardware so if you could help me get this firmware running on the device above it would help tremendously. > If I declare the maximum packet size to 0x400 (1024d) in the decriptor than > everything run smooth. The transmitted data seems to be uncorrupted, since > the marker are in place and the counters are contious. > > If I declare the maximum packet size to 0x3AC (940d) in the descriptor, the > trouble starts. If I use only less than 320 bytes per packet (roughly > 20MBit/s) the stuff is running, if I increase the actual packetsize the data > becomes corrupted (overwritten with zeros, 0xFFs or random data). This > behaviour is data rate independend, because if I only send larger packets in > larger time steps, they are still corrupted. > What are you using for the transfer size? High speed devices need to transfer packets in intervals of 8; there are other limitations as well. It would help if I could see your PC code. It is okay if it's delphi. > Just to block the question: No I can not change the 940 Byte maximum packet > size, since it is fixed in my target device. > > I become now really desperated, and hope that you can help me. > ISO is one of libusbK's primary functions. Provided hardware is working properly and USB 2.0 high speed rules are not being violated, I'm confident we can resolve your problem. I will wait for your response about my cutedigi board. What we do next will be dependent on that. Regards, Travis |
|
From: Ekkehard <edo...@ad...> - 2011-11-29 16:52:12
|
Hello Travis, the stuff is running! But I dont know why? I believed until a few minutes ago that the size given to UsbK_IsoReadPipe must be multiples of the maximum packet size from the descriptor (and multiples of 8). So I allways used multiples of 940, eg. 64*940. But this seems to be wrong! I also believed that the calls IsoK_Init and IsoK_SetPackets also tied to the maximum packet of the descriptor. But digging around with my test FW, I made a mistake, leaving 1024 bytes as packet size in my Windows program, while having 940 bytes as maximum packet size in the descriptor. And, surprise, it's running!! Honnestly, without this mistake I would not be able to guess this. Greets Ekkehard -- View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5032979.html Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
|
From: Travis <lib...@gm...> - 2011-11-29 21:21:52
|
On 11/29/2011 8:52 AM, Ekkehard wrote: > Hello Travis, > the stuff is running! But I dont know why? Great! Glad you are having success. > I believed until a few minutes ago that the size given to UsbK_IsoReadPipe > must be multiples of the maximum packet size from the descriptor (and > multiples of 8). So I allways used multiples of 940, eg. 64*940. > But this seems to be wrong! It must be large enough to hold the data described by the iso packet descriptors. In your case, this seems mostly correct? The transfer size must be intervals of 8*940. Could you elaborate? > I also believed that the calls > IsoK_Init and IsoK_SetPackets > also tied to the maximum packet of the descriptor. > No. These advanced ISO functions give you full control of the packet descriptors. IsoK_Init() creates a hunk of memory to hold the iso packet descriptors (not the data). IsoK_SetPackets() initializes all iso packets to the same length (specified). > But digging around with my test FW, I made a mistake, leaving 1024 bytes as > packet size in my Windows program, while having 940 bytes as maximum packet > size in the descriptor. > That would certainly cause problems. ;) So, is this correct? you are calling IsoK_Init() with NumberOfPackets=64 IsoK_SetPackets() with PacketSize=940 and using a transfer size of 64*940 in UsbK_IsoReadPipe() Regards, Travis |
|
From: Ekkehard <edo...@ad...> - 2011-11-30 09:01:14
|
Hello Travis,
ok I was too short, here comes everything in detail
1.) Descriptor
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
DLL version: 1.2.5.0
Driver version: 3.0.4.0
bus/device idVendor/idProduct
bus-0/\\.\libusb0-0255--0xXXXX-0xXXXX XXXX/XXXX
- Manufacturer : XXXXXXXXXXXX
- Product : XXXXXXXXXXXX
- Serial Number: XXXXXXXXXXXX
bLength: 18
bDescriptorType: 01h
bcdUSB: 0200h
bDeviceClass: 00h
bDeviceSubClass: 00h
bDeviceProtocol: 00h
bMaxPacketSize0: 40h
idVendor: 2013h
idProduct: 024Fh
bcdDevice: 0100h
iManufacturer: 1
iProduct: 2
iSerialNumber: 3
bNumConfigurations: 1
wTotalLength: 55
bNumInterfaces: 1
bConfigurationValue: 1
iConfiguration: 0
bmAttributes: 80h
MaxPower: 250
bInterfaceNumber: 0
[snip AlternateSetting 0]
bAlternateSetting: 1
bNumEndpoints: 2
bInterfaceClass: 255
bInterfaceSubClass: 0
bInterfaceProtocol: 0
iInterface: 0
bEndpointAddress: 84h
bmAttributes: 01h
wMaxPacketSize: 940
bInterval: 1
bRefresh: 0
bSynchAddress: 0
bEndpointAddress: 85h
bmAttributes: 01h
wMaxPacketSize: 940
bInterval: 1
bRefresh: 0
bSynchAddress: 0
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
2.) Definitions in Windows SW
BufCount = 16;
TSEndPoint = $84;
PacketSize = 1024;
IsoPacketsPerTransfer = 128;
QueryReadCount = IsoPacketsPerTransfer*PacketSize;
3.) Function calls (Delphi/Pascal)
SetLength(myBuffers[i],QueryReadCount); // BufCount buffers
...
IsoK_SetPackets(isoCtxs[i], PacketSize);
...
success := UsbK_IsoReadPipe(usbHandle, TSEndPoint, myBuffers[i][0],
Length(myBuffers[i]), ovlkHandles[i], isoCtxs[i]);
...
success := OvlK_WaitOrCancel(ovlkHandles[i], 1000, transferredLength);
...
// loop through all isoPackets, with Offset and Length
Conclusion:
The maximum packet size "940" in the descriptor is total misleading. It can
probably not work because 940 could not be divided by 8, without remainder.
But 1024 works perfect! All data is alligned, all isoPacket.Offset values
are correct etc.
One other thing, I have seen that you only pass the lower 16bit of the
isoPacket status, this might be a problem because some status are zero in
the lowest 16bit and contain errors
#define USBD_STATUS_CANCELED
((USBD_STATUS)0xC0010000L)
Maybe you can copy the topmost 2 bits of the original status to the bit 15
and 14 of the 16 bit status that you return.
Best regards
Ekkehard
--
View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5035005.html
Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.
|
|
From: Travis <lib...@gm...> - 2011-11-30 14:55:46
|
On 11/30/2011 1:01 AM, Ekkehard wrote: > Hello Travis, > ok I was too short, here comes everything in detail > 1.) Descriptor > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > DLL version: 1.2.5.0 > Driver version: 3.0.4.0 > > bus/device idVendor/idProduct > bus-0/\\.\libusb0-0255--0xXXXX-0xXXXX XXXX/XXXX > - Manufacturer : XXXXXXXXXXXX > - Product : XXXXXXXXXXXX > - Serial Number: XXXXXXXXXXXX > bLength: 18 > bDescriptorType: 01h > bcdUSB: 0200h > bDeviceClass: 00h > bDeviceSubClass: 00h > bDeviceProtocol: 00h > bMaxPacketSize0: 40h > idVendor: 2013h > idProduct: 024Fh > bcdDevice: 0100h > iManufacturer: 1 > iProduct: 2 > iSerialNumber: 3 > bNumConfigurations: 1 > wTotalLength: 55 > bNumInterfaces: 1 > bConfigurationValue: 1 > iConfiguration: 0 > bmAttributes: 80h > MaxPower: 250 > bInterfaceNumber: 0 > [snip AlternateSetting 0] > bAlternateSetting: 1 > bNumEndpoints: 2 > bInterfaceClass: 255 > bInterfaceSubClass: 0 > bInterfaceProtocol: 0 > iInterface: 0 > bEndpointAddress: 84h > bmAttributes: 01h > wMaxPacketSize: 940 > bInterval: 1 > bRefresh: 0 > bSynchAddress: 0 > bEndpointAddress: 85h > bmAttributes: 01h > wMaxPacketSize: 940 > bInterval: 1 > bRefresh: 0 > bSynchAddress: 0 > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > 2.) Definitions in Windows SW > BufCount = 16; > TSEndPoint = $84; > PacketSize = 1024; > IsoPacketsPerTransfer = 128; > QueryReadCount = IsoPacketsPerTransfer*PacketSize; > > 3.) Function calls (Delphi/Pascal) > > SetLength(myBuffers[i],QueryReadCount); // BufCount buffers > ... > IsoK_SetPackets(isoCtxs[i], PacketSize); > ... > success := UsbK_IsoReadPipe(usbHandle, TSEndPoint, myBuffers[i][0], > Length(myBuffers[i]), ovlkHandles[i], isoCtxs[i]); > ... > success := OvlK_WaitOrCancel(ovlkHandles[i], 1000, transferredLength); > ... > // loop through all isoPackets, with Offset and Length > > Conclusion: > The maximum packet size "940" in the descriptor is total misleading. It can > probably not work because 940 could not be divided by 8, without remainder. The "interval of 8" constraint applies to the number of packets, not the maximum packet size, so 940 *should* be acceptable. > But 1024 works perfect! All data is alligned, all isoPacket.Offset values > are correct etc. > There should be holes of uninitialized data in your transfer buffer every 940 bytes. Is this the case? Is it possible your device is returning more than 940 bytes despite what is defined in the ep descriptor? I'm beginning to suspect that the "940" in your endpoint descriptor is misleading because it is literally incorrect as it is being treated as a 1024 byte ep. > One other thing, I have seen that you only pass the lower 16bit of the > isoPacket status, this might be a problem because some status are zero in > the lowest 16bit and contain errors > #define USBD_STATUS_CANCELED > ((USBD_STATUS)0xC0010000L) Correct. This was a recent change that decreases the size of an iso packet descriptor to 64bits > Maybe you can copy the topmost 2 bits of the original status to the bit 15 > and 14 of the 16 bit status that you return. > Thanks for the tip. I will get this fixed for the next release. Regards, Travis |
|
From: Ekkehard <edo...@ad...> - 2011-11-30 18:56:58
|
I am working with an existing device, coming up with the given descriptor. Since it does'nt worked, I made a firmware for my Cypress board to emulate the behavior, e.g. coming up with an compareable descriptor, sending data in the same size and matter etc. Having now two devices behaving same, I am pretty sure that there is something strange - or not understood by me. As described above in the thread I was able to catch the transmitted data with Snoopy Pro, which shows the up and down going URBs and there related content. Definitly I can say that a buffer size of 940 bytes passed to the related functions, will cause errors in the received data, more precisely in the URBs shown in Snoopy Pro. The errors occours often on the same memory positions, but I was not able to determine the prinicple of occourence. Using 1024 instead (a kind of ignoring the descriptor) works perfect. There are no transmission errors, holes, overwritten or missed data, etc. I left the program run for hours free of errors. Anyway, since it works, your software does the job!! -- View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5036456.html Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
|
From: Ekkehard <edo...@ad...> - 2011-11-29 16:57:57
|
The mentioned Board uses the CY7C68014A, while mine uses the Cy7C68013 chip. I expect that the FW examples bound with the development kit of the FX2 will work with both chips. Basicly my FW follows the Streaming example given in http://www.cypress.com/?rID=12967 Just the descriptor and the send packetsize are changend -- View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5032993.html Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
|
From: Ekkehard <edo...@ad...> - 2011-12-02 08:54:05
|
If I change the uses packetsize back to 940, than the offset in the packet data is allways a multpile of 940, so I dont belive that it has to do with the size of transmitted data. I also tried 944 (since it is a multpile of 8) but this causes error in received data as well. Can I measure the effective size of transmitted data with an oscilloscope? -- View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5041097.html Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
|
From: Ekkehard <edo...@ad...> - 2013-05-31 06:50:42
|
FYI After a longer period of trouble free running, I found that I now have to switch back to a packetsize of 1024 instead of 940. I argue that it has to do with a driver update, but I am unable to verify. The two drivers I have in test are 3.0.5.13 and 3.0.5.16 and both are running smooth with the change. The question remains why it was running with a packet size of 940 (as announced in the EP descriptor) and not with 1024, and now opposite? Greet Eskkehard -- View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5712022.html Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
|
From: Xiaofan C. <xia...@gm...> - 2011-12-02 08:15:40
|
On Thu, Dec 1, 2011 at 11:41 PM, Ekkehard <edo...@ad...> wrote: > I am not very firm with USB spec, but on the other hand it looks not bad at > all. Here what I got with USBSnoop, you see the device is sending > 940 Bytes or less. 0x47 is the start marker. > > > [28617 ms] <<< URB 599 coming back <<< > -- URB_FUNCTION_ISOCH_TRANSFER: > PipeHandle = 89fede84 [endpoint 0x00000084] > TransferFlags = 00000003 (USBD_TRANSFER_DIRECTION_IN, > USBD_SHORT_TRANSFER_OK > TransferBufferLength = 0000b3ec > TransferBuffer = 00000000 > TransferBufferMDL = 8a4ad5b8 > StartFrame = 01c08fc0 > NumberOfPackets = 00000080 > ErrorCount = 00000000 > IsoPacket[0].Offset = 0 > IsoPacket[0].Length = 940 > IsoPacket[0].Status = 00000000 > ... > IsoPacket[1].Offset = 1024 > IsoPacket[1].Length = 940 > IsoPacket[1].Status = 00000000 > ... > IsoPacket[2].Offset = 2048 > IsoPacket[2].Length = 376 > IsoPacket[2].Status = 00000000 > ... > It seems the Offsets are all multiple of 1024, so I think the length may be 940 since you only request 940 bytes of data but your device may send out 1024 Bytes of data with the remaining 84 bytes not received, therefore libusb-win32/libusbK will fail since your device send out more data than requested. Ref: "the offset value indicates sizes for all the packets within the microframe". http://msdn.microsoft.com/en-us/library/windows/hardware/ff540414%28v=vs.85%29.aspx -- Xiaofan |
|
From: Travis <lib...@gm...> - 2011-12-01 14:57:26
|
On 11/30/2011 10:56 AM, Ekkehard wrote: > I am working with an existing device, coming up with the given descriptor. > Since it does'nt worked, I made a firmware for my Cypress board to emulate > the behavior, e.g. coming up with an compareable descriptor, sending data in > the same size and matter etc. > Having now two devices behaving same, I am pretty sure that there is > something strange - or not understood by me. > As described above in the thread I was able to catch the transmitted data > with Snoopy Pro, which shows the up and down going URBs and there related > content. > Definitly I can say that a buffer size of 940 bytes passed to the related > functions, will cause errors in the received data, more precisely in the > URBs shown in Snoopy Pro. The errors occours often on the same memory > positions, but I was not able to determine the prinicple of occourence. > Using 1024 instead (a kind of ignoring the descriptor) works perfect. > There > are no transmission errors, holes, overwritten or missed data, etc. I think this says it all. Your device *must* be sending 1024b packets to the PC, otherwise there would be sections of unused data, of size 1024-940=84 bytes, at the end of each packet. > I left > the program run for hours free of errors. > Anyway, since it works, your software does the job!! > I certainly can't argue with success. ;) Your solution fixed it. However, this device violates USB specs when it (presumably) sends packets larger than it's reported wMaxPacketSize. This might cause problems with different host controllers, OSes, etc. Regards, Travis |
|
From: Ekkehard <edo...@ad...> - 2011-12-01 15:41:28
|
I am not very firm with USB spec, but on the other hand it looks not bad at
all.
Here what I got with USBSnoop, you see the device is sending 940 Bytes or
less.
0x47 is the start marker.
[28617 ms] <<< URB 599 coming back <<<
-- URB_FUNCTION_ISOCH_TRANSFER:
PipeHandle = 89fede84 [endpoint 0x00000084]
TransferFlags = 00000003 (USBD_TRANSFER_DIRECTION_IN,
USBD_SHORT_TRANSFER_OK
TransferBufferLength = 0000b3ec
TransferBuffer = 00000000
TransferBufferMDL = 8a4ad5b8
StartFrame = 01c08fc0
NumberOfPackets = 00000080
ErrorCount = 00000000
IsoPacket[0].Offset = 0
IsoPacket[0].Length = 940
IsoPacket[0].Status = 00000000
00000000: 47 1f ff 10 00 00 00 00 00 00 00 00 00 00 00 00
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 47 1f ff 10
000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000170: 00 00 00 00 00 00 00 00 47 1f ff 10 00 00 00 00
00000180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000230: 00 00 00 00 47 1f ff 10 00 00 00 00 00 00 00 00
00000240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000002a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000002b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000002c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000002d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000002e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000002f0: 47 1f ff 10 00 00 00 00 00 00 00 00 00 00 00 00
00000300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000003a0: 00 00 00 00 00 00 00 00 00 00 00 00
IsoPacket[1].Offset = 1024
IsoPacket[1].Length = 940
IsoPacket[1].Status = 00000000
00000000: 47 1f ff 10 00 00 00 00 00 00 00 00 00 00 00 00
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 47 1f ff 10
000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000170: 00 00 00 00 00 00 00 00 47 1f ff 10 00 00 00 00
00000180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000230: 00 00 00 00 47 1f ff 10 00 00 00 00 00 00 00 00
00000240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000002a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000002b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000002c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000002d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000002e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000002f0: 47 1f ff 10 00 00 00 00 00 00 00 00 00 00 00 00
00000300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000003a0: 00 00 00 00 00 00 00 00 00 00 00 00
IsoPacket[2].Offset = 2048
IsoPacket[2].Length = 376
IsoPacket[2].Status = 00000000
00000000: 47 1f ff 10 00 00 00 00 00 00 00 00 00 00 00 00
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 47 1f ff 10
000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000170: 00 00 00 00 00 00 00 00
--
View this message in context: http://libusb.6.n5.nabble.com/Isochronous-IN-problem-tp5020128p5039049.html
Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.
|
|
From: Xiaofan C. <xia...@gm...> - 2011-11-28 02:45:52
|
On Thu, Nov 24, 2011 at 9:12 PM, Ekkehard <edo...@ad...> wrote: > I have to use isochronous transfer. BTW, I have to ask why you really need to use isochronous transfer? Unless you are developing a USB Audio/Video device, isochronous transfer can usually be replaced by interrupt and bulk transfer. This is especially true for high speed USB device. An example from NI. http://zone.ni.com/devzone/cda/tut/p/id/4636 -- Xiaofan |
Thanks for helping keep SourceForge clean.
X