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 ?
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.
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.
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.
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.
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.