Re: [patch 3/4] new serial flow control

Re: [patch 3/4] new serial flow control

[Samuel Thibault]

Hi,

I'm re-opening a somewhat old thread about serial flow control methods:

Russell King, le Wed 05 Jan 2005 23:53:01 +0000, a écrit :
> we have other people
> who want to use their on-board hardware RS485 flow control options on
> UARTs for their application, which means we need an RS485 flow control
> method.  (They can't select it without accessing the hardware directly.)
> 
> So, we now seem to have:
> 
> 	Standard flow control
> 	CTVB flow control
> 	RS485 RTS flow control

Let's add a new one: Inka braille devices, which uses RTS/CTS as
acknowledge strobes for each character.

> I still believe that flow control should be enabled by CRTSCTS, but
> the flow control personality set by other means.
> 
> Therefore, I think this requires further discussion, especially with
> Alan (who seems to be the tty layer god now) to work out some sort of
> reasonable interface.

How could this look like in userspace? Something like

#define CRTSCTS_RS232 0
#define CRTSCTS_RS485 1
#define CRTSCTS_TVB 2
#define CRTSCTS_INKA 3
	int method = CRTSCTS_RS485;
	ioctl(fd,TIOCMSFLOWCTRL,&method);

(and the converse TIOCMGFLOWCTRL)?

Regards,
Samuel

Re: [patch 3/4] new serial flow control

[Samuel Thibault]

Samuel Thibault, le Sun 09 Oct 2005 00:27:11 +0200, a écrit :
> > So, we now seem to have:
> > 
> > 	Standard flow control
> > 	CTVB flow control
> > 	RS485 RTS flow control
> 
> Let's add a new one: Inka braille devices, which uses RTS/CTS as
> acknowledge strobes for each character.

Hmm: and there is DTR/DSR flow control too.

Regards,
Samuel

Re: [patch 3/4] new serial flow control

[Russell King]

On Sun, Oct 09, 2005 at 12:27:11AM +0200, Samuel Thibault wrote:
> Hi,
> 
> I'm re-opening a somewhat old thread about serial flow control methods:
> 
> Russell King, le Wed 05 Jan 2005 23:53:01 +0000, a ?crit :
> > we have other people
> > who want to use their on-board hardware RS485 flow control options on
> > UARTs for their application, which means we need an RS485 flow control
> > method.  (They can't select it without accessing the hardware directly.)
> > 
> > So, we now seem to have:
> > 
> > 	Standard flow control
> > 	CTVB flow control
> > 	RS485 RTS flow control
> 
> Let's add a new one: Inka braille devices, which uses RTS/CTS as
> acknowledge strobes for each character.
> 
> > I still believe that flow control should be enabled by CRTSCTS, but
> > the flow control personality set by other means.
> > 
> > Therefore, I think this requires further discussion, especially with
> > Alan (who seems to be the tty layer god now) to work out some sort of
> > reasonable interface.
> 
> How could this look like in userspace? Something like
> 
> #define CRTSCTS_RS232 0
> #define CRTSCTS_RS485 1
> #define CRTSCTS_TVB 2
> #define CRTSCTS_INKA 3
> 	int method = CRTSCTS_RS485;
> 	ioctl(fd,TIOCMSFLOWCTRL,&method);
> 
> (and the converse TIOCMGFLOWCTRL)?

I think they should be termios settings - existing programs know how
to handle termios to get what they want.  Why make the situation more
complex for them?

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

Re: [patch 3/4] new serial flow control

[Samuel Thibault]

Russell King, le Sun 09 Oct 2005 01:01:53 +0100, a écrit :
> > How could this look like in userspace?
> 
> I think they should be termios settings - existing programs know how
> to handle termios to get what they want. 

Hence a new field in the termios structure?

There was a discussion about this back in 2000:

http://marc.theaimsgroup.com/?t=96514848800003&r=1&w=2

and more precisely a remind of SVR4's termiox structure with an added
x_hflag:

http://marc.theaimsgroup.com/?l=linux-kernel&m=96523146720678&w=2

I'm not sure about how we'd want to implement that. The SVR4 approach
(orthogonal input/output flow control selection) doesn't seem right to
me: there are really peculiar flow controls that involve both ways. A
mere enumeration of possible methods might be better.

Regards,
Samuel

Re: [patch 3/4] new serial flow control

[Russell King]

On Sun, Oct 09, 2005 at 02:21:30AM +0200, Samuel Thibault wrote:
> Russell King, le Sun 09 Oct 2005 01:01:53 +0100, a ?crit :
> > > How could this look like in userspace?
> > 
> > I think they should be termios settings - existing programs know how
> > to handle termios to get what they want. 
> 
> Hence a new field in the termios structure?
> 
> There was a discussion about this back in 2000:
> 
> http://marc.theaimsgroup.com/?t=96514848800003&r=1&w=2
> 
> and more precisely a remind of SVR4's termiox structure with an added
> x_hflag:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=96523146720678&w=2
> 
> I'm not sure about how we'd want to implement that. The SVR4 approach
> (orthogonal input/output flow control selection) doesn't seem right to
> me: there are really peculiar flow controls that involve both ways. A
> mere enumeration of possible methods might be better.

What I was thinking of was to use some of the spare termios cflag bits
to select the flow control.  You'd only want one flow control type at
one time though.  Eg: define two fields, each to select the signal.

0 - RTS
1 - DTR

0 - CTS
1 - DTR
2 - DSR

You still want CRTSCTS to enable hardware flow control though - which
is what programs expect to happen with that flag enabled.  RTS/CTS
flow control would be type 0 above for compatibility with existing
programs.

However, bear in mind that the majority of the more inteligent 8250-
compatible UARTs with large FIFOs only do hardware flow control on
RTS/CTS - attempting to simulate hardware flow control on the other
signals could end up with up to 64 or 128 characters being sent after
the transmit handshake is deasserted.

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

Re: [patch 3/4] new serial flow control

[Samuel Thibault]

Hi,

Russell King, le Sun 09 Oct 2005 09:37:24 +0100, a écrit :
> On Sun, Oct 09, 2005 at 02:21:30AM +0200, Samuel Thibault wrote:
> > Russell King, le Sun 09 Oct 2005 01:01:53 +0100, a ?crit :
> > > > How could this look like in userspace?
> > > 
> > > I think they should be termios settings - existing programs know how
> > > to handle termios to get what they want. 
> > 
> > Hence a new field in the termios structure?
> > 
> > There was a discussion about this back in 2000:
> > 
> > http://marc.theaimsgroup.com/?t=96514848800003&r=1&w=2
> 
> What I was thinking of was to use some of the spare termios cflag bits
> to select the flow control.  You'd only want one flow control type at
> one time though.  Eg: define two fields, each to select the signal.
> 
> 0 - RTS
> 1 - DTR
> 
> 0 - CTS
> 1 - DTR
> 2 - DSR

It looks fine, but it might not be sufficient for expressing that:

- some flow control use RTS to indicate that DTE is ready to send data,
- some other use it to indicate that DTE wants to send data. (and CTS is
used for acknowledgment of this),
- some other use it as a strobe for acknowledging characters, some other
use it as a strobe for acknowledging frames (announced by CTS).

> However, bear in mind that the majority of the more inteligent 8250-
> compatible UARTs with large FIFOs only do hardware flow control on
> RTS/CTS

Hardward flow control is usually performed in software. Can't their
hardware implementation of hardware flow control be disabled when
control method is not usual RTS/CTS?

Regards,
Samuel
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 3/4] new serial flow control

[Samuel Thibault]

Hi,

Russell King, le Sun 09 Oct 2005 09:37:24 +0100, a écrit :
> On Sun, Oct 09, 2005 at 02:21:30AM +0200, Samuel Thibault wrote:
> > Russell King, le Sun 09 Oct 2005 01:01:53 +0100, a ?crit :
> > > > How could this look like in userspace?
> > > 
> > > I think they should be termios settings - existing programs know how
> > > to handle termios to get what they want. 
> > 
> > Hence a new field in the termios structure?
> > 
> > There was a discussion about this back in 2000:
> > 
> > http://marc.theaimsgroup.com/?t=96514848800003&r=1&w=2
> 
> What I was thinking of was to use some of the spare termios cflag bits
> to select the flow control.  You'd only want one flow control type at
> one time though.  Eg: define two fields, each to select the signal.
> 
> 0 - RTS
> 1 - DTR
> 
> 0 - CTS
> 1 - DTR
> 2 - DSR

It looks fine, but it might not be sufficient for expressing that:

- some flow control use RTS to indicate that DTE is ready to send data,
- some other use it to indicate that DTE wants to send data. (and CTS is
used for acknowledgment of this),
- some other use it as a strobe for acknowledging characters, some other
use it as a strobe for acknowledging frames (announced by CTS).

> However, bear in mind that the majority of the more inteligent 8250-
> compatible UARTs with large FIFOs only do hardware flow control on
> RTS/CTS

Hardward flow control is usually performed in software. Can't their
hardware implementation of hardware flow control be disabled when
control method is not usual RTS/CTS?

Regards,
Samuel

Re: [patch 3/4] new serial flow control

[Russell King]

On Sun, Oct 09, 2005 at 12:09:09PM +0200, Samuel Thibault wrote:
> Russell King, le Sun 09 Oct 2005 09:37:24 +0100, a ?crit :
> > What I was thinking of was to use some of the spare termios cflag bits
> > to select the flow control.  You'd only want one flow control type at
> > one time though.  Eg: define two fields, each to select the signal.
> > 
> > 0 - RTS
> > 1 - DTR
> > 
> > 0 - CTS
> > 1 - DTR
> > 2 - DSR
> 
> It looks fine, but it might not be sufficient for expressing that:
> 
> - some flow control use RTS to indicate that DTE is ready to send data,
> - some other use it to indicate that DTE wants to send data. (and CTS is
> used for acknowledgment of this),

Agreed - and that's one extra bit of control information.

> - some other use it as a strobe for acknowledging characters, some other
> use it as a strobe for acknowledging frames (announced by CTS).

The last has no business being in the serial driver though - the driver
knows nothing about frames of characters.  It's more a userland (in
which case it's TIOCM* ioctls) or ldisc issue (tty_driver->tiocmset).

> > However, bear in mind that the majority of the more inteligent 8250-
> > compatible UARTs with large FIFOs only do hardware flow control on
> > RTS/CTS
> 
> Hardward flow control is usually performed in software. Can't their
> hardware implementation of hardware flow control be disabled when
> control method is not usual RTS/CTS?

You missed the point.  Of course the hardware flow control can be
disabled.  However, if you do have on-chip CTS flow control disabled
with UARTs with large FIFOs, and remote end says "stop sending", the
characters already in the FIFO will be sent, which may be up to
64 or even 128 characters instead of the usual 16 or so with the
16550A.  If the remote end only has room for 32 more characters,
you're into an overrun condition at every "stop sending" event.

Hence, people must expect a DTR/DSR software-based hardware flow
control to be less reliable than using RTS/CTS (with an adapter to
swap the RTS/CTS pins for DTR/DSR) with advanced 8250-based UARTs.

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

Re: [patch 3/4] new serial flow control

[Samuel Thibault]

Hi,

Russell King, le Sun 09 Oct 2005 12:17:18 +0100, a écrit :
> On Sun, Oct 09, 2005 at 12:09:09PM +0200, Samuel Thibault wrote:
> > - some other use it as a strobe for acknowledging characters, some other
> > use it as a strobe for acknowledging frames (announced by CTS).
> 
> The last has no business being in the serial driver though -
> the driver knows nothing about frames of characters.  It's more
> a userland (in which case it's TIOCM* ioctls) or ldisc issue
> (tty_driver->tiocmset).

In principle, yes. But implementing it in userland is not responsive
enough doesn't work reliably, while it can actually be implemented in
the serial driver as "acknowledge any CTS upfront" (if the device is not
throttled), and then it works fine. Writing a whole line discipline (and
getting it accepted in the kernel) just for this is a bit overkill.

> > > However, bear in mind that the majority of the more inteligent 8250-
> > > compatible UARTs with large FIFOs only do hardware flow control on
> > > RTS/CTS
> > 
> > Hardward flow control is usually performed in software. Can't their
> > hardware implementation of hardware flow control be disabled when
> > control method is not usual RTS/CTS?
> 
> You missed the point.  Of course the hardware flow control can be
> disabled.  However, if you do have on-chip CTS flow control disabled
> with UARTs with large FIFOs,
> etc..

Yes, of course. But can't this be disabled too? (people won't mind cpu
overhead if they can at least get their device working).

Regards,
Samuel
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 3/4] new serial flow control

