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 <[email protected] > <mailto:[email protected]>> > > 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 [email protected]
