FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - FTDI Community

Pages: [1] 2 3 ... 46
1
Discussion - Software / Re: FT4222H - Clock rate issues and pauses. Again?
« on: December 03, 2021, 11:40:19 AM »
Hello,

I'm not 100% sure but I was wondering if the MPSSE-based FT232H might be suitable but it would depend if the system needs to check ACK as if so it would definitely have gaps.

Note that any of the devices could have gaps (at the very least where data is split across USB packets and frames) and the timing could also vary depending on USB bus conditions. For high throughput devices, they use bulk USB transfers and these have their latency and assigned bandwidth determined by the host and by the bus conditions (other devices connected) and so I would say that it isn't possible to have a 100% guaranteed gap or latency.

For specifc cases where the gaps are important, having additional processing on the device end may be one consideration(for example an MCU or logic device with an FT232H in async FIFO mode feeding data at up to 8MBytes/sec) and the MCU then outputting the I2C data and even checking the ACK.

If you definitely dont need to check the ACK, we could do a basic check with a UM232H (acting as USB-I2C via MPSSE in place of the UMFT4222H) to see how writing a stream of 100 bytes etc. looks if it would help you determine if it is worth pursuing,

Best Regards, FTDI Community



2
Hi,

We do have some other documentation that will be able to help you. the draft application note about optimizing USB device communication goes over transfer sizes and data transfer optimization for both reads and writes.

if you email me at support4@ftdichip.com I will be able to send it to you.

here is some more documentation that may be able to help:

https://ftdichip.com/wp-content/uploads/2020/08/AN232B-04_DataLatencyFlow.pdf
https://www.ftdichip.com/Support/Documents/AppNotes/AN232B-03_D2XXDataThroughput.pdf

the D2XX driver has a function called FT_Purge which can be used to clear the buffers. This is shown in section 3.32 of the D2XX programmers guide

https://ftdichip.com/wp-content/uploads/2020/08/D2XX_Programmers_GuideFT_000071.pdf

Also, thank you for your feedback concerning our documentation. i assure you we have a review system for all of our documentation and we will take your feedback under consideration.

Please let me know if you have anymore questions.

Best Regards,

FTDI Community

3
Hi,

Setting the timeout to 0 just means that the timeout is infinite, or until the task has been completed. There should be no real consequences to dong this.

Best Regards,

FTDI Community 

4
Discussion - Drivers / Re: Relinkable object files for libft4222
« on: November 29, 2021, 10:40:06 AM »
Hi,
The libftd2xx distribution has the object files needed to recompile with as required by the libusb license.   You should bundle the object files for libftd2xx as well as the .a/.so file with your libft4222 object files. There’s no general need to provide a Makefile or internal headers.   This can be done using the Jenkins as you already take the tar.gz file for each platform.

Regards
FTDI Community

5
Discussion - Software / Re: FT4222H - Clock rate issues and pauses. Again?
« on: November 26, 2021, 06:22:51 PM »
Hello,

We checked with our dev team on this and it is not possible to completely avoid the small gaps between the bytes.

The start-up byte for the full-speed is fixed at 100Kbps and is enabled when you go above 1M and so if you run at 1M or less you can avoid it. However, you would not be able to change the speed of this byte.

I'm not sure if it will be possible to reduce those short pauses any further than what you had seen at 1MHz unfortunately.

Does your target device need the interface to check the ACK/NAK status which it returns?

Best Regards, FTDI Community

6
Discussion - Software / Re: FT201X - How to purge the FX-Buffer
« on: November 26, 2021, 03:10:49 PM »
Hi ,
Can you try FT_Purge? This function purges receive and transmit buffers in the device.

Regards
FTDI Community

7
Discussion - Drivers / Re: VCP driver on macOS 11
« on: November 18, 2021, 04:00:49 PM »
Hello,

We have received your email and are in contact with our R&D team about this.

Please continue to work with us on email as the forum is maybe not the best medium to get the quickest support.

Best Regards,
FTDI Community

8
Discussion - Drivers / Re: Windows (Universal) D2XX driver
« on: November 16, 2021, 12:48:52 PM »
Hi,

The Universal Windows Driver (Windows 10 and Windows 11 only) enables developers to create a single driver package that runs across multiple different device types, from embedded systems to tablets and desktop PCs.

