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 <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
|
