[lug] Latency for serial port hardware handshake?

[Stephen Queen]

On 11/16/06, Dan Julio <djulio99 at yahoo.com> wrote:
> Hey all,
>
> Does anyone know how Linux processes de-assertion of
> CTS on a typical PC-based serial port?  I need to
> understand how many more characters may be sent from
> the Linux box (DTE) to a DCE device when the DCE
> device de-asserts CTS.
>
> Specifically I am running on a Dell 4100/RH7.3.  The
> built-in port uses the 16550A UART chip.  I am talking
> to an embedded controller with a small buffer.  This
> buffer holds 4 up-to-16 byte packet entries.  The
> controller de-asserts CTS when 3 buffer entries are
> full allowing for transmission of part-of or a
> complete 4th packet.
>
> I have enabled my linux control software to look at
> CTS (options.c_cflag |= (CRTSCTS);)   I verified this
> works by manually de-asserting CTS (the computer won't
> send anything until it is re-asserted).  However it
> looks like there is some latency between the serial
> driver acting on CTS when there is data in some
> internal FIFO.  It looks like I get another packet+
> sent to the device after it de-asserts CTS and, of
> course, it loses the packet after #4.
>
> And...then...if any of you wizards know how this all
> works I have another question.  Can I expect this to
> be different on different hardware (probably yes).
> The eventual target for the control software is
> another embedded system running on a StrongARM
> (built-in UART and probably different drivers).
>

I am kind of confused by your use of the word packet. I assume that
you mean byte when you say packet. According to the data sheet for the
16550A, if the 4th byte has already started to be transmitted when cts
is de-asserted, then it will transmit the complete byte. So if the
controller a little late de-asserting cts it would exhibit the
behavior you describe. I don't believe it would have much to do with
the linux driver because this should be handled in the hardware of the
16550A.