[Samuel Thibault]

Hi,

Russell King, le Sun 09 Oct 2005 12:17:18 +0100, a écrit :
> On Sun, Oct 09, 2005 at 12:09:09PM +0200, Samuel Thibault wrote:
> > - some other use it as a strobe for acknowledging characters, some other
> > use it as a strobe for acknowledging frames (announced by CTS).
> 
> The last has no business being in the serial driver though -
> the driver knows nothing about frames of characters.  It's more
> a userland (in which case it's TIOCM* ioctls) or ldisc issue
> (tty_driver->tiocmset).

In principle, yes. But implementing it in userland is not responsive
enough doesn't work reliably, while it can actually be implemented in
the serial driver as "acknowledge any CTS upfront" (if the device is not
throttled), and then it works fine. Writing a whole line discipline (and
getting it accepted in the kernel) just for this is a bit overkill.

> > > However, bear in mind that the majority of the more inteligent 8250-
> > > compatible UARTs with large FIFOs only do hardware flow control on
> > > RTS/CTS
> > 
> > Hardward flow control is usually performed in software. Can't their
> > hardware implementation of hardware flow control be disabled when
> > control method is not usual RTS/CTS?
> 
> You missed the point.  Of course the hardware flow control can be
> disabled.  However, if you do have on-chip CTS flow control disabled
> with UARTs with large FIFOs,
> etc..

Yes, of course. But can't this be disabled too? (people won't mind cpu
overhead if they can at least get their device working).

