At low baud rate such as 9600bps, I do not think hardware flow control CTS/RTS is necessary. I believe at higher baud rates, CTS/RTS will be necessary. What is this baud rate? Can one still do without CTS/RTS at 115.2kbps?
Flow control is a general term for a means by which an entity that wants to push information to another can avoid sending it faster than the recipient can accept. One of the earliest forms of flow control that still exists in common usage is commonly called xon/xoff; it was used in communication between teletypes, in situations where one teletype was using its paper-tape reader to send data to another teletype. Although a teletype printer could usually keep up with a paper tape reader (both operated at ten characters/second), that would be contingent upon things like an adequate supply of paper. An operator who noticed that it was necessary to replace the paper in a teletype which was receiving a transmission could type Control-S to send an XOFF character, which would ask the paper-tape reader at the other end to stop. After the paper was replaced, the operator could type Control-Q to restart the paper-tape reader. Those characters are still used to this day, although the far end of the connection will usually be a computer rather than a tape reader.
RTS/CTS protocol is a method of handshaking which uses one wire in each direction to allow each device to indicate to the other whether or not it is ready to receive data at any given moment. One device sends on RTS and listens on CTS; the other does the reverse. A device should drive its handshake-output wire low when it is ready to receive data, and high when it is not. A device that wishes to send data should not start sending any bytes while the handshake-input wire is low; if it sees the handshake wire go high, it should finish transmitting the current byte and then wait for the handshake wire to go low before transmitting any more.
Note that while devices should ideally never send more than a byte after their handshake input goes high (if the line goes high just as they start transmitting a character, they must allow that character to be transmitted completely), many PC serial ports do not comply with this even when handshaking is enabled. The serial ports allow software to detect the state of the incoming handshake wire, and expect software to decide when data should be enqueued for transmission. Unfortunately, the only way to achieve good performance with a serial port is to enqueue data for transmission slightly in advance of when it will actually be sent, and many PC serial ports will always transmit any queued-up data as fast as they can without regard for the handshake wires. Consequently, it's not uncommon for PC serial ports to send a dozen or so characters even after they've been asked to wait.
You seem to have a major misconception what "serial" means. Serial means that bits of data are transmitted serially, meaning after each other in time. The number of bits you consider a word in a serial transmission scheme has nothing at all to do with the number of wires and therefore the number of microcontroller pins needed to connect to those wire.
There are various types of serial interfaces, but RS-232 uses a single signal for each direction. The most basic RS-232 interface for bi-directional communication uses only 3 wires: TX, RX, and GND. It is common to use a protocol that logically sends 8 bits at a time, but that has nothing to do with the number of wires since each of those bits are sent in series (hence the name "serial") over the same wire.
If you want to add "hardware flow control" to the basic RS-232 interface, then you need two more wires, RTS and CTS for the bi-directional case. Some microcontrollers come with fancy enough UARTs built in that they can handle RTS and CTS directly in the hardware. On others you have to implement this in the firmware, although that's not all that hard.
Software flow control is done with in-band signalling and uses only the basic two wires, RX and TX (plus GND, but that's implied so we don't normally say that). Usually this is done by sending XOFF to tell the other side to stop sending, then XON to say it's OK to send more stuff. If your data never contains these codes otherwise, then there is nothing more you have to do. Note that XON and XOFF are in the control codes space from 0 to 31, so would not be used if the protocol is text-based. If you are using a binary protocol where all of the codes 0-255 are possible, then you usually use a escape mechanism to add back the codes used by XON and XOFF.
Keep in mind that microcontrollers can't connect directly to RS-232. The convention is for logic-level UARTs, such as included in microcontrollers, to have the RS-232 data inverted on their pins and at the normal logical level. For example, 0 V at the UART would translate to over 5 V on the RS-232 wire, and logic high (like 3.3 or 5 V) at the UART would translate to under -5 V on the RS-232 wire.
- Electronic – ATMEGA UART transmition with flow control
- Electronic – UART Flow Control
- Electronic – Is hardware flow control necessary
- Electronic – STM32 UART reliability with high baud rate
- Electronic – 8051 baud rate calculator using 16-bit timer for software UART timing
- Electronic – arduino – Implementing UART flow control in microcontroller