ASELSTM
commented
2 years ago Hi @sdekrijger,
First, thank you for your contribution. The objective of the ReceiveToIdle APIs is to allow application to handle use cases where number of data to be received is unknown. It is useful for the UART case as communication is asynchronous, the Transmitter and Receiver don't share a clock reference. Therefore, unless a start bit detected, the receiver does not know exactly when it will receive a data.
For USART case this can be driven by the CLK synchronization signal. As long as there is data to be received as long as there is signal on the CLK pin. Once no more activity is detected on the clock line, thus reception is over. As per referenced in the reference manual :
In master mode, the SCLK pin operates in conjunction with the TX pin. Thus, the clock is provided only if the transmitter is enabled (TE=1) and data are being transmitted (USART_TDR data register written).
The clock signal can then provide an overview of the data transfer status, even if the amount of data to be received is unknown.
Hence, we do not have plans to add ReceiveToIdle APIs for the USART driver. Please allow me then to close this issue. Thank you for your comprehension and thank you once again for your contribution.
With regards,
sdekrijger
There doesn't seem to be a ReceiveToIdle API for the USART devices while there is one for UART devices. This is an issue when, in my case for board layout reasons, switching from UART to USART. The peripheral does support it, it's just missing in HAL.