Regards,
Samuel

Re: [patch 3/4] new serial flow control

[Samuel Thibault]

Samuel Thibault, le Sun 09 Oct 2005 13:33:13 +0200, a écrit :
> 
> Russell King, le Sun 09 Oct 2005 12:17:18 +0100, a écrit :
> > > Hardward flow control is usually performed in software. Can't their
> > > hardware implementation of hardware flow control be disabled when
> > > control method is not usual RTS/CTS?
> > 
> > You missed the point.  Of course the hardware flow control can be
> > disabled.  However, if you do have on-chip CTS flow control disabled
> > with UARTs with large FIFOs,
> > etc..
> 
> Yes, of course. But can't this be disabled too?

(I mean, the FIFOs)
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 3/4] new serial flow control

[Samuel Thibault]

Samuel Thibault, le Sun 09 Oct 2005 13:33:13 +0200, a écrit :
> 
> Russell King, le Sun 09 Oct 2005 12:17:18 +0100, a écrit :
> > > Hardward flow control is usually performed in software. Can't their
> > > hardware implementation of hardware flow control be disabled when
> > > control method is not usual RTS/CTS?
> > 
> > You missed the point.  Of course the hardware flow control can be
> > disabled.  However, if you do have on-chip CTS flow control disabled
> > with UARTs with large FIFOs,
> > etc..
> 
> Yes, of course. But can't this be disabled too?

