UART/Serial Flow Control Documentation

Status
Not open for further replies.
Hi there
I've been curious to know if the documentation available here: https://www.pjrc.com/teensy/td_uart.html is misleading.

Specifically the sections labeled:

Code:
Serial1.attachRts(pin)
Serial1.attachCts(pin)

I believe the descriptions need to be swapped. Such that when the RTS pin goes high, teen will pause transmission, and when CTS pin goes high, its expected that the connected other device will pause it's transmission.
Could someone confirm this observation? Or am I misunderstanding some perspective here :)
Thanks!


Code:
Serial1.attachRts(pin)
Enable RTS flow control. The specified pin becomes an output. Low indicates the Teensy is ready to recieve data. High is a request for the other device to pause transmission. RTS is driven high before Teensy's receive buffer is full, to allow tolerance for devices which do not immediately pause transmission in response to RTS.
This function must be called after Serial1.begin();

The RTS output from Teensy should be connected to the CTS input on the other serial device, similarly to the TX output connecting to the other device's RX input. Do not simply connect same-named signals with serial.

Supported only on Teensy LC, 3.0 - 3.6. Any digital pin may be used.

Code:
Serial1.attachCts(pin)
Enable CTS flow control. When this pin is driven high, Teensy will pause transmission after the currently transmitting byte (if any) is completed.
This function must be called after Serial1.begin();

The CTS input from Teensy should be connected to the RTS output on the other serial device, similarly to the RX input connecting to the other device's TX output. Do not simply connect same-named signals with serial.

Supported only on Teensy 3.0 - 3.6. Only specific pins may be used.
 
The write up at the link looks correct. RTS is an output and is wired to CTS on the other end. When you assert RTS, it means send me data.
CTS is an input and is wired to RTS on the other end. When you see CTS asserted, you can send data, otherwise you stop.
 
Might be worth mentioning RS-232 has a long history of not-so-consistent signal naming.

Back in the early 1990s when dialup modems were common, using 9 or 25 pin D-sub connectors, it was common practice to label the modem pinout with the same names as the PC. For example, pin 2 on the 9 pin connector was usually called "RX" or "RXD" on both PC and modem, even through the modem actually transmitted on pin 2.

The conventions around the handshake signals changed over time. In more modern usage, RTS & CTS were used to control the flow of data, and DTR & DSR were used to indicate the presence of a device ready to be used. Many modems would hang up the phone line if DTR was de-asserted.

But in earlier times, like the 1970s and 1980s, terminals and mainframes used the handshakes differently. I'm not familiar with the details.

Of course the signal levels are inverted from RS-232 and TTL/logic level, and some documents still speak of "mark" and "space" or other terminology that's not always easy to match up with how the signals really work.

Before the IBM PC used 9 pins, different manufacturers would use different gender connectors and sometimes even different pinouts for some of the handshakes.

On top of all that, numerous devices have appeared over the years with incorrect documentation or even their own strange usage not following any of the established conventions.

That all adds up to a mountain of confusing & sometimes contradictory info about what these signals really mean.
 
Status
Not open for further replies.
Back
Top