10.8Is Hardware Flow Control Done by Hardware ?

Some think that hardware flow control is done by hardware but only a small part of it is done by hardware. Most of it is actually done by your operating system software. UART chips and associated hardware usually know nothing at all about hardware flow control. When a hardware flow control signal is received (due to the signal wire flipping polarity) the hardware gives an electrical interrupt signal to the CPU.

However, the hardware has no idea what this interrupt means. The CPU stops what it was doing and jumps to a table in main memory that tells the CPU where to go to find a program which will find out what happened and determine what to do about it. In this case this program stops the outgoing flow of bytes.

But even before this program stops the flow, it was already stopped by the interrupt which interrupted the work of the CPU. This is one reason why hardware flow control stops the flow faster. It doesn't need to wait for a program to do it. But if that program didn't command that the flow be stopped, the flow would resume once that program exited. So the program is essential to stop the flow even though it is not the first to actually stop the flow. After the interrupt happens any bytes (up to 16) which were already in the serial port's hardware transmit buffer will still get transmitted. So even with hardware flow control the flow doesn't instantly stop.

Using software flow control requires that each incoming byte be checked to see if it's an "off" byte.

These bytes are delayed by passing thru the 16-byte receive buffer. If the "off" byte was the first byte into this buffer, there could be a wait while 15 more bytes were received. Then the 16 bytes would get read and the "off" byte found. This extra delay doesn't happen with hardware flow control.

* License

* Text Terminal How-To Index