On RTS-CTS & DTR-DSR pairs, which and why?

[pawel]

Hello All

Is there somewhere in the Net a good article about when and why to use the flow control RTS-CTS and/or DTR-DSR.
I am dealing with duplex communication between two devices via RS232 and I would like to know when and why to control those lines.

I also found three types of Null-Modem cables and all it is connected with the control of those lines.

Where I can read about it?

Thanks in advance
Pawel

[wha@atmel]

Hi Pawel

I recommend http://www.book.nu/0965081923
look in addition to Jan Axelsons website......
excellent info's there

regards
Werner

[Al_S]

Most RS-232 communication is full duplex, meaning you can transmit and receive at the same time. RS-232 UARTs have separate transmit and receive machines and FIFOs. The processing speed and large available memory of today's electronics (PCs as well as other devices) drastically reduce the need for hardware handshaking. I've been writing RS-232 applications for almost 20 years. I haven't used hardware handshaking for over 15 years, and that application only required it because one piece of equipment was already 30 years old.
Hardware handshaking adds complexity to the software as well as the hardware. If you're only going a short distance, off the shelf cables include all RS-232 lines. But for longer runs, it will be easier and cheaper to run 3 or 4 conductor cabl
e without hardware handshaking.
If you need handshaking, consider software handshaking if your devices support XON/XOFF handshaking.
If you do a Google search for RS-232 handshaking, you'll find plenty of links. Some of these will give you an introduction.
http://www.airborn.com.au/rs232.html
http://www.bb-europe.com/tech_articles/faq_rs232_connections_work.asp
http://www.qkon.com/uploads/27_Practical%20RS232%20Design%20Considerations.pdf

[pawel]

Hi Werner

Thanks for the info. I can not find the website you are refering to, can you give a link?
thanks
Pawel

[pawel]

Hello Al

Thank you for the answer. I know google will through out tousands of links, that is why I wanted to ask for one or two good ones.

I am not convinced to use hansdhaking. I think it is a good idea to indicate that the transaction was a success. I also see that in LV the only change is to select flow control to a proper value.

It is not actually true, since none of RTS, CTS, DTR, DSR are changed automatically. As I see it, those lines shell be controlled manually after receiving the porper amount of information. The additional problem is that VISA property node " set modem lines" does not work on some UARTS when the flow control is different that NONE. For egsample, on my machine, the onboard UART accepts the modem line changing, but the PCI c
ard with additional ports does not.

But comming back to the handshaking. I would like to have handshaking, but controlled by hardware. If UART buffer is stuffed the control lines are set and the device on the other site knows what is going on.
Can you give me some advices on that?

Thanks in advance
regards
Pawel

[wha@atmel]

try this:
http://www2.rad.com/networks/1995/rs232/rs232.htm

next link was active - but seems not to work now ??
http://www.jaxelson.@lvr.com/styles/lvr.css

search @ Google for "Jan Axelson" - you will find a lot
hope this helps...... regards
Werner

[Al_S]

Going back to one of the original mass-popular UARTs, the Intel 82510, RTS, CTS, DTR, and DSR could be read or written using registers. It was the software's responsibility to read or write these lines to impliment "hardware" handshaking. That's what I meant when I said that hardware handshaking adds complexity to the software as well as the hardware.
When hardware handshaking was implimented, it wasn't used to indicate that transmission was complete or successful: it was used to tell one device when a slow device was ready.
As you have seen, not every device supports hardware handshaking. I would not recommend hardware handshaking and haven't used it in fifteen years.
You could impliment some software protocol to indicate end of transmisssion or
success. There are published protocols like x-modem which build packets, do error checking, etc. But I don't think even this is necessary for many applications.