Thanks for suggesting to change the flow control.
Yesterday, I have read the AN232B-04_DataLatencyFlow.pdf document. That
document seems to be valuable, but I am missing info about asynchronous
mode. Unfortunately, it recommends handshaking protocol like you Will,
what I cannot achieve with this current design, due to high bandwith, I
cannot wait for long to send the bytes (in the microcontroller).
I thinking how to convert the design to use flow control, but this
decision might require quite complex program structure, to realize
correct timing. So, this task going to sleep for a while...
My next questions:
1. Whats happens when a device is connected to the chip what is plugged
into USB bus, and sending continuous data stream? While it is not yet
queried? May some data preserved for a while?
2. When starting libftdi, how to clean the buffer if it is filled with
some rubbish data at first ftdi_read_data(...) call? (I experience all
the time mixed and various incorrect data in the first data set.)
3. What happens between two ftdi_read_data(...) calls? Might be there a
chance to missing some data?
Will Zhang írta:
> Take a look at this application note from FTDI, particularly part II.
> FTDI recommends using hardware flow control/handshaking to prevent chip
> buffer overrun.
> This FAQ has info on how CTS/RTS work on FTDI chips.
> However though, I think there's a bug with libftdi's flow control
> setting function. Here's what I know:
> My configuration involves an FT232R in UART mode connected to an FPGA.
> The FPGA has UART transmitter implemented in HDL with CTS input (which
> is connected to the RTS output on FT232R) as flow control option.
> Ideally, if the FPGA is sending data non-stop but meanwhile the PC
> cannot keep up with it's pace (USB driver is not scheduled frequent
> enough to move data from chip buffer to the PC), the chip buffer will
> fill up quickly and the RTS line will go high (RTS# is active low) to
> indicate buffer full. Then the FPGA UART Tx should stop transmitting
> data in order to prevent buffer overrun on the FT232R.
> The problem I've found is that many driver options did not set the flow
> control register in the FT232R chip correctly. I have experimented
> numerous driver options on the PC side, some worked, many didn't.
> Here's a list:
> These drivers are not working correctly, RTS line is constantly high,
> which is the behavior when flow control is set to NONE.
> - FTDI's D2XX library (binary release only) on Linux and Mac OS X
> - ftdi_sio VCP kernel module on Linux (This is the Linux VCP driver on
> FTDI's website)
> - libftdi on Linux and Mac OS X
> These drivers are working correctly, RTS is high when buffer is nearly
> full, low otherwise.
> - FTDI's VCP kernel extension (binary release only) for Mac OS X
> - FTDI's VCP driver (binary release only) for Windows
> I haven't tested D2XX DLL driver on Windows.
> Apparently, I'm not the first one to report this issue. This is an
> archived conversation that had described the same problem:
> Note that for all these drivers, the CTS/RTS flow control works fine in
> the other direction, FPGA -> FT232R in my case.
> Any suggestions? Should I report this to FTDI, Bill Ryder maybe?
> 2010/8/24 Szőke Sándor - Alex <mail@xxxxxxxxxxxxxx
> I trying to manage a connection between the PC and a micro controller.
> using a cable with ftdi232rq.
> The things I have figured out:
> 1. managed setting of exact 2Mbaud with 2000100 baud, which is funny for
> me. :) (This cable has maximum transfer capacity of 3Mbaud.)
> 2. ftdi_read_data(...) was returned without data with the size of the
> puffer, but the one currently in svn is suitable. Read returns after
> latency or buffer is full.
> The problem I have just recently discovered, is when making a continuous
> receive for more than 10 seconds. There are missing bytes somewhere in
> the middle... (variable missing bytes occur in the data flow). I would
> be happy with 1 byte missing from 4kbyte.
> I read in 4096 bytes with 16ms latency.
> I don't know how to resolve this.
> Maybe there is data received, in between the calls to
> ftdi_read_data(...) that is missed? Or what?
> Currently, the micro sends bytes continuously at 2Mbaud.
> Any help would be appreciated...
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx