Re: tcdrain / TCSBRK / wait_until_sent delay

[Andy Parkins <andyparkins@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]

On Monday 2005 May 09 17:33, rich+ml@lclogic.com wrote:
> On Mon, 9 May 2005, Andy Parkins wrote:
> > Are you sure that RTSCTS flow control is what you think it is?  These
> > days RTS means "request to send to me" rather than "I request to send";
> > that allows RTS and CTS to be crossed over in null modem cables - and
> > puts the flow control in the receiver directly.
>
> Yep. RTS is an output from the PC, CTS is an input to the PC, weird
> cabling does not change this.

I wasn't suggesting otherwise; I think these days though, RTS doesn't mean 
that the PC is requesting to send it means the PC is open to receiving. 

http://www.pccompci.com/cable.html

Hence, when the RTS and CTS are crossed over in a null modem cable (which 
isn't by any means weird) RTS from device 1 lights up CTS in device 2 and 
vice versa -- exactly what would be required.  Although t

> > I'm coming to accept that what I'm after isn't possible.  How likely is
> > it that I could patch the serial_core kernel driver to do the RTS control
> > for me?  Am I going to end up in the same situation?
>
> I believe you will end up in the same situation.

As it happens, Christer Weinigel in another part of the thread suggested a 
solution that I've had great success with - so thankfully I don't have to go 
near the kernel :-)

> You might take a look at a usb-to-serial cable, kernel will 'mount' it as
> /dev/ttyUSB0 or something so the application doesn't have to know any
> better. However these cables contain PL2303 or similar uart which supports
> auto rts/cts if so enabled (the idea is to not push every control signal
> transient down the usb). Google for PL2303 spec, look for pl2303.c in the
> kernel.

That would be an excellent solution, and I still may look into that - the 
option of lots of serial ports via USB has a certain appeal.

Again, thanks for your help on this.  It's all been (and continues to be) very 
interesting.

Andy

-- 
Dr Andrew Parkins, M Eng (hons), AMIEE


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]