Hi,
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?
Alex
Will Zhang írta:
> Hi,
>
> Take a look at this application note from FTDI, particularly part II.
>
> http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf
>
> FTDI recommends using hardware flow control/handshaking to prevent chip
> buffer overrun.
>
> This FAQ has info on how CTS/RTS work on FTDI chips.
>
> http://www.ftdichip.com/Support/FAQs.htm#HwGen3
>
>
> 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:
>
> http://developer.intra2net.com/mailarchive/html/libftdi/2009/msg00131.html
>
> 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?
>
> Cheers,
>
> Will
>
>
>
> 2010/8/24 Szőke Sándor - Alex <mail@xxxxxxxxxxxxxx
> <mailto:mail@xxxxxxxxxxxxxx>>
>
> Hi!
>
> 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...
>
> Alex
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
