USB Isochronous Transfer

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

USB Isochronous Transfer

1,951 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ranaya on Thu Jun 07 01:17:26 MST 2012
Hi all....

  For real time data acquisition, what wud be the best transfer method ? I think Isochronous transfer may suit for it. And it grantees the data rate too, (correct me if im wrong). In application examples i saw few usb classes (cdc, hid and msd) but they use int/ control & bulk transfer only.

Tell me gentleman where can i find an Isochronous transfer example for USB device ? If i use it, do i need a custom driver ?? (i use lpc1769 expresso)

Thanx Alot

Ranaya
0 Kudos
7 Replies

1,038 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by r1200gs on Wed Jun 04 14:57:59 MST 2014
Some updated USB throughput observations:

On an LPC Link2 (4370 MPU):

using the 'usb_rom_libusb' example running kBench on Windows 7 under VMWare on a Macbook Pro:
    - with 4096 (default) packet size:  3.5 mBytes/sec (as reported above)
    - with 409600 packet size: 36 mBytes/sec

using 'libusb' (libusbK is Windows only) native on the Macbook Pro on Mac OS 10.9.2:
    - with 51200 packet size: 33 mByte/second read and 27 mByte/sec write.

This is with an unmodified 'usb_rom_libusb' application running on the LPC Link2 which uses bulk endpoints.

From my spec reading today, I believe this to be fully error corrected data transfer, but I have read about dropped packets in the LabTool code and so I will be watching for that still.
0 Kudos

1,038 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by r1200gs on Mon Jun 02 15:06:31 MST 2014
I got the 'usb_rom_libusb' example in LPCOpen for the 43XX working on an LPC Link2 and throughput comes out at 3.5 mBye/sec using high speed USB. Which is pretty awful compared to the Cypress app note you mention. It looks to me that the example does raw transfers using the on-board USB library in ROM (as opposed to CDC).

Can anyone give an example of what sort of USB throughput can be achieved on a 4370? If I can't hope to get at least 10 mBytes/sec (it would be nice to get 40 mBytes/sec as per the Cypress app note) I need to be working on a different solution.

Sustained throughput you can get with a LabTool board, for example, would be helpful to hear.

Thanks.
0 Kudos

1,038 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Tsuneo on Sat Jun 09 07:17:53 MST 2012
Ah yes.
CDC is handy. It's good enough for light home/office application and quick experiment.

For heavy-duty application, generic drivers, WinUSB or libusb(-x86),  provide better control over USB. For example, Windows CDC driver (usbser.sys) silently drops bulk IN pipe, when burst noise defeats USB hardware retries. In such case, generic drivers notify your application, at least. And then your application recovers the IN pipe by pipe reset.

Fortunately, CDC device is driven by generic driver without any change of its firmware. Just assign VID/PID of the CDC device at the driver's INF file. Therefore, you may start with CDC, and easily change to generic driver, when you need more control.

Tsuneo
0 Kudos

1,038 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ranaya on Fri Jun 08 22:30:32 MST 2012
Thnx Tsueno, appreciated ur help :)

So here usb CDC class is preferred for my application. isnt it ?? Thanx Every1....
0 Kudos

1,038 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Tsuneo on Fri Jun 08 15:32:14 MST 2012

Quote: ranaya

  For real time data acquisition, what wud be the best transfer method ? I think Isochronous transfer may suit for it. And it grantees the data rate too, (correct me if im wrong).



For this purpose, bulk transfer is preferred.

The major reason is error correction. Data acquisition often means error-free, instead of data streaming. Bulk transfer has intrinsic error correction mechanism (error-retries) which is implemented on the hardware side. But isoc is equipped with just error detection. For isoc, you have to implement error correction method on your firmware and PC application.

Another reason is bandwidth availability. Isoc transfer reserves bus bandwidth, but it also means that the available bandwidth is limited. The max bandwidth of isoc doesn't saturate bus bandwidth. You may guarantee full bandwidth for bulk in operation. For example, just single device hooks under a PC host controller, the bulk endpoint on the device may occupy full bandwidth.

Here is a performance comparison of iso and bulk, on high-speed EZ-USB
[B]Streaming Data Through Isochronous or Bulk endpoints on EZ-USB FX2 and FX2LP[/B]
http://www.cypress.com/?docID=29941
[I]The results show that the average throughput that can be achieved with the BULK transfers is 43.8 MBps and the maximum throughput that can be achieved with ISO transfers is 24 MBps.[/I]

Tsuneo
0 Kudos

1,038 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ranaya on Fri Jun 08 10:59:27 MST 2012
All these examples use bulk/ interrupt and control transfers. Can any 1 give me a clue on this.... I want to send a text file frm SD card to PC via USB. Is CDC sufficient for this ?? If not how can i develop ISOCHRONOUS transfer ???

Waiting for ur quick replies gentlemen !!!
0 Kudos

1,038 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by researchinnovation on Thu Jun 07 04:32:57 MST 2012

Quote: ranaya
Hi all....

  For real time data acquisition, what wud be the best transfer method ? I think Isochronous transfer may suit for it. And it grantees the data rate too, (correct me if im wrong). In application examples i saw few usb classes (cdc, hid and msd) but they use int/ control & bulk transfer only.

Tell me gentleman where can i find an Isochronous transfer example ? If i use it do i need a custom driver ?? (i use lpc1769 expresso)

Thanx Alot

Ranaya




Hi....!!!

Try this

http://ics.nxp.com/support/lpcxpresso/


Thanks & Regards....:)
0 Kudos