The Windows Desktop driver will suit most users who want to use our products on a Windows PC.

We have just updated the website to include this information.

Best Regards,

FTDI Community

9
Hi,

we were able to recreate the high CPU load on the raspberry pi. you can add the following setting at the beginning of your code which will resolve this issue: ftStatus = FT_SetTimeouts(ftHandle, 5000,0);

concerning the gaps between bytes, sorry this is a firmaware limitation so there is no way to resolve it.

Best Regards

FTDI Community

10
Hello,

As we are working from home at the moment, I do not have the required hardware to see if I can recreate your issue. However, I have sent your code to my colleague who does have access to the required hardware, so they can test it. I'll let you know what they find.

In the mean time, have you tried running the example as is? Just to see if the hardware is functioning properly?

Best Regards

FTDI Community

11
Hello,

We have a technical note about USB data transfer efficiency that can help you: https://ftdichip.com/wp-content/uploads/2020/08/TN_103_FTDI_USB_Data_Transfer_EfficiencyFT_000097.pdf.

The main points are:

• Send as much data to the IC from the host application as possible in a single write. This will
maximize the size of the data packets being sent to the device and hence minimize the number of
packets required and time to transfer an amount of data.

• Set the latency timer to a value appropriate for the application. Note that a low latency timer
value may result in many short incoming USB packets rather than a single large packet, thus
diminishing performance.

you should also refer to section 5.3 of the FT4222 datasheet: https://ftdichip.com/wp-content/uploads/2020/07/DS_FT4222H.pdf

This section outlines the I2C bus interface.

also which example are you referring to? the one shown in the LibFT4222 user guide or the one included in the library download?

Best Regards

FTDI Community

12
Discussion - Software / Re: FT4222 cannot set speed. Exception raised
« on: November 05, 2021, 04:01:20 PM »
Hi,

You should try running our FT4222H code examples to see if it really is the PC. LibFT4222 Windows Library (v1.4.4) and Examples.

Also, i will need to know more about the exception. feel free to email with the details: support4@ftdichip.com

Best Regards

FTDI community

13
Discussion - Software / Re: FT4222H - Clock rate issues and pauses. Again?
« on: November 05, 2021, 01:46:57 PM »
Hi,

Here is an example attached of 64 bytes transferred by a single write (to address 0x22) at 1MHz clock rate

The gap between the 0x02 and 0x03 for example is 4.6uSec

ftStatus = FT4222_I2CMaster_Write(ftHandle, 0x22, master_data, sizeof(master_data), &sizeTransferred);
master_data is a buffer with 64 bytes (0-63 in value)

Best Regards, FTDI Community




14
Hello,

Ok that's fine then.

using the BOMS and FAT files to detect connection/removal won't work. As you say the UART2DSC doesn't do anything to detect removal or connection of USB devices. This is because it is a minimum project that is used to demonstrate how to write to a file on a flash disk. the procedure is as follows:

the USB host call to VOS_IOCTL_USBHOST_GET_CONNECT_STATE to see if there is a device connected and enumerated.
Search through the devices for the correct device.
Then open and attach the BOMS driver to the handle to the correct device.
After that attach the FAT driver to the BOMS driver.

Periodically poll the VOS_IOCTL_USBHOST_GET_CONNECT_STATE for disconnection, this checks that a device is connected to the root hub.
Also check the return value of any FAT or BOMS driver calls for FAT_NOT_FOUND or FAT_ERROR/FAT_FATAL_ERROR, MSI_NOT_FOUND or other errors. If there is an error again check VOS_IOCTL_USBHOST_GET_CONNECT_STATE to confirm or if there is a bub involved

On disconnection, detach FAT then BOMS drivers from the device.

I would recommend you use one of our other projects such as V2DAP, which has increased functionality and can be downloaded here: https://ftdichip.com/firmware/precompiled/.

Best Regards

FTDI Community
 

15
Hello,

Sorry for the misunderstanding.

what version of the VNC2 toolchain are you using?

version V2.0.2-SP2 fixes a known connect/disconnect issue.

Download Vinculum II Toolchain V2.0.2-SP2

let me know if you are already using this version.

Best regards

FTDI community

Pages: [1] 2 3 ... 46