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.