This test patch demonstrates the isochronous transfer on 'F32x. But don't expect much for the moment. Only the transfer protocol was replaced to isochronous on USB_INT_Cypress in this patch. After implementing the vendor request, USB_ADC is planned.

USB_ISO_TEST

This test program is based on USB_BULK_Cypress and USB_INT_Cypress. Please refer "USB_INT and USB_BULK on Cypress device driver"

USB_ISO_TEST (modified USB_INT_Cypress)
Firmware
Modified to test isochronous transfer.
Firmware protocol stack
  mainly based on USB_BULK "Last updated 18 JUN 2004"
 add details from USB_INT "Last updated 30 JAN 2004"
  GetDescriptor - String
  Suspend - Resume support
Firmware function
 derived form USB_INT "Last updated 30 JAN 2004"

Device driver
EZ-USB Development Tools V2.61.700
Please refer "USB_INT and USB_BULK on Cypress device driver" to download it.

This is the last message before my vacation. I'll be off until next Monday.. Bye!!

Tsuneo

PS
"USB_ISO_TEST.zip" was updated.
Next files were accidentally dropped from "Host Application Source" folder on previous zip.
3DMeterCtrl.cpp, 3DMeterCtrl.h, dynamicLED.cpp, DynamicLED.h, DynLED.h
Actually, as these files aren't modified, dragging them in from the original files will work.

My USB topics
How to increase HID_Example In/Out packet size?
FIFO read/write performance
256000 bytes/sec Isochronous transfer
Isochronous test patch
Multi-thread and Overlapped example for USB_INT Host Application
Vendor Requests test code
USB_INT and USB_BULK on Cypress device driver

Wanted to know as I can optimize the data transfer?. In case of having 64 ready data to send them to the PC, and soon to return to count without lost.

At the moment I have working I modulate to 64 bytes by package.

I am working strong with test ISO, to obtain a transference of my data to the PC, without lost.

I am optimizing my codes to obtain it.

If you develop the code to transmit 256 kbytes/s with Endpoint 3 would be very good and I would like to see that speed.

I am handling Iso Transfer, with packages of 64 bytes. With converter ADC of the F320 receipt signals of 10kHz and they see well when I make the graph, but if handling signals of smaller frequency these are seen very badly, they seem stairs with great steps (signals of 100 Hertz).

I believe that this happens because there is a time that is lost when the data are being transmitted USB way.

a) Firmware:
To buffer the data, prepare two buffers of the max packet payload size. One buffer will do, but using two buffers is reliable. In your case, two 64 bytes buffers will fit in pdata memory area.
In ADC ISR, store the data to one of the buffer, and raise a flag when the buffer becomes full. When one buffer becomes full, switch to another buffer to fill.
In mainloop, poll the buffer-full flag. Detecting this flag up, transfer the data from current buffer to FIFO and set INPRDY. And down the flag.
Data buffering will be also useful especially for error correction.

I'm now working on direct FIFO writing method. In this method, the ADC data is directly pushed into the FIFO without buffering every time the ADC ends conversion. And when the FIFO becomes full, INPRDY bit is set to send the packet.

Both method, bufferd or direct, will result full or empty packet if the transfer rate is faster than the data rate produced by sampling. USB engine sends empty (zero-length) packet if the FIFO is not ready when Isochronous IN transaction occurs. Double buffering is necessary for these schema.

Direct FIFO method has the advantage on speed and memory usage. However, the weak point of this method is that FIFO access is spread out everywhere. As both FIFO access and USB operation, such as vendor request, use USB registers, they interfere mutually. I believe FIFO access method should be improved if SiLabs plans a revised version of USB MCU.

b) Host application:
If your program requests the transfer packet by packet, not as a block, it may drop packets occasionally. Request as large block as possible, if your program calls DeviceIoControl() synchronously. Or use thread or asynchronous (overlapped) call. As for thread and overlapped example, please refer "Multi-thread and Overlapped example for USB_INT Host Application"

Anyway, the dificulty on Isochronous lies on Host application than firmware to get high bandwidth continuously. I spend almost all of my spare time to poke about the host application these days.

Tsuneo