Re: [Patch] new serial flow control

[Nick Craig-Wood]

Stuart MacDonald <stuartm@xxxxxxxxxxxxxxx> wrote:
>  From: Alan Cox
> > On Mer, 2004-10-06 at 08:38, Samuel Thibault wrote:
> > > No: CRTSCTS is a one-signal-for-each-way flow control: each
> > > side of the link tells whether it can receive data. CTVB is a
> > > two-signals-for-only-one-way flow control: the device tells when it
> > > wants to send data, the PC acknowledges that, and then one frame of
> > > data can pass.
> > 
> > This sounds a lot like RS485 and some other related stuff. I need to
> > poke my pet async guru and find out if they are the same thing. If so
> > that would be useful.
> 
>  RS485 is a driver-transparent electrical interface.

Yes, in theory!  In practice it isn't quite transparent due to
tristating.

These are the 4 main types of serial interface that I use regularly
RS232, RS422, RS485 4-Wire and RS485 2-Wire.

RS232 we all know and love - 12 V signalling etc

RS422 is RS232 with a different electrical interface, ie 5V
differential (2 wires per signal, eg rx+, rx- etc)

RS485 4-Wire is like RS422 but the bus has the potential to go
tri-state.  In a bus with only one master, the master can just
transmit all the time and all the slaves will listen.  However if you
want to be a slave or have multiple masters it is necessary for you to
tristate the bus.

RS485 2-Wire is like RS485 4-Wire except the transmit and receive
lines are combined into rx_tx+ and rx_tx-.  In this kind of bus it is
essential everyone tristates the line after transmitting.

For the RS485 busses there needs to be some way of telling the serial
interface hardware that you want the bus to be tristate.  This is
typically done with DTR (which isn't used for RS485 busses), DTR=1
means untristate the bus and DTR=0 means tristate it.

When used like this timing is very critical - you must de-assert DTR
as soon as the serial character has left the serial UART.  This is
difficult to do exactly in user-space.  Alternatively you can use a
specialist serial interface which will do it for you.

In practice for our applications we use RS485 in master mode which
requires no difficult control.  When we have to do RS485 in 2-Wire
mode we transmit a character and block our application to wait for it
to come back then de-assert RTS.  Thats nasty though and would be much
better done in the serial driver, where you get an interrupt at
exactly the moment the tx fifo is empty.

>  Unfortunately the half-duplex and master-slave(s) arrangements
>  require some sort of token passing to know when they can
>  successfully transmit.

It does.  Its usually done with a packet protocol and addresses.

>  This is usually handled by the apps in some manner, although it's
>  often wanted to be handled by the serial driver. This could be one
>  method of signalling, but isn't sufficient to show RS485 operation.

The tristating above should be done in the driver if possible.  The
packet protocol etc should be done in the application.

The flow control method described by the OP doesn't sound exactly like
RS485, but the timing constraints of waggling RTS are exactly the
same.

-- 
Nick Craig-Wood <nick@xxxxxxxxxxxxxx> -- http://www.craig-wood.com/nick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/