Serial Port Programming Part 9 - Hardware Flow Control - RTS,CTS

-
What is Flow Control?

 Technically, flow control is a mechanism in which receiver can control the transmission speed. This is done in case of superfast sender and slow receiver. If we don't have flow control, in this case, the receive buffer in the receiver will be overwritten with the new data.

Hardware Flow Control in RS-232:

 RS-232 provides two control lines for hardware flow control:

  • RTS (Request to Send)
  • CTS (Clear to Send)
RTS/CTS is handshaking method 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 a given moment of time.

The RTS pin of one device will be connected to CTS pin of the other device. RTS pin is output and CTS pin is input.

In case of connecting DTE to DTE(null modem cabling), we connect RTS of one device to CTS of other device.


In case of connecting DTE to DCE (straight through cabling), we connect RTS to RTS and CTS to CTS.

A device which is ready to accept data will keep the RTS line asserted (high), when it finds that the receiver buffer is going to be full in some time, it will deassert(low) the RTS line. The other device should look at is CTS state while transmitting, i.e., transmit only when the CTS pin is high. If it is low, wait until the CTS pin goes high.

If one of the device (for example device1 in device1, device2) is fast enough to receive data at any speed, CTS pin of device2 can be tied to high and RTS pin of device1 can be used for other functionality

How to enable Hardware Flow Control?

stty -F /dev/tty<port> crtscts

Or in the code, set 'CRTSCTS' in the c_cflag of struct termios structure.

Comments

Post a Comment

Popular posts from this blog

bb.utils.contains yocto

-
Image
bb.utils.contains  is most commonly used function in Yocto. grep in poky directory returned with 696 count. $ grep -nr 'bb.utils.contains' poky/ | wc -l 696 It's definition is present in 'poky/bitbake/lib/bb/utils.py' file This function returns third argument if the second argument is subset of the first argument else returns fourth argument Let's take an example to understand this. You can see from the above screenshot, when the second argument is a subset of first argument, "present" was returned, else "notpresent" was returned We can also use bb.utils.contains inside if loop. This we can use inside a recipe. if ${@bb.utils.contains('SOMEFLAG','NEWVALUE3','true','false',d)}; then     FOO = 'HELLO' fi
Read more

Difference between RDEPENDS and DEPENDS in Yocto

-
We normally observe these two (RDEPENDS and DEPENDS) whenever we open any recipe. What should we choose when we write our own recipe. DEPENDS -> Build Time Dependency RDEPENDS -> Run Time Dependency DEPENDS: When a recipe 'A' is DEPENDS on recipe 'B'. In this case, Bitbake first builds recipe 'B' and then recipe 'A' E.g. You need 'dbus' to be built before 'wpa_supplicant'. RDEPENDS: When a recipe 'A' is RDEPENDS on recipe 'B'. In this case, Bitbake deploys 'B' on the target system when it deploys 'A'.  E.g. 'perf' RDEPENDS on 'bash' In other words, DEPENDS are those set of packages that should be available while building package, whereas RDEPENDS are set of packages that should be available during execution of the program.
Read more

PR, PN and PV Variable in Yocto

-
PN : Represents the name of the recipe. The name is usually extracted from the recipe file name. PR:  Represents the revision of the recipe. Default value for this revision is "r0". Subsequent revisions of the recipe conventionally will have "r1", "r2" and so on. PV:  Represents the version of the recipe. Normally extracted from the recipe file name. For example: ffmpeg_3.4.2.bb recipe. ${PN} : ffmpeg ${PV} : 3.4.2
Read more