I am currently working on a project where we use TIVA C TM4C123G and I am currently getting inspired by launchpad as reference design. I have several UART peripheral to connect to the main chip using UART, however on the pins of the chip RTS and CTS are only marked on the UART1. How I am supposed to deal with this ?
\$\begingroup\$
\$\endgroup\$
3
-
1\$\begingroup\$ Have you looked online to determine the purpose of the RTS and CTS pins? Look at that and you should get some insight into their requirements for any given application. \$\endgroup\$– nanofaradMay 25, 2016 at 14:20
-
1\$\begingroup\$ If you will use RS485 then you will need RTS signal to switch between receive/transmit. \$\endgroup\$– Marko BuršičMay 25, 2016 at 16:34
-
2\$\begingroup\$ You need something to enable an RS485 transceiver, but that doesn't have to be the RTS line. Using the RTS line is just a sort of common hack - "it's there, we can control it in software, let's use it!" But on an embedded system there are typically many GPIOs meeting that definition too. \$\endgroup\$– Chris StrattonMay 26, 2016 at 6:59
Add a comment
|
5 Answers
\$\begingroup\$
\$\endgroup\$
1
You may be able to just ignore these signals. CTS (Clear To Send) and RT (Request To Send) provide a handshaking mechanism so that each device can tell the other when it's ready to receive data.
However, many Uarts don't implement this and either assume the other end can take data at any time or use another method such as XON/XOFF
Hardware handshaking with RTS/CTS is not used very often on modern equipment but you will need to check the manual, a few devices still require it.
-
\$\begingroup\$ Thank you for your answer, this comfort me a bit in the possibility to implement without using RTS and CTS. I was thinking that I could potentially link those line to some normal GPIO, just in case I would need to make an update latr by just implementing RTS and CTS on software by bitbanging GPIO with RTS and CTS, but i am not sure if it would work or not..? \$\endgroup\$ May 25, 2016 at 14:57
\$\begingroup\$
\$\endgroup\$
7
It depends on what kind of "flow-control" your (unidentified) "several UART peripherals" use. It also depends on whether you need simultaneous communication with your peripherals, and whether they need to be able to asynchronously "interrupt" the controller, or whether they will be polled and only "speak when spoken to". These are all part of the overall system design which is a larger issue than the narrow issue you asked about.
answered May 25, 2016 at 14:33
-
\$\begingroup\$ Thank you for your answer. The devices are typically: GSM module, RS485 transceiver or CAN transceiver. I am a bit new to those so I am unclear about if I can peacefully draw schematic and pcb layout without having those RTS and CTS line between the peripherals and the MCU \$\endgroup\$ May 25, 2016 at 14:55
-
2\$\begingroup\$ You can't answer the question about using RTS and CTS without FIRST designing the larger concept of how the whole system will work and how the pieces will talk to each other. RTS and CTS are only parts of the solution. You haven't established the communication control protocol yet, so you don't know how (or IF) you will need RTS and CTS. \$\endgroup\$ May 25, 2016 at 14:59
-
-
1\$\begingroup\$ Start back at the beginning and establish HOW you need to communicate to these peripherals. It sounds like you have not yet done a proper system design. \$\endgroup\$ May 25, 2016 at 15:27
-
2\$\begingroup\$ You need to make LARGER PLANS of HOW the software will work. How often it needs to communicate with the peripherals. Whether it will initiate communication, or whether it must accept input on demand. There are dozens of system architecture questions which must be resolved before you get to RTS/CTS. \$\endgroup\$ May 25, 2016 at 16:52
\$\begingroup\$
\$\endgroup\$
RTS and CTS is only allows you to have the flow control.. perhaps i am using an FTDI chip which translates USB to UART flows... here are 4 methods of flow control that can be programmed for the FT232BM device.
None - this may result in data loss at high speeds
RTS/CTS - 2 wire handshake. The device will transmit if CTS is active and will drop RTS if it cannot receive any more.
DTR/DSR - 2 wire handshake. The device will transmit if DSR is active and will drop DTR if it cannot receive any more.
XON/XOFF - flow control is done by sending or receiving special characters. One is XOn (transmit on) the other is XOff (transmit off).
Depending on the requirement you can select... there is a command on the terminal line we can use to set or reset the flow control. Use this link for more details.
stty --file /dev/ttyUSB0 -crtscts to disable hardware flow control
stty --file /dev/ttyUSB0 crtscts to enable hardware flow control.
stty -F /dev/ttyUSB0 -crtscts ixon ixoff to disable hw flow enable software xon and xoff.
\$\begingroup\$
\$\endgroup\$
Hardware support for RTS/CTS can be advantageous and sometimes necessary, depending upon how much "advance notice" a device can give of when it needs a transmitting device to hold off. If a receiving device doesn't have hardware support for automatically releasing RTS, it will need to be able to ensure that it's always able to service any incoming characters before the hardware buffer can overflow. If a device doesn't have hardware support for holding off on CTS, then it will have to avoid feeding the UART more characters than the receiver would be able to handle after releasing RTS.
If both transmitter and receiver include hardware support for RTS/CTS, they will be able to communicate reliably even if the receiver has only a single-character buffer and the receiver software may sometimes take awhile to respond to incoming data (if the receiver would drop data upon receiving the second complete byte, it would have to release RTS as while it is receiving the first, which would degrade performance; if it wouldn't drop data unless/until the start bit of a third byte arrives, it could leave RTS asserted until it is receiving the second). If the receiver lacks hardware RTS support, reliable communication will not be possible unless the receiver buffer can hold everything that might arrive while it is unable to respond to incoming data (e.g. because it's too busy with higher-priority interrupts). If the receiver has hardware support but the sender doesn't, reliable communication will be possible but only if the sender software paces itself so it never gives the UART more data than can safely be transmitted.
In chips with PLD-like functionality on some of the pins, it may be possible to fudge crude RTS support in chips which don't have real hardware support by programming an output to automatically latch high any time the serial receive pin is low. That would have the effect of causing the receiver to start reporting itself unready any time a transmission begins. Once software receives a byte, it would then be able to reassert CTS to let the sender know it can transmit another byte. Performance using such an approach would likely be bad, but if a device which has neither hardware RTS support nor the ability to guarantee good interrupt response times needs to receive data from a device that stops data immediately when its CTS (the receiver's RTS) is released, such an approach could allow reliable operation.
Another approach that might sometimes be useful in cases where a device will be responsive and non-responsive at predictable intervals (e.g. because it periodically performs some task that requires 100% CPU, with no interruption, for milliseconds at a time) is to have a device release RTS any time it's about to enter a non-responsive state regardless of whether its receive buffer would be ready to accept some data. The biggest problem with this approach is that if one device is only ready to receive data during certain times, and another only checks whether it's ready to receive data at certain times, no data will get sent unless those times coincide.
Personally, I consider hardware RTS/CTS support a valuable feature, but a lot of chip makers don't seem to. Fortunately, FTDI USB-to-serial chips respond very well to those signals (others may as well, but I've not tested them), making it possible for a device without hardware RTS/CTS support to request one byte at a time by asserting RTS briefly (I'm not sure what the minimum width would be) whenever the receiver software checks for an incoming byte and releasing it shortly thereafter. This will work reliably provided RTS is never accidentally asserted for more than one character interval at a time.
\$\begingroup\$
\$\endgroup\$
0
RTS and CTS are not necessary. RX and TX is enough if you do all flow control in software.
For example: RTS can be used if you have an RS-485 transceiver (that can only transmit or receive at a time) to automatically disable the receiver and enable the transmitter when you want to send something.
If your MCU does not have hardware RTS you could also do the same with a GPIO and a piece of code.