(I mean, the FIFOs)

Re: [patch 3/4] new serial flow control

[Alan Cox]

On Sul, 2005-10-09 at 13:44 +0200, Samuel Thibault wrote:
> > Yes, of course. But can't this be disabled too?
> 
> (I mean, the FIFOs)

In the USB case generally not. Also many high end devices are polled
with big buffers and have no IRQ support. It works for the 16x50s that
are most PCs today however and that is enough IMHO to be relevant for
now (next gen PC's probably won't have serial of course)

Re: [patch 3/4] new serial flow control

[Samuel Thibault]

Russell King, le Sun 09 Oct 2005 09:37:24 +0100, a écrit :
> the majority of the more inteligent 8250- compatible UARTs with large
> FIFOs only do hardware flow control on RTS/CTS

BTW, nobody tried to use hardware implementation of software flow
control? (UART_(XON/XOFF)[12] of TI16C752, ST16650, ST16650A, ST16654
UARTs).

Regards
Samuel
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 3/4] new serial flow control

[Samuel Thibault]

Russell King, le Sun 09 Oct 2005 09:37:24 +0100, a écrit :
> the majority of the more inteligent 8250- compatible UARTs with large
> FIFOs only do hardware flow control on RTS/CTS

BTW, nobody tried to use hardware implementation of software flow
control? (UART_(XON/XOFF)[12] of TI16C752, ST16650, ST16650A, ST16654
UARTs).

