RFC: UART API Enhancements

[qianfan-Zhao]

Support change bandrate, parity and others

I had a discuss with @erwango about change uart's baudrate and others at runtime or configuration:

ErwanG: We have several options (update API for run time, update DTS with
a specific zephyr property (zephyr,parity = <>; ...) or both

I think the best way is we can changed baudrate and others both at runtime and configuration. Now zephyr support change bandrate in dts in this way:

current-speed = <115200>;

How about add somethings like that, eg: current-parity , current-stop-bits , current-data-bits ?

@JoeHut @ibisz
There has a way change baudrate at runtime and some uart drivers implement that, such as uart_ns16550 and uart_qmsi . How about expand line_ctrl_set to make it support change others properties ?

Hardware control like RTS and CTS also can be changed by using line_ctrl_set

RS485 mode

Many soc such as stm32f070 support 'RS-485 transceiver' mode, there should has some options in dts to make uart support RS485 mode. linux can do that in dts by using this options:

* RS485 serial communications

The RTS signal is capable of automatically controlling line direction for
the built-in half-duplex mode.
The properties described hereafter shall be given to a half-duplex capable
UART node.

Optional properties:
- rs485-rts-delay: prop-encoded-array <a b> where:
  * a is the delay between rts signal and beginning of data sent in milliseconds.
      it corresponds to the delay before sending data.
  * b is the delay between end of data sent and rts signal in milliseconds
      it corresponds to the delay after sending data and actual release of the line.
  If this property is not specified, <0 0> is assumed.
- rs485-rts-active-low: drive RTS low when sending (default is high).
- linux,rs485-enabled-at-boot-time: empty property telling to enable the rs485
  feature at boot time. It can be disabled later with proper ioctl.
- rs485-rx-during-tx: empty property that enables the receiving of data even
whilst sending data.

If the soc doesn't support hardware RS485 mode, using a GPIO simulate rts pin is a good way. Also we can add this property:

rts-gpio = <&gpioc 13 GPIO_INT_ACTIVE_LOW>;

Using ring_buffer cache uart data

If CONFIG_UART_INTERRUPT_DRIVEN was configured, there should has one tx_ringbuffer and one rx_ringbuffer to cached the data received or to be sended. This feature and ringbuffer's size can be select in Kconfig. Upper layer can recieved a signal when data arrived and decided wether or not read thats data. the tx_ringbuffer cached upper layer's data and sending them when the bus is not busy.

But some soc has hardware FIFO, I don't know if this fearure is really need.

Zephyr only supports one uart-pipe configured in dts. If you need two or more uart-pipe you need do lot of work. We should rework uart_pipe_register API to register more than one uart-pipe.

There are many shortcomings like @mike-scott said:

uart_pipe hands off the data while still in ISR -- terrible to debug and you can't do much processing before bad things happen
couldn't have more than 1 registered at a time
using a ring buffer to store UART data allowed a thread safe way of accessing the buffer from both sides.

And he rewrite a better driver in PR #6344 , I think that's a good solution.

[JoeHut]

I am also voting for changing properties like the baud rate at runtime. We have peripherals that have a quite low baud rate like 9600 per default and store changes to that only in volatile memory. Therefore we set 9600 in dts as the current_speed and use the vendor cmds for setting a higher baud rate after we reconfigured the peripheral. So there are definitely use cases.

[ibisz]

Parallel with the TX/RX ring buffer implementation it’s necessary to take in consideration the RTS/CTS hardware handshake handling too. To integrate a cellular modem over U(S)ART, for example, the above-mentioned features are compulsory together with the mentioned dynamic parameter/properties settings.

[ibisz]

Please review [RFC] WCN14A2A LTE/LTE-M Modem Driver Changes #6344

[qianfan-Zhao]

@ibisz Thanks for you that let me know #6344 , that's a good solution

[pfalcon]

Using ring_buffer cache uart data

This has now been implemented as part of #10765 . Details of the API is still being worked on (it's marked EXPERIMENTAL), implementation needs optimization, but otherwise the intended functionality is there and ready for interested parties to play with (and provide feedback, to drive further elaboration).

[erwango]

@qianfan-Zhao , I guess we can close this one since it is now available in mainline. Please reopen it if needed.