1
votes

Can anyone share with me any information on what exactly happens (or is meant to happen...) in RS232 communication when the status of the RTS or CTS line is changed?

I'm working on an application where a PC, which interfaces to the serial port via Qt's QextSerialPort library, communicates with an Atmel AVR microcontroller. From time to time the microcontroller must do things (check ADCs, time precise intervals etc.) which require it to disable its internal interrupts and therefore shut down its UART port temporarily. I'm using RTS/CTS handshaking so that the AVR can signal to the PC when it is about to close its port by putting its RTS line high, and signal the re-opening of the port by bringing RTS low again.

Basically this functions well, but I'm still unclear what is meant to happen if RTS is set high while there is a byte halfway through being transmitted in either direction. On the AVR side I can control things at a very low level, but on the PC side I just put QextSerialPort into hardware flow control mode, which causes it to do whatever the underlying Windows functions do. I'm wondering if a behavioural mismatch here may be the explanation for occasional glitches I get in the transmission.

2

2 Answers

1
votes

No, this is troublesome. RTS/CTS handshaking is implemented by the driver, not the UART. It simply stops writing bytes into the transmitter FIFO when CTS turns off. You'll have the byte in flight plus whatever is in the FIFO that can still be transmitted. This can certainly go wrong if the receiver FIFO isn't big enough and the interrupts are turned off too long. The FIFO on the PC side is typ 16 bytes, depends on hardware. Don't know about the AVR, you didn't mention a model.

Be sure to implement the buffer overrun check on the AVR side to diagnose this kind of mishap. Lowering the baud rate is a cheap workaround.

0
votes

AFIAK, the RTS line shouldn't be asserted during a byte transmission, only in the 'idle time' between characters.

problem is, handshaking is almost never implemented correctly. Windows should conform to the standard (or the wikipedia entry), but i can't confirm this.