tcflow(TCOON/TCOOFF) vs. received XON/XOFF characters

tcflow(TCOON/TCOOFF) vs. received XON/XOFF characters

[Grant Edwards]

I'm working on the regression test appliction I use to test the serial
drivers I maintain, and I've run into a problem with interaction
between tcflow(TCOON/TCOOFF) and XON/XOFF using bog-standard 16x50
UARTs and the normal in-kernel driver.

When I call tcflow(TCOOFF) on a tty device and then write data to that
tty device, the data isn't sent. That's what I expect. But, when an
XON is then received by that port, it does not start the tx data.

Conversly, when a serial port receives an XOFF, it stops sending
data as it should, but a subsequent call to tcflow(TCOON) does not
casue it to start sending data.

Am I misunderstanding how tcflow(TCOxxx) is supposed to interact with
XON/XOFF flow control?

Or is something broken in the tty layer or uart driver?

-- 
Grant Edwards               grant.b.edwards        Yow! This is a NO-FRILLS
                                  at               flight -- hold th' CANADIAN
                              gmail.com            BACON!!

Re: tcflow(TCOON/TCOOFF) vs. received XON/XOFF characters

[Peter Hurley]

On 07/16/2014 01:20 PM, Grant Edwards wrote:
> I'm working on the regression test appliction I use to test the serial
> drivers I maintain, and I've run into a problem with interaction
> between tcflow(TCOON/TCOOFF) and XON/XOFF using bog-standard 16x50
> UARTs and the normal in-kernel driver.
>
> When I call tcflow(TCOOFF) on a tty device and then write data to that
> tty device, the data isn't sent. That's what I expect. But, when an
> XON is then received by that port, it does not start the tx data.
>
> Conversly, when a serial port receives an XOFF, it stops sending
> data as it should, but a subsequent call to tcflow(TCOON) does not
> casue it to start sending data.
>
> Am I misunderstanding how tcflow(TCOxxx) is supposed to interact with
> XON/XOFF flow control?
>
> Or is something broken in the tty layer or uart driver?

tcflow(TCOxxx) flow control is independent of IXON flow control.
The union of both flow states determines if the tty can output;

                      IXON = true        IXON = false
                   START       STOP
tcflow(TCOON)      on         off          on
tcflow(TCOOFF)     off        off          off

Regards,
Peter Hurley

PS - The various flow states are not SMP-safe. I'm working to correct that.

Re: tcflow(TCOON/TCOOFF) vs. received XON/XOFF characters

[Grant Edwards]

On 2014-07-17, Peter Hurley <peter@hurleysoftware.com> wrote:

> tcflow(TCOxxx) flow control is independent of IXON flow control.
> The union of both flow states determines if the tty can output;
>
>                       IXON = true        IXON = false
>                    START       STOP
> tcflow(TCOON)      on         off          on
> tcflow(TCOOFF)     off        off          off

Thanks, that's pretty much what I had decided based on tests and
browsing the source code.

Just to confirm:

  tcflow(TCION/TCIOFF): overrides the "input" side of xon/xoff flow
                        control and forces the sending of XON/XOFF.

  tcflow(TCOON/TCOOFF): does not have anything to do with the "output"
                        side of xon/xoff flow control, but controls
                        something completely orthogonal.

That rather counter-intuitive (not that counter-intuitive is exactly a
novel thing when it comes to Unix serial ports).
                        
That rasies this question: what does an application use to control the
"output" side of xon/xoff flow control?  There is a Windows API for
doing that, and I get asked how to do it in Linux.  I always tell them
they can't.

-- 
Grant Edwards               grant.b.edwards        Yow! Oh, I get it!!
                                  at               "The BEACH goes on", huh,
                              gmail.com            SONNY??

Re: tcflow(TCOON/TCOOFF) vs. received XON/XOFF characters

[Peter Hurley]

On 07/17/2014 10:03 AM, Grant Edwards wrote:
> On 2014-07-17, Peter Hurley <peter@hurleysoftware.com> wrote:
>
>> tcflow(TCOxxx) flow control is independent of IXON flow control.
>> The union of both flow states determines if the tty can output;
>>
>>                        IXON = true        IXON = false
>>                     START       STOP
>> tcflow(TCOON)      on         off          on
>> tcflow(TCOOFF)     off        off          off
>
> Thanks, that's pretty much what I had decided based on tests and
> browsing the source code.
>
> Just to confirm:
>
>    tcflow(TCION/TCIOFF): overrides the "input" side of xon/xoff flow
>                          control and forces the sending of XON/XOFF.
>
>    tcflow(TCOON/TCOOFF): does not have anything to do with the "output"
>                          side of xon/xoff flow control, but controls
>                          something completely orthogonal.
>
> That rather counter-intuitive (not that counter-intuitive is exactly a
> novel thing when it comes to Unix serial ports).
>
> That rasies this question: what does an application use to control the
> "output" side of xon/xoff flow control?  There is a Windows API for
> doing that, and I get asked how to do it in Linux.  I always tell them
> they can't.

I didn't explain this properly.

Both tcflow(TCOxxx) and receiving START/STOP when IXON == true control
the output flow.

For example,

     ttyS0 = open("/dev/ttyS0", O_RDWR);

     /* Disable ttyS0 output */
     tcflow(ttyS0, TCOOFF);

     /* writes to ttyS0 will now be buffered but not sent */

     /* remote terminal sends START which is received, however sending is
      * still disabled by tcflow()
      */

     /* Enable ttyS0 output */
     tcflow(ttyS0, TCOON);

     /* ttyS0 output enabled, previously buffered writes are now sent */

     /* remote terminal sends STOP which is received and ttyS0 output
      * is now disabled (writes to ttyS0 will be buffered but not sent)
      */

     tcflow(ttyS0, TCOON);  <--- has no effect because flow was not previously
                                 disabled by tcflow()

     /* remote terminal sends START which is received and ttyS0 output
      * is now enabled, previously buffered writes are now sent
      */


I did gloss over one special case:  tcflow(TCOON) will re-enable output
_even if the remote terminal last sent STOP_ but only if output is also
disabled by tcflow(TCOOFF).

To me, the separate state tracking of tcflow() and START/STOP makes sense.

Regards,
Peter Hurley