Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length.

[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.)

[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 support1@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

[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!