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.

Topics - Jaholmes

Pages: [1]
1
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.)

2
I'm building a USB sensor application using discrete logic--no MCU or CPU.  I have a few candidate designs drawn up, and noticed that I could simplify things if it was permissible to keep WR normally high, then pulse low-high to write.  Datasheets for the FT240X and FT245 are a bit ambiguous about this.  I should mention that I'm also reading bytes, so RD must also being pulsed low-high periodically.  Can this happen while WR is held high--without anything bad happening?  Or must WR be low to read?  I'd guess it would be ok, but figure I ought to put it out there just in case.

Very best,
Aaron

Pages: [1]