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?
\$\begingroup\$
\$\endgroup\$
4
-
4\$\begingroup\$ It will depend on the clock speed of whatever devices you are using. \$\endgroup\$– whatsisnameCommented Aug 20, 2016 at 20:01
-
1\$\begingroup\$ NOTE: baud rate does not determine the number of characters per second that the application actually sends: It only determines the maximum number of characters per second that it can send. I've dealt with more than one application where a serial port was used for control or telemetry (as opposed to bulk data transfer), and the actual character rate was substantially less than what the baud rate would allow. \$\endgroup\$– Solomon SlowCommented Aug 21, 2016 at 1:18
-
1\$\begingroup\$ There is no one bit rate that answers your question. Much depends on the capability of the hardware (how deep are the hardware receive buffers?), on the capabilities of the CPU (interrupt latency, and raw processing speed). I worked on one application where it was a requirement to use only three wires, but the thing on one end was a laptop-class processor running an RTOS, and the thing on the other end was a big FPGA. Don't remember what bit rate we used, but 115.2 sounds like the right neighborhood. Careful design of the protocol (packets designed to fit in hardware buffers) made it work. \$\endgroup\$– Solomon SlowCommented Aug 21, 2016 at 1:27
-
1\$\begingroup\$ Flow control is necessary at any baud rate. Your question is based on a false assumption. The sender can always outrun the receiver at any baud rate. \$\endgroup\$– user207421Commented Aug 21, 2016 at 23:47
Add a comment
|
8 Answers
\$\begingroup\$
\$\endgroup\$
2
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.
answered Aug 20, 2016 at 15:27
-
2\$\begingroup\$ Size of the receive buffer (hardware FIFO) plays into this too. Say the data arrives in 32-byte bursts that occur at the repetition interval of 10 seconds. A receiver with a 64-byte FIFO can do without handshaking at high baud rates, likely. A receiver with a 16-byte FIFO will likely need handshaking above a certain baud rate where it can't relieve the FIFO quickly enough. \$\endgroup\$ Commented Aug 20, 2016 at 19:22
-
1\$\begingroup\$ @Nick: indeed. My point was that the issue is implwmentatiin dependent :) \$\endgroup\$ Commented Aug 20, 2016 at 19:38
\$\begingroup\$
\$\endgroup\$
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").
\$\begingroup\$
\$\endgroup\$
2
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.
-
1\$\begingroup\$ I would just point out that if you're connecting two pc's over a null modem, I can't think of a reason not to enable a hardware handshake. \$\endgroup\$ Commented Aug 21, 2016 at 14:47
-
\$\begingroup\$ @RubberDuck - I agree with the sentiment, but here's a reason: if one of the PCs is emulating a device that doesn't support hardware flow control. I've done this both to test software and to reverse engineer obsolete kit. \$\endgroup\$– Chris HCommented Aug 22, 2016 at 7:58
\$\begingroup\$
\$\endgroup\$
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.
answered Aug 20, 2016 at 15:29
\$\begingroup\$
\$\endgroup\$
1
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.
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
-
\$\begingroup\$ manual xon/xoff still works, I used it yesterday. \$\endgroup\$– hildredCommented Aug 22, 2016 at 2:29
\$\begingroup\$
\$\endgroup\$
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.
answered Aug 21, 2016 at 1:47
\$\begingroup\$
\$\endgroup\$
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.
\$\begingroup\$
\$\endgroup\$
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.
