[lug] Latency for serial port hardware handshake?

[Dan Julio]

Hi Carl,

Thanks for responding.  I sort-of took your idea and
wrote some test firmware that counted incoming
characters after de-asserting CTS.  I wrote a
linux-side test program that just blasted out data.  
I consistently got 16 more characters.  I think that
CTS does not stop the 16550A from sending data, just
the linux device driver from loading any more data
into it.

Then things got screwey on the PXA255 ARM core.  I
can't even make the ports work reliably at this point
so it's another battle. *sigh*, I love linux and I
hate linux...

But thanks again for your response.

Dan


--- "Wagner, Carl" <Carl.Wagner at level3.com> wrote:

> Dan,
> 
> If I remember correctly the 16550A has a 16 byte
> FIFO.
> After you de-assert CTS does it continue to send
> bytes out the wire?
> Is it possible that the FIFO on the 16550A is being
> overrun?
> 
> Do you need to use one of the real-time Linux
> extensions?
> Can you slow the baud rate down to compensate for
> possible interrupt
> latency?
> Can you de-assert CTS after 2 packets?
> 
> I am not sure I would expend a lot of time on this
> if your target is a
> StrongARM, unless the StrongARM implements a virtual
> 16550A.
> 
> That is about as much help as I can give.
> Carl.
> 
> 
> 
> -----Original Message-----
> From: lug-bounces at lug.boulder.co.us
> [mailto:lug-bounces at lug.boulder.co.us] On Behalf Of
> Dan Julio
> Sent: Thursday, November 16, 2006 4:20 PM
> To: lug at lug.boulder.co.us
> Subject: [lug] Latency for serial port hardware
> handshake?
> 
> 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).
> 
> Thanks, Dan
> 
> 
>  
>
________________________________________________________________________
> ____________
> Sponsored Link
> 
> Rates near historic lows - 
> $200,000 mortgage for $660/ month - 
> http://yahoo.ratemarketplace.com
> _______________________________________________
> 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
> _______________________________________________
> 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 portf67
> channel=#colug
> 



 
____________________________________________________________________________________
Sponsored Link

Degrees online in as fast as 1 Yr
MBA, Bachelor's, Master's, Assoc
http://yahoo.degrees.info