Hello,

When using bulk USB transfers, it is better to buffer up several readings and then transfer these together. Bulk USB works more efficiently when transferring in larger data packets compared to sending lots of small packets.

The Bulk mode does not offer guaranteed latency and so may also not work in all cases if you want to stream the data in real time where any delay will be noticeable. Many of the USB audio devices which you mentioned on USB2 use the isochronous transfer type which get schedules to offer more consistent latency by the host.

We have the FT602 which uses UVC class instead and so for video-based applications this device would suit well,

Best Regards, FTDI Community

Hello,

Please note that this beta version is now a release version on the FTDI website:

https://ftdichip.com/utilities/#ft_prog

Best Regards,
FTDI Community

Hello,

We just read the number of bytes in the buffer. We did not output or examine the buffer contents. We could see the values were correct on the USB analyser.

The USBview output is taken when the device is connected to a High-Speed USB host. There will be other speed descriptor for Full-speed USB hosts.

Can this be plugged into a Full-speed host for USB? If not then the USBDescritptor sample code will dump the Full-speed descriptors to the UART. The descriptor may be different for Full-speed.

Which endpoint is being used? Is it being correctly selected by the right Alternate Setting?

Best Regards,
FTDI Community

Hello,

We plugged your code into a VNC2 and a Logitech web cam. The code worked straight away with a transfer size of 192 bytes using the simple GET_CUR (probe) and SET_CUR (commit). We used a USB Analyser to observe the output. This particular webcam defaulted to a resolution 320x240 at 15 fps in MJPEG. There were 12 bytes of header per packet leaving up-to 180 bytes of data.

However the program printed out zero bytes per read. The cause is the USB Host read and writes work slightly differently from other read and writes. When a USB host read or write is used the actual length of data transfer is held in the usbhost_xfer_iso_t structure and not in the parameters passed to vos_dev_read/write.

See the page “USB Host Read and Write Operations” in the help file.
“In vos_dev_write() the num_to_write and num_written parameters are ignored and in vos_dev_read() the num_to_read and num_read parameters are ignored as this information is provided and returned in the transfer block.”

Specifically for isochronous transfers the maximum transfer length is specified in the len structure member of the usbhost_xfer_iso_t structure. In the “USB Host Isochronous Transfer Block” page the note for this member says “When the operation completes, the value of len is not updated. However, the transfer length for each frame transaction is updated.” So, the total count of bytes transferred is obtained by reading and checking the condition code of all the deployed len_psw members and summing the sizes there. This is done to ensure that any missed isochronous transfers are accounted for properly in code.

We’ve modified the code as follows and can see 192 bytes reported in the while loop correctly.

                xfer.frame = frame + 1;
               
                *num_read = 0; // LAZ, Added  /*Note this is a pointer and needs dereferenced. */
               
                // now start the read from the ISO endpoint (line 511)
                status = vos_dev_read(ctx->hc, (unsigned char *) &xfer, sizeof(usbhost_xfer_t), num_read); /*(2)*/

                // Sum the total data transferred in each of the isochronous packets for the actual transfer size.
                while (i > 0)
                {
                                *num_read += xfer.len_psw[i - 1].size;
                                i--;
                }
               
                if (status != USBHOST_OK)
                {
                                return UVC_ERROR;
                }

If we set the number of transfers in the usbhost_xfer_iso_t structure to 8 via the ISO_TRANSFER_COUNT macro and disable the printf then we can get meaningful measurements of data transfer from the web cam. In this default resolution the bus utilisation was between 10% and 25%. Maximum throughput can be achieved with the USBHOST_XFER_FLAG_NONBLOCKING set and semaphores used to signal completion as in the original app note code.

Best Regards,
FTDI Community

Hello,

The FT232H/MPSSE itself is not specific to the type of FPGA but it requires that the programming software supports the MPSSE JTAG programming for the selected target. I have never used xc3sprog but it may be that it does not have support for the XC3S50AN and so it would be worth checking with the developers of the utility.

Best Regards, FTDI Community

Hello,

Thank you for your question.

Unfortunately we have not developed a terminal equivalent application for the FT4222H, but maybe someone else on the forum could help you with this.

We do however have a series of software examples which can be downloaded and used to test the device, these include read/write as well as GPIO examples.

The samples are included in the LibFT4222 download, available in the 'downloads' tab on the product page:
https://ftdichip.com/products/ft4222h/


Best Regards,
FTDI Community

Hello,

Unfortunately the driver team are still currently working on the VCP driver, but I will see if they can expedite a ARM build for the D2XX drivers:

Is there any news on this? We have several large customers asking for a fully native driver and can't produce one until have an ARM compatible FTDI library.

Best Regards,
FTDI Community