Thomas,
Thank you for the response. I'm aware of the limitations of software
flow control, but perhaps I don't understand how buffering works with
the FT232R chip. If you'll indulge me one more time, maybe I can make
my question more clear.
For the moment, I'm ignoring the bitbang/serial side of the chip. I now
suspect that the flow control configuration instructions to the FTDI
chip (use of hardware or software flow control) relate to the non-USB
side of things. If the USB buffer to the FTDI chip is full, how is
this made visible to the application? Do the the usb bulk writes
block? Do one of the status bytes from the FTDI chip change a bit,
indicating that the application should throttle until the bit changes
state again? Is it handled completely internally within the USB framework?
Thanks again,
-Matt
On 5/29/2012 9:41 AM, Thomas Jarosch wrote:
libftdi doesn't have built in support for XON/XOFF, you have to handle
this at the application level. libftdi was written for the bitbang
mode in mind in the first place, nowadays it does much more of course.
I don't think it will be part of the core library, since it really
implements a (common) protocol on top of libftdi. Most people who need
full RS232 communication stick to the ftdio_sio kernel driver. The
wikipedia page on software flow control
http://en.wikipedia.org/wiki/Software_flow_control#Comparison_with_hardware_flow_control
has a good summary why XON/XOFF is "problematic" :) Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