Regards
Samuel

Re: [patch 3/4] new serial flow control

[Russell King]

On Sun, Oct 09, 2005 at 12:27:11AM +0200, Samuel Thibault wrote:
> Hi,
> 
> I'm re-opening a somewhat old thread about serial flow control methods:
> 
> Russell King, le Wed 05 Jan 2005 23:53:01 +0000, a ?crit :
> > we have other people
> > who want to use their on-board hardware RS485 flow control options on
> > UARTs for their application, which means we need an RS485 flow control
> > method.  (They can't select it without accessing the hardware directly.)
> > 
> > So, we now seem to have:
> > 
> > 	Standard flow control
> > 	CTVB flow control
> > 	RS485 RTS flow control
> 
> Let's add a new one: Inka braille devices, which uses RTS/CTS as
> acknowledge strobes for each character.
> 
> > I still believe that flow control should be enabled by CRTSCTS, but
> > the flow control personality set by other means.
> > 
> > Therefore, I think this requires further discussion, especially with
> > Alan (who seems to be the tty layer god now) to work out some sort of
> > reasonable interface.
> 
> How could this look like in userspace? Something like
> 
> #define CRTSCTS_RS232 0
> #define CRTSCTS_RS485 1
> #define CRTSCTS_TVB 2
> #define CRTSCTS_INKA 3
> 	int method = CRTSCTS_RS485;
> 	ioctl(fd,TIOCMSFLOWCTRL,&method);
> 
> (and the converse TIOCMGFLOWCTRL)?

I think they should be termios settings - existing programs know how
to handle termios to get what they want.  Why make the situation more
complex for them?

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

Re: [patch 3/4] new serial flow control

[Samuel Thibault]

Hi,

I'm re-opening a somewhat old thread about serial flow control methods:

Russell King, le Wed 05 Jan 2005 23:53:01 +0000, a écrit :
> we have other people
> who want to use their on-board hardware RS485 flow control options on
> UARTs for their application, which means we need an RS485 flow control
> method.  (They can't select it without accessing the hardware directly.)
> 
> So, we now seem to have:
> 
> 	Standard flow control
> 	CTVB flow control
> 	RS485 RTS flow control

Let's add a new one: Inka braille devices, which uses RTS/CTS as
acknowledge strobes for each character.

> I still believe that flow control should be enabled by CRTSCTS, but
> the flow control personality set by other means.
> 
> Therefore, I think this requires further discussion, especially with
> Alan (who seems to be the tty layer god now) to work out some sort of
> reasonable interface.

How could this look like in userspace? Something like

#define CRTSCTS_RS232 0
#define CRTSCTS_RS485 1
#define CRTSCTS_TVB 2
#define CRTSCTS_INKA 3
	int method = CRTSCTS_RS485;
	ioctl(fd,TIOCMSFLOWCTRL,&method);

(and the converse TIOCMGFLOWCTRL)?

Regards,
Samuel
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html