Great explanation! Thanks Mr Nutt 😊 Em qui., 11 de mar. de 2021 às 13:38, Gregory Nutt <spudan...@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. > > >
