Hi, It seems, that I have achieved no data loss.
I created threaded program. The main process calls ftdi_read_data(...) and afterward creates a separate thread to process the returned data and immediately calls ftdi_read_data(...) again. I have used double buffering to be on the safe side. On designs require high data flow, I recommend using threads to process or query data, to call ftdi_read_data(...) as soon as possible to avoid data loss. Alex Szőke Sándor - Alex írta: > 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]
