You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Sara da Cunha Monteiro de Souza <sa...@gmail.com> on 2021/03/11 13:38:48 UTC

Discussion regarding termios support in NuttX.

Hi all,

I've been implementing termios support for ESP32-C3 and I noticed a couple
of things that left me curious about.

1.  tcgetsid() and tcsendbreak() interfaces are declared but never defined
in NuttX. Why?
2. I noticed no chip implemented the TCXONC ioctl required by tcflow()
interface.
Is there a strong reason for that? Should it be implemented at upper half
level (serial.c) or lower half level? How would it be implemented?

Thanks in advance!

Sara

Re: Discussion regarding termios support in NuttX.

Posted by Sara da Cunha Monteiro de Souza <sa...@gmail.com>.
Great explanation!
Thanks Mr Nutt
😊

Em qui., 11 de mar. de 2021 às 13:38, Gregory Nutt <sp...@gmail.com>
escreveu:

>
> > 1.  tcgetsid() and tcsendbreak() interfaces are declared but never
> defined
> > in NuttX. Why?
>
> Prototypes for those functions are required to be in termios.h whether
> they are implemented or not.
> https://pubs.opengroup.org/onlinepubs/7908799/xsh/termios.h.html
>
> Of course it would be better if they were implemented.
>
> No that there is another way to send a break using the TIOCSBRK and
> TIOCCBRK ioctl commands.  That is support by several MCUs under arch/.
> I imagine that tcsendbreak() would just be wrapper around these ioctl
> commands.
>
> tcgetsid() returns the session ID of the TTY.  There is no such thing in
> NuttX (since there are no controlling terminals) so that would be a lot
> more effort to implement.
>
> > 2. I noticed no chip implemented the TCXONC ioctl required by tcflow()
> > interface.
> >
> > Is there a strong reason for that?
> No one has needed it.  If you need it, implement it.
> > Should it be implemented at upper half
> > level (serial.c) or lower half level? How would it be implemented?
>
> NOTE that TCXONC implements software XON/XOFF flow control.  That would
> be implemented in the upper half driver (serial.c) since software flow
> control does not involve the hardware in any way.
>
> I don't know of anyone who has ever needed software flow control.  Most
> people use hardware flow control and that is controlled via:
>
>   * CONFIG_SERIAL_IFLOWCONTROL
>   * CONFIG_SERIAL_OFLOWCONTROL
>   * CONFIG_SERIAL_TERMIOS
>   * Ioctl commands TCSETS, TCGETS
>
> These configure to set the value of output pins at the serial interface
> when the Rx FIFO is full.  This is minimally useful on MCUs that have
> very tiny Rx FIFOs like the STM32.  For the STM32, there is a kludge to
> implement custom, non-standard flow control:
>
>       9278 config STM32_FLOWCONTROL_BROKEN
>       9279         bool "Use Software UART RTS flow control"
>       9280         default n
>       9281         ---help---
>       9282                 Enable UART RTS flow control using Software.
>     Because STM
>       9283                 Current STM32 have broken HW based RTS
>     behavior (they assert
>       9284                 nRTS after every byte received)  Enable this
>     setting workaround
>       9285                 this issue by using software based management
>     of RTS
>
> Tranditional hardware IFLOW control is kind of useless since it only
> uses the Rx FIFO and does not account for the fact that there may be
> plenty of buffer space still available in the serial.c Rx buffer.
>
>
>

Re: Discussion regarding termios support in NuttX.

Posted by Gregory Nutt <sp...@gmail.com>.
> 1.  tcgetsid() and tcsendbreak() interfaces are declared but never defined
> in NuttX. Why?

Prototypes for those functions are required to be in termios.h whether 
they are implemented or not. 
https://pubs.opengroup.org/onlinepubs/7908799/xsh/termios.h.html

Of course it would be better if they were implemented.

No that there is another way to send a break using the TIOCSBRK and 
TIOCCBRK ioctl commands.  That is support by several MCUs under arch/.  
I imagine that tcsendbreak() would just be wrapper around these ioctl 
commands.

tcgetsid() returns the session ID of the TTY.  There is no such thing in 
NuttX (since there are no controlling terminals) so that would be a lot 
more effort to implement.

> 2. I noticed no chip implemented the TCXONC ioctl required by tcflow()
> interface.
>
> Is there a strong reason for that?
No one has needed it.  If you need it, implement it.
> Should it be implemented at upper half
> level (serial.c) or lower half level? How would it be implemented?

NOTE that TCXONC implements software XON/XOFF flow control.  That would 
be implemented in the upper half driver (serial.c) since software flow 
control does not involve the hardware in any way.

I don't know of anyone who has ever needed software flow control.  Most 
people use hardware flow control and that is controlled via:

  * CONFIG_SERIAL_IFLOWCONTROL
  * CONFIG_SERIAL_OFLOWCONTROL
  * CONFIG_SERIAL_TERMIOS
  * Ioctl commands TCSETS, TCGETS

These configure to set the value of output pins at the serial interface 
when the Rx FIFO is full.  This is minimally useful on MCUs that have 
very tiny Rx FIFOs like the STM32.  For the STM32, there is a kludge to 
implement custom, non-standard flow control:

      9278 config STM32_FLOWCONTROL_BROKEN
      9279         bool "Use Software UART RTS flow control"
      9280         default n
      9281         ---help---
      9282                 Enable UART RTS flow control using Software.
    Because STM
      9283                 Current STM32 have broken HW based RTS
    behavior (they assert
      9284                 nRTS after every byte received)  Enable this
    setting workaround
      9285                 this issue by using software based management
    of RTS

Tranditional hardware IFLOW control is kind of useless since it only 
uses the Rx FIFO and does not account for the fact that there may be 
plenty of buffer space still available in the serial.c Rx buffer.