Silicon bug in USART RTS pin?

castillo · ‎2010-12-23

Posted on December 23, 2010 at 17:55

Tesla DeLorean · ‎2011-05-17

Posted on May 17, 2011 at 14:19

The state of RTS is driven by the RXNE status of a functional receiver, not the RE bit. ie you leave the receiver hanging with data still pending in the receive buffer.

For the control you desire, driving the RTS pin directly as a GPIO, based on your *applications* need(s) would be the way to go.

The only CTS/RTS silicon bug I'm aware of is one where they clash with some CAN pins, which is fixed by remapping the unused CAN peripheral off the pins. (PA.11 and PA.12 per the errata, which may/may not effect your part)

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

castillo · ‎2011-05-17

Posted on May 17, 2011 at 14:19

Thanks for the soon answer.

That's what I was afraid of. The problem with that approach is that you always need a pending byte in the data register to stop receiving data. I think this is not a good point, specially if you work with interrupts, because nobody interrupts the CPU since that byte is already pending, and data would wait forever in the USART register.

Anyway, I will try with GPIO as you say.

Regards.

Tesla DeLorean · ‎2011-05-17

Posted on May 17, 2011 at 14:19

The system you describe sounds quite capable of receiving data all the time. If software buffering issues, or other processes, require the data to be throttled, that's something outside purview the USART. The same processes that determine if the RTS should be active/in-active, or deals with the buffering, is the place to check the USART for pending data, and re-enable interrupts, etc.

Enabling/disabling the receive interrupt might also achieve your goal.

What is happening that requires RTS to throttle incoming data?

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