Hi, i have a problem with my Hardware Flow Control on my STM32F103RBT6. I send a UART Signal with Polling but the STM neither sets the Signal on the USART Tx Pin nor does it set the RTS Pin. Please help me to find a solution. Thank you!

SJank.3 · ‎2022-09-24

The STM does send the Signal if i set the RTS Pin on high level per software:

USART2->CR3 |= 0x0100; //RTSE->1

The Problem is i use a three state Buffer Line Driver (74HC126D) in order to enable transmitting or receiving but the RTS Pin from the STM is from the Hardware set to a low level. Is there an Option to change that, because i need a high level to enable the transmitting.

gbm · ‎2022-09-25

Not quite sure about what you want to achieve, but the first thing to remember is that RTS is not Ready-To-Send. In reality its RTR (Ready-To-Receive) output which is normally connected to the other party CTS input. It becomes active when the receiver is ready for next frame (the double-buffered receive data register is empty).

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice

AScha.3 · ‎2022-09-25

you understand the control flow ?

RTS is on receiver side, not sender.

if understanding now ok, whats wrong ?

If you feel a post has answered your question, please click "Accept as Solution".

JPeac.1 · ‎2022-09-25

From your description it appears you are using the USART in a half-duplex, shared bus type architecture. This is very similar to RS485 except you are using tri-state instead of a differential bus. RTS/CTS flow control is designed for RS232 type architectures with a full duplex, two channel point to point wiring. The control lines are tied to managing data flow, to prevent buffer overflows. RTS informs the other side the local node has data ready to send. CTS is asserted by the remote node to indicate the local node can transmit that data without losing data.

In your configuration RTS is NOT a flow control signal. Rather it controls transmit access to the common bus. You will have to manually control the RTS state to manage line turnaround between receive and transmit, according to whatever protocol you are implementing. Do not enable hardware flow control with RTS/CTS.

You might want to research half-duplex RS485 designs, which are very similar to what you are attempting. The STM32F1 series does not have hardware support for line turnaround. You might be better off treating your RTS line as a simple GPIO output pin.

If you haven't used half-duplex shared bus before, be sure to check the USART TC transmit complete status before switching between transmit and receive line state. Remember the USART has an output buffer; using TXE transmit empty does not reflect the buffer status.

Jack Peacock

Tesla DeLorean · ‎2022-09-25

>>You might be better off treating your RTS line as a simple GPIO output pin.

+1

As I recall the F1 implementation is harsh and super clunky, compounded by the zero buffer depth and the inability of the MCU to really understand if it can sink/source data.

I personally would opt for doing the flow control via GPIO from within the buffering methods behind the UART service interrupts.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

SJank.3 · ‎2022-09-26

Jack Peacock thank you very much for your detailed help. And also thank you to the others :) I already assumed somthing like the RTS/CTS was founded to communicate between 2 or more uart ports so i decided to use the RTS output Pin as GPIO but i didnt manage to set the RTS pin to a high level yet. I will keep trying thank you again for all your answers!