2005-03-15 16:06:02

by moreau francis

[permalink] [raw]
Subject: [UART] 8250:RTS/CTS flow control issue.

I tried to use my serial port with rts/cts flow
control enabled in order to transfer a data file
between 2 DTE. The first one is a PC running Linux
with a 8250 UART and the second one is a developement
board running Linux with a particular UART (I wrote
its driver based on 8250's one).

Actually 8250 UARTs have rts/cts line but they're
managed by software (and then called hw flow control
!!!). Hence when my board's UART (which have a "true"
hw flow control) asserts its RTS line, 8250's UART
sends 8 bytes before stopping TX...
Therefore board's UART fifo have been overrun because
it has only 8 bytes for its fifo.

Does it mean that we can't do any reliable flow
controls with 8250 UART ? In that case a simple
workaround would be to limit tx fifo to 1 byte...

Thanks

Francis







D?couvrez nos promotions exclusives "destination de la Tunisie, du Maroc, des Bal?ares et la R?p. Dominicaine sur Yahoo! Voyages :
http://fr.travel.yahoo.com/promotions/mar14.html


2005-03-17 09:57:53

by Russell King

[permalink] [raw]
Subject: Re: [UART] 8250:RTS/CTS flow control issue.

On Tue, Mar 15, 2005 at 05:05:54PM +0100, moreau francis wrote:
> Does it mean that we can't do any reliable flow
> controls with 8250 UART ? In that case a simple
> workaround would be to limit tx fifo to 1 byte...

With a popular 8250 UART on the other end, you need to ensure that
you disable the CTS signal with sufficient time (== at least the
number of bytes in the transmit FIFO) so that the transmission stops.

This is because many 8250 UARTs don't have any hardware linkage
between the CTS signal and the transmitter. Later 8250 UARTs which
do have automatic hardware flow control allow for this, as do
most other serial peripherals.

I, therefore, strongly suggest that you arrange to do the same -
iow, deassert RTS when your buffer is approaching approx. 2/3 full
rather than absolutely full.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

2005-03-17 14:35:23

by moreau francis

[permalink] [raw]
Subject: Re: [UART] 8250:RTS/CTS flow control issue.

Russell King wrote:
>I, therefore, strongly suggest that you arrange to do
the same - iow,
>deassert RTS when your buffer is approaching approx.
2/3 full rather
>than absolutely full.

Well, I don't think this gonna work because my rx fifo
is only 8 bytes
length and 8250's one is 16 bytes length. This means
that if I
deassert RTS when my fifo is 5 bytes full, I can
potentially receive 8
bytes and thus get an overrun...

But why should I "degrade" my UART because some 8250
devices have
poor hardware implementation. Maybe we should limit
their tx fifo to
one byte when rts/cts flow control is enabled...

thanks

Francis






D?couvrez nos promotions exclusives "destination de la Tunisie, du Maroc, des Bal?ares et la R?p. Dominicaine sur Yahoo! Voyages :
http://fr.travel.yahoo.com/promotions/mar14.html

2005-03-17 16:17:37

by Russell King

[permalink] [raw]
Subject: Re: [UART] 8250:RTS/CTS flow control issue.

On Thu, Mar 17, 2005 at 03:34:49PM +0100, moreau francis wrote:
> But why should I "degrade" my UART because some 8250
> devices have
> poor hardware implementation. Maybe we should limit
> their tx fifo to
> one byte when rts/cts flow control is enabled...

Because you don't actually understand what "hardware" and "software" flow
control refer to. It doesn't refer to the way the control is derived, as
your messages appear to imply.

What it does refer to is the *signalling* method:

* Hardware flow control is performed using the RTS and CTS signals.
These signals may be software controlled.

* Software flow control means sending an XOFF character to stop
transmission, and another character to start transmission.

In both flow control scenarios, it is very common that there may be some
latency between the reception of the "stop transmission" signal and the
transmission actually stopping.

This is precisely why the 8250 UARTs which do have "automatic flow
control" incorporated into the receiver have *large* FIFOs with
programmable trigger levels - it allows for the latency at the
transmission end.

If you want it to be immediate, then I'm afraid you're going to have a
relatively hard time, with compatibility problems with various systems.
You can't really dictate to people that they must turn off the FIFOs on
their UARTs for your product to work. (Well, you can, but _you_ would
have to support them.)

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

2005-03-18 09:31:06

by moreau francis

[permalink] [raw]
Subject: Re: [UART] 8250:RTS/CTS flow control issue.


--- Russell King <[email protected]> wrote:
> If you want it to be immediate, then I'm afraid
> you're going to have a
> relatively hard time, with compatibility problems
> with various systems.
> You can't really dictate to people that they must
> turn off the FIFOs on
> their UARTs for your product to work. (Well, you
> can, but _you_ would
> have to support them.)
>

well, I don't specially wan't to be immediate.
My hardware has "auto flow control" and a 8 bytes
fifo...So *whatever* the trigger level is for RTS
(actually I can't tune it), I will overrun because
the end *driver*, which should be aware of the lack of
its "hw auto flow control", decides to fill up its tx
fifo to 8 bytes when transmiting...

One other solution may be to give the possibility of
the user to tune the size of tx fifo ?

thanks

Francis






D?couvrez nos promotions exclusives "destination de la Tunisie, du Maroc, des Bal?ares et la R?p. Dominicaine sur Yahoo! Voyages :
http://fr.travel.yahoo.com/promotions/mar14.html