Re: tcdrain / TCSBRK / wait_until_sent delay

[Andy Parkins <andyparkins@gmail.com>]

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

On Saturday 2005 May 07 19:09, rich+ml@lclogic.com wrote:
> > > Have you tried hardware flow control, "stty crtscts < /dev/ttyX"?. 
> > > With CTS strapped high, RTS should follow THRE||TE.
> >
> > That's an interesting idea - CTS is currently set by the RS485 converter
> > to indicate when it has successfully turned the buffer around.  So it
> > goes, RTS set high, wait for CTS, send...  Is what you're suggesting that
> > I cut this wire and hold CTS high externally?
>
> Oh no, in that case you don't need to do anything. The transaction you
> described is exactly what happens automatically when crtscts is enabled.
>
> However if your uart doesn't actually support AFE then it will be done
> by the driver and have the timing characteristics you see already.
>
> Hook up your scope, "stty crtscts < /dev/ttyX; echo test > /dev/ttyX" and
> see what happens.

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.

Of course in my case the RS485 converter is abusing the RTS line for its own 
purposes, which is why I set -CRTSCTS.

Regardless of all that, I tried it anyway with no joy :-)

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?


Andy

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


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