Handling RTS & CTS - UART

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

In one of my project i am using uart with tx and rx lines to communicate to the computer. The project involves high volume of data transfer. The time taken to complete the transfer is very long. I had decided to use RTS and CTS signls.

Can any one give me any example or explanation how to do it?

Nandhu

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are using RS-232 you need an interface chip with 2 inputs and 2 outputs. You hookup the AVR USART to the interface chip like normal. Then you use two general purpose AVR I/O pins for RTS and CTS that you also connect to the RS-232 interface chip (Google RS-232 standard to figure out which one is the input and output). Then you write software for the AVR to do the handshaking with the added AVR input pin and added AVR output pin.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What do you hope to achieve by implementing hardware flow? Essentially, if you are a DCE, watch the RTS pin. If it goes low, stop sending the DTE data.

If your incoming buffer is about to fill, de-assert the CTS pin, the host should stop sending data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
the host should stop sending data.
...eventually, when the buffer is empty in case of a pc.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:
the host should stop sending data.
...eventually, when the buffer is empty in case of a pc.

I think PCs stop within 2-3 characters. So you need to design for such.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

timgoh0 wrote:
What do you hope to achieve by implementing hardware flow? Essentially, if you are a DCE, watch the RTS pin. If it goes low, stop sending the DTE data.

If your incoming buffer is about to fill, de-assert the CTS pin, the host should stop sending data.

Thanks everyone

Because i loose come data if i am sending it contineously. For this ever time i have to send it back to confirm the data. This slows down the transfer time.
Can i speed up the data transfer avoiding the confirmation? Is there any other better way to do it?

Regards
Nandhu

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well what baud rate are you presently using?

By the way, besides RTS/CTS you might consider using in-band flow control (Xon/Xoff)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To speed up the communication, you should send large blocks of data, e.g. 256 bytes.
Then only every block must be confirmed.

E.g. I use a protocol, where the PC ask at first, which was the largest block size of the AVR, which can be received continously.
So e.g. an ATTiny25 can handle 64 byte blocks or an ATmega238P can handle 1024 byte blocks.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
I think PCs stop within 2-3 characters. So you need to design for such.

That's been my experience with the FTDI USB-RS232 chips. I have

ISR(USART_RX_vect, ISR_BLOCK) {
	char c = UDR0;
	if (c=='\r') {
		UART0.RxFIFO.PushBackISR('\n');
	} else {
		UART0.RxFIFO.PushBackISR(c);
	}	
	if (UART0.RxFIFO.Space() < 3) {
		CTS.Low();
	}
}

at one end of my receive FIFO, and

int uart_getchar(FILE *stream) {
	char c=0;
	while (!UART0.RxFIFO.PopFront(c)) {
		OS.Yield();
	}
	if (UART0.RxFIFO.Space() > 4) {
		CTS.High();
	}
	return (unsigned char)c;
}

at the other end. This works reliably on a mega168/20MHz at 115.2kBaud. The code is C++ so it might look a bit odd to some of you C-types!

Christopher Hicks
==

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for everyone.

Now i am using 115.2k Baud. I am using 256bytes block to checking. I have my computer to receive data from the micro M8. If i send 256 bytes i am only receving 23 or 24. So there is a problem with my VB program. I am on it.

By the way can any one explain how xon xoff works?

Nandhu

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Windows should be able to buffer 256 bytes. I think your problem is elsewhere.

Basically with Xon/Xoff, the receiver sends an Xoff character when it wants your to stop sending, then sends Xon when it want you to send again.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

Basically with Xon/Xoff, the receiver sends an Xoff character when it wants your to stop sending, then sends Xon when it want you to send again.

The use of XON/XOFF requires that the data xferred isn't "true binary" , as the XON/XOFF characters must not occur in the data sent (look in an ascii table XON/XOFF is in there).

Edit: RTS/CTS ia often referred to as "hardware handshake" and XON/XOFF as "software handshake" , you'll prob. see that mentioned in a terminal program.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thankyou all.

I rectified the problem. Now iam able to send and receive data at 115.2k Baud. There are problem in both micro and vb program.

I will come back with questions if any problems found in this reagrd

Nandhu

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can I use the rest of pins of PORTD to implement handshaking? RX/TX USART just use PD0 and PD1 pins of PORTD.. I would like to use PD2 and PD3 as RTS/CTS, Is it posible?

Thanks

Ronaldo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Can I use the rest of pins of PORTD to implement handshaking? RX/TX USART just use PD0 and PD1 pins of PORTD.. I would like to use PD2 and PD3 as RTS/CTS, Is it posible?

You can just pick any two PORT pins you choose to implement CTS/RTS - so that should be fine. You may be better off doing software flow control (Xon/Xoff) though.