[lug] Latency for serial port hardware handshake?

[Dan Julio]

Hey Stephen,

Thanks for responding.  

Sorry for the confusing email.  By packet I meant a
1-16 byte group of characters that the DCE device
processes at a fixed rate.  At a certain size of
packet the device can process each packet before the
next is delivered.  But there are certain smaller
packets that must be dealt with.  That's why the
device has a 4-entry FIFO (64 bytes total).  Under
worst-case situations the device may need to stop the
linux host (DTE) from sending more data.

I wrote some test firmware today that just counted
incoming characters after it de-asserted CTS.  On the
linux side I had a simple program just blast as much
data as possible with hardware handshaking enabled.  I
consistently got an extra 16 bytes after de-asserting
CTS.  This leads me to believe that CTS is not looked
at (at least in my linux box) by the UART.  I think
the driver looks at it before loading the UART
(16-byte) FIFO. 

Anyway, thanks for responding.

Dan


--- Stephen Queen <svqueen at gmail.com> wrote:

> 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.
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List:
> http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667
> channel=#colug
> 



 
____________________________________________________________________________________
Sponsored Link

Don't quit your job - take classes online
www.Classesusa.com