USART with flow control

[Gerardo GALLUCCI]

Posted on October 01, 2010 at 11:22

USART with flow control

[trevor23]

Posted on May 17, 2011 at 14:09

No, RTS is active low (as all UART TTL signals are). It is low to tell the other end that it is OK for it to send data to us -- it has nothing to do with transmission only receiving. CTS from the other end is low to tell us that it is OK for us to send data (we must not send when CTS is high). At RS232 levels the signals are inverted which might be the reason for your confusion.

Regards Trevor.

[Gerardo GALLUCCI]

Posted on May 17, 2011 at 14:09

Thanks Trevor for the help 😉

so, if i'm right now, RTS has to be ''always'' low, even during the stop bit.. I'm using an STM32 as host (and a bluetooth module). STM32 sends ''x'', and the module answers ''AT-AB ErrFormat'' as you can see, during STM32's transmission, its RTS is always low; during module's transmission, at the end of every byte, its RTS go up (on every stop bit,i think) may it depend from module's implementation, different from mine?

[trevor23]

Posted on May 17, 2011 at 14:09

''so, if i'm right now, RTS has to be ''always'' low, even during the stop bit.''

Yes ''may it depend from module's implementation, different from mine?'' No idea, as I don't know anything about the bluetooth device you are using. It could be that it can only deal with one byte at a time so when it receives a byte it raises its RTS (your CTS) while it processes that byte to stop you sending another byte untill it is ready (because it has no serial buffers). This is pretty horrible but I have seen it many times in the past.

[Tesla DeLorean]

Posted on May 17, 2011 at 14:09

I'm using modems, and ended up trying CTS/RTS in a combination of hardware/software modes (ie in USART, and/or via GPIO) to get things working the way I wanted. I was also using interrupts, and significantly larger ring buffers behind the USART. As Trevor points out the implementation is awfully simplistic, and I think it could have done with a hardware FIFO.

There is also an errata on one of the RTS/CTS pairs with one of the CAN buses that share the same pins, and you have to park the CAN somewhere else using remapping. I don't remember the exact details, but it did frustrate development, as the unclock CAN was holding one of the pins preventing normal operation.