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

Pages: [1] 2 3 ... 10
 1 
 on: December 03, 2021, 12:04:46 PM 
Started by HI_type - Last Post by HI_type
Hello FTDI Community

I did nor get an answer from my colleagues but still believe that we do not need to check for ACK/NACK. I shall push for an answer and return soon.

When sending above 1 MBit, will the FT232H send the start byte at 100 Kbit (we measured 50 kBit on the the FT4222H)? Not sending the start bit at 400 KBit (or ideally more, even if it is outside of spec) is currently the biggest limitation.

 2 
 on: December 03, 2021, 11:40:19 AM 
Started by HI_type - Last Post by FTDI Community
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



 3 
 on: December 01, 2021, 08:02:30 PM 
Started by Jaholmes - Last Post by Jaholmes
Thank you, I'd love to get a copy of the draft app note.  I'll email shortly.

Yes, I'm familiar with Purge().  In this instance, I'm not looking to discard anything, though as a general rule we do Purge() the RX and TX buffers upon first connecting to the device just to minimize consumption of stale data at both ends of the cable.

To the docs thing:  That would be great also.  I'll often scratch my head while reading the datasheets and app notes when I come across terms like "transmit" and "receive," because they obviously mean very different things according to whether you're talking about the host PC or the chip, and if the chip, then whether you're talking about the USB side or the UART/parallel/etc. side.  Sometimes the context is enough to disambiguate, but often times it's not, at least not for me.  I'm all for excessive explicitness when it comes to these things.  (Then I don't have to come here and ask possibly dumb questions either! :))

 4 
 on: December 01, 2021, 03:19:51 PM 
Started by Jaholmes - Last Post by FTDI Community
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

 5 
 on: November 30, 2021, 04:03:26 PM 
Started by Jaholmes - Last Post by Jaholmes
I was somewhat amused to discover that the application note on latency contains exactly zero instances of the word "write," heh.  Sigh...  Obviously there will be a lot of platform dependencies here, but I'm curious if FTDI can offer any guidance on best practices for minimizing PC->device latency, specifically in situations where the data rate is very low.  As I understand it, the latency timer only applies to data being moved from device to PC.  If I write only a single byte using FT_Write() (not exactly a real-world scenario for me, but for discussion's sake...), how much buffering is done by the driver?  What, if anything, can be assumed about the frequency with which that buffer will be committed to USB if not completely filled?  D2XX does not appear to have any analog of a "flush" operation.  Would it be better if I used VCP and the Windows serial API, which does have a flush?  Does VCP do anything special when the associated port is "flushed" via the Windows serial port API?

I expect these questions have all been asked many times before, however all searches for latency seem to lead to the FTDI app note on latency, which appears solely concerned with latency device->PC and not the other way around.

(As an aside, it would be great if FTDI could make a quality pass on their documentation.  As it stands, there are just far too many ambiguities and outright contradictions, and in places that are pretty unbecoming of a communication device company, as they pertain to such basic terms as "transmit," "receive," and "buffer."  As an example, the product page for the FT232R talks about "256 Byte receive buffer and 128 Byte transmit buffer..." and "Adjustable receive buffer timeout," while in the datasheet you have "128 byte receive buffer and 256 byte transmit buffer."  The datasheet says nothing about the "receive buffer timeout," which in other documentation is called the "latency timer," and is described as pertaining to transmit, not receive.  As well, the block diagram for the device doesn't refer to buffers, but to FIFOs, making one wonder whether they're truly the same thing.)

 6 
 on: November 30, 2021, 09:27:35 AM 
Started by a4711 - Last Post by FTDI Community
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 

 7 
 on: November 29, 2021, 10:40:06 AM 
Started by a4711 - Last Post by FTDI Community
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

 8 
 on: November 29, 2021, 09:04:01 AM 
Started by boodoooo - Last Post by boodoooo
Hello,

i did try FT_Purge already.

What buffer holds the data coming from the USB-Host? (Data sent via FT_Write)
The FT201X-datasheet has two statements to this, but they are mismatching.

Note that the Transmit buffer is the buffer which holds data which has come from the host computer and is going to be read by the external I2C master.

Data sent from the USB host controller to the I2C interface via the USB data OUT endpoint is stored in the FIFO RX (receive) buffer.

Regards, Hendrik

 9 
 on: November 29, 2021, 04:54:06 AM 
Started by HI_type - Last Post by HI_type
Hello FTDI Community

Understood and thank you for the explanation. Our target device does not require us to check every ACK/NAK, but will double check just to be absolutely certain. Assuming that ACK/NAK checks are not needed, do you have another I2C master device that performs better?

 10 
 on: November 26, 2021, 06:22:51 PM 
Started by HI_type - Last Post by FTDI Community
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

Pages: [1] 2 3 ... 10