Usings CTS and RTS on the ATMega microcontrollers

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

I need to use RTS and CTS control along with the Tx and Rx communications with the ATMega1280. Are there specific pins for the RTS and CTS? How do I implement this hardware flow control on the ATMega and in my program?

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

why do you need the CTS and RTS if you only need to make a connetion to a computer it is enough to youse the TXD and RXD and CTS and RTS have specific pins.

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

RampageSR wrote:
How do I implement this hardware flow control on the ATMega and in my program?
You pick two unused pins, label them CTS and RTS, and you implement the protocol around them.

There is no hardware support for CTS/RTS that I know of. A quick review of the datasheet did not bring up any pointers.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Quote:

why do you need the CTS and RTS

For flow control? Why else?

To do h/w flow control on an AVR it's your responsibility. It's often combined with a buffer and as the buffer approaches full you change an IO pin (CTS) state to tell the other end to hold off for a while then reassert when the buffer is freed up a bit.

The AVR can poll (or use an Int) to see what the other end's line is telling it. It shouldn't Tx when it is not given permission to do so.

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

i have never needed flow controll for my applications.

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

Quote:

i have never needed flow controll for my applications.

I've never needed to use suppositories but that doesn't stop me from understanding why some people need to use them.

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

i don't now what to youse it for ether.
do you now some applications please tell me i have only seen it yousted in ELEKTOR as some I/O.

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

gurra95 wrote:
why do you need the CTS and RTS if you only need to make a connetion to a computer it is enough to youse the TXD and RXD and CTS and RTS have specific pins.

I am communicating with a device that requires CTS and RTS control. It's not a computer. The device is stuck using hardware flow control.

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

Most RS232 interface chips (such as MAX232) have 2 receive channels and 2 transmit channels (or more). Normally, we use just one receive and one transmit. Simply connect the an unused receiver and an unused transmitter to a pair of port pins. One of these gets used for CTS and one for RTS. You implement the hardware handshaking in code.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Mon. Jan 18, 2010 - 05:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
do you now some applications please tell me

Any serial device that has buffers that have a potential to overflow could see the benefit from CTS/RTS. These days we're spoiled because PCs can do things so quickly that it's almost impossible to "flood" them with data even at a fast baud rate like 115,200 but it was certainly possible in the past and there's still a lot of devices with low powered processors that take a measurable, finite time to process data and that can be overcome if sent to much data at once. Their way to tell the fast data producer to "hold on a minute while I process the data you already sent" is CTS/RTS. Another method is Xon/Xoff. Another is DTR/DSR.

See also:

http://en.wikipedia.org/wiki/Flo...

Anyway the bottom line for the OP is that the AVR UARTs do not provide CTS/RTS within the UARTs - they are very simple, not like 16550's so you have to bit-bang the flow control on GPIO.

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

clawson wrote:
To do h/w flow control on an AVR it's your responsibility. It's often combined with a buffer and as the buffer approaches full you change an IO pin (CTS) state to tell the other end to hold off for a while then reassert when the buffer is freed up a bit.

The AVR can poll (or use an Int) to see what the other end's line is telling it. It shouldn't Tx when it is not given permission to do so.

So I choose two unused pins and designate them as my CTS and RTS? Then I create a buffer array and when the buffer array is say 80% full (pointer at 0.8 * Buffer size), I change the CTS to HIGH until the buffer pointer is back to zero? Or am I misunderstanding what you wrote?

Also, Do I have the ATmega check to see if the RTS line is HIGH, indicating that the remote device is ready to transmit data to the ATmega?

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

clawson wrote:
Any serial device that has buffers that have a potential to overflow could see the benefit from CTS/RTS. These days we're spoiled because PCs can do things so quickly that it's almost impossible to "flood" them with data even at a fast baud rate like 115,200 but it was certainly possible in the past and there's still a lot of devices with low powered processors that take a measurable, finite time to process data and that can be overcome if sent to much data at once. Their way to tell the fast data producer to "hold on a minute while I process the data you already sent" is CTS/RTS. Another method is Xon/Xoff. Another is DTR/DSR.

See also:

http://en.wikipedia.org/wiki/Flo...

Anyway the bottom line for the OP is that the AVR UARTs do not provide CTS/RTS within the UARTs - they are very simple, not like 16550's so you have to bit-bang the flow control on GPIO.

That is exactly what my situation is. I'm interfacing an older device that is forced to use hardware flow control. It appears that from the answers I have seen here so far is to implement the RTS, CTS pins myself and as data is received and transmitted, I need to handle (simulate) the proper RTS, CTS controls.

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

AAH!!
now i understand

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

clawson wrote:
Their way to tell the fast data producer to "hold on a minute while I process the data you already sent" is CTS/RTS. Another method is Xon/Xoff. Another is DTR/DSR.
CTS/RTS and DTR/DSR are for opposites sides of the communication channel and which of each pair are input and output depends on the role (DCE or DTE) of each device.

If the device that you're connected to treats RTS as an input and CTS as an output, you may be able to get by with holding RTS at the active level and then monitoring CTS to control when to send data to the device. If you're using interrupt driven transmission, you should check the state of the CTS line before placing a character in the USART's data register. If it is not in the active state, you'll probably want to disable the USART's UDRE interrupt. Then, periodically you'll want to sample the CTS line and, if active, re-enable the USART's UDRE interrupt. Things are simpler if you're using polled transmission.

On the receive side, if you're using interrupt driven reception you probably are using a queue or ring buffer. When the queue gets nearly full (perhaps 2-3 bytes remaining) you'll want to set the control line output to the inactive state, signalling the other device to stop sending. Then, as you take data out of the queue, you can set the control line output back to the active state when the amount of free space exceeds some pre-determined level (perhaps 3-4 bytes). The thresholds that you choose will depend on the characteristics of each end, i.e. what is the maximum number of bytes that might be received after you put the control signal in the inactive state telling the other device to stop sending.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

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

Try and use RS-232 to drive a printer with out flow control.
That is why I had to implement flow control. :)

I'll believe corporations
are people when Texas executes one.