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.
