• Com Port Flow Control
• Hardware Flow Control
• Hardware Flow Control Serial Port Charlotte
• Uart Hardware Flow Control

$begingroup$

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?

user768421

ControlHandShake A bitmask that specifies the control lines that the serial port uses for flow control. This member is set to zero or to the bitwise-OR or one or more of the following flags. To test the application connect two EFM32's or use the terminal with a USB-to-UART bridge. After setting up the serial port with soft-ware flow control according to the figure as below, type 20 characters, and then the EFM32 will send a 52 bytes message. Setup the Serial Port AN0059.0: UART Flow Control Software Examples.

user768421$endgroup$

8 Answers

$begingroup$

It is not data rate that matters; we use CTS / RTS (or XON / XOFF for software flow control) where a possibility of a receiver overflow exists, although admittedly that is more likely at higher data rates.

If a receiver cannot empty its buffers quickly enough, then it should deassert CTS (in response to which, the transmitter will assert RTS if there is more data to transmit).

Note that the transmitter may experience a buffer underrun in which case it should deassert RTS (because there is no valid data to send).

So it comes down to how fast the buffers can be moved - that is more likely to be an issue at higher data rates but it is completely implementation dependent; there is no single speed.

Peter SmithPeter Smith$endgroup$$begingroup$

You require some form of flow control (be that hardware or XON/XOFF) when you are transferring data at a speed greater than you can process it. It's as simple as that.

Flow control is used for one end to tell the other end 'wait a moment, I am still thinking'. Usually it is tied to a buffer being almost full (known as a 'high water mark').

MajenkoMajenko$endgroup$$begingroup$

Hardware flow control allows the communicating pieces of equipment to synchronize with each other. It allows the receiving piece of equipment to indicate that it is ready to receive the data that is being sent. If data is sent when the receiver is not 'listening', this will cause data errors.

The data rate that this occurs at will depend on a number of other things, including the type of device and software on the device. If you are connecting two PCs at 115.2K, they will likely be able to run fine. If it is two microcontrollers with other software load, they may not.

If you specify what type of devices are sending and receiving, you will receive better advice.

$endgroup$$begingroup$

The need for flow control on an asynchronous serial interface is fully dependent on the application needs. Sometimes a slower baud rate can lower the effective data rate to alleviate the need for flow control but that is again application dependent.

There are some techniques that can allow an application to function at higher baud rates without the need to use flow control handshaking. One of these is to use an interrupt driven UART send and receive technique and queue the data flow between the application mainline code and the interrupt routines through circular FIFO buffers.

The use of FIFO buffers has to be made based upon whether the application processor can handle UART interrupts at the character rate (i.e. baud_rate / bits_per_transmission_unit). If it cannot handle that interrupt rate plus the small overhead imposed by the FIFO buffer handling then it would become necessary to lower the baud rate enough to permit the interrupt rate to function.

Sometimes your application processor will have a UART that includes a hardware FIFO built in. If these are used in conjunction with a interrupt handled FIFO buffering scheme it can be beneficial for the interrupt service routine design to empty receive hardware FIFOs or fill transmit hardware FIFOs completely at interrupt time to/from the software handled FIFO buffers which would typically be larger in size. Configured and coded properly this can lower the net interrupt rate that an application processor has to handle at any particular baud rate.

Michael KarasMichael Karas$endgroup$$begingroup$

I remember when we used to use 'dumb' terminals, and you would type Ctrl+S (XOFF) to pause transmission so we could read the screen before the data scrolled off it. Then we would type Ctrl+Q (XON) to resume output. The screen might be paused for 10 minutes. It was nothing to do with the baud rate.

Com Port Flow Control

Similarly, a serial printer which was out of paper might assert hardware flow control to pause output while the paper was replaced. Again it would be nothing to do with the baud rate.

Can one still do without CTS/RTS at 115.2kbps?

I routinely send data from my ATmega328P* to a serial monitor at 115200 baud. That works fine.

_{* Arduino}

$endgroup$$begingroup$

There are many considerations.

• How big is your receive buffer?
• How quickly can the receiver empty said buffer?
• Will the receiver do things that cause it to stop looking at the buffer for some time? if so is the buffer big enough to let the receiver ride over those cases?
• If you do lose words due to receive buffer overflow how bad is it?
• If the source experiances 'back-pressure' due to flow control how bad is it?

There is no magic number for 'when do I need hardware flow control', it is a question that must be asked and answered in the context of a specific system.

Can one still do without CTS/RTS at 115.2kbps?

Many systems do, see for example the serial console ports on nearly every embedded linux board.

Peter Green

Hardware Flow Control

Peter Green

Hardware Flow Control Serial Port Charlotte

$endgroup$$begingroup$

Do you care about your data getting dropped in the bit bucket? If yes, then use flow control.

Do you have a secondary parity/ECC/flow-control like TCP has? If yes, then you are covered. However, using TCP/OSI as a model, multiple layers do error checking and control to ensure the delivery of data and to keep errors to as few as possible. Let's say your are running TCP/IP, without hardware flow control at 115.2kbps, your effective rate due to hardware flow issues could be terrible.

Dave Tweed

Uart Hardware Flow Control

♦$endgroup$$begingroup$

If target device has buffer of 16 bytes but fast interrupt is not guaranteed , then RTS/CTS is always preferred and also include odd parity bit for reliability. Without all the details, it is hard to know the threshold of target buffer overflow, so it becomes trial and error.

Sunnyskyguy EE75Sunnyskyguy EE75$endgroup$

Not the answer you're looking for? Browse other questions tagged uartflow-control or ask your own question.