| Author |
Message |
|
|
 Posted: Sep 19, 2011 - 08:42 AM |
|
Joined: Aug 20, 2011
Posts: 12
|
|
| Hope this is the right place to ask this, but can someone please tell me when, why and (briefly) how one would implement handshaking such as RTS/CTS? |
|
|
| |
|
|
|
|
|
|
Posted: Sep 19, 2011 - 09:20 AM |
|
Joined: Mar 27, 2002
Posts: 18749
Location: Lund, Sweden
|
|
|
Quote:
Hope this is the right place to ask this
Well, it would actually be better to start a new thread. Discussions in this thread should ideally be limited to comments&corrections to the tutorial as such. If any of the MODERATORs are in a good mood they might break this out.
Why? When you need it. 
And there is also the duscussion if you are actually wanting "handshaking" which in my world is something that is done when establishig a connection, or "flow control" which is about avoiding the sender to overrun the receiver. Hardware hanshaking would more likely be done on th DSR and DTR lines. Flow control on the RTS/CTS lines.
How? Attach two free digital I/O pins to RTS/CTS and handle them in your code. The UART module in the AVR does not implement anything re this. |
|
|
| |
|
|
|
|
|
|
Posted: Sep 19, 2011 - 04:09 PM |
|
Joined: Aug 20, 2011
Posts: 12
|
|
Thanks, sorry for asking in the wrong place.
I ask because I saw an ancient archived thread here talking about baud rates and someone said in it that for high baud rates with lots of data, you'd need to do RTS/CTS handshaking and I wanted some clarification.
Also looking at FTDI's FT232R datasheet examples, they use RTS/CTS in their "USB to UART on MCU" example.
I'm planning to make something which gathers data as a program runs and sends it back to a PC, looks like it may well be going through UART -> FT232R -> USB virtual COM port -> PC, and I was wondering if this applies to me or I could likely get away with just the Rx/Tx lines. |
|
|
| |
|
|
|
|
|
|
Posted: Sep 19, 2011 - 04:24 PM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
you'd need to do RTS/CTS handshaking and I wanted some clarification
Untrue. If only wires are involved then no matter what the baud rate it's very unlikely that CTS/RTS will be required. If the data is to pass over some other medium: RF over the air or audio tones down a phone line then it's possible it might be necessary if those protocols will try to send packets several times and may need to say "don't send me any more, I'm still chewing on the last thing you sent". But in this day and age CTS/RTS are probably very rarely used.
If you are using USB and wires all the way forget about it. |
_________________
|
| |
|
|
|
|
|
|
Posted: Sep 19, 2011 - 04:32 PM |
|
Joined: Jul 27, 2001
Posts: 7429
Location: St. Leonards-on-Sea (UK)
|
|
| These days software handshaking with XON/XOFF tends to be more common, with data sent in blocks with error detection. |
_________________
Leon Heller
G1HSM
|
| |
|
|
|
|
|
|
Posted: Sep 19, 2011 - 04:38 PM |
|
Joined: Aug 20, 2011
Posts: 12
|
|
Thanks, that's saved me some bother!
Matthew |
|
|
| |
|
|
|
|
|
|
Posted: Sep 19, 2011 - 05:15 PM |
|
Joined: Sep 04, 2005
Posts: 193
|
|
What further limits the usefullness of CTS/RTS is that some devices sample the lines at regular interval. Some promise to only send up to 256 characters after CTS is asserted.
The problem just is that when you need it, then you REALLY need it. In other words, for hobby uses don't bother. If your ass is on the line, better safe than sorry. |
|
|
| |
|
|
|
|
|
|
Posted: Sep 19, 2011 - 05:38 PM |
|
Joined: Dec 11, 2007
Posts: 6980
Location: Cleveland, OH
|
|
|
Quote:
Also looking at FTDI's FT232R datasheet examples, they use RTS/CTS in their...
Probably worth mentioning that if the hardware has the control signals you may need to correctly tie the input signal High or Low to enable the USART to flow.
Look closely at the data sheet in this regard.
JC |
|
|
| |
|
|
|
|
|
|
Posted: Sep 20, 2011 - 05:03 PM |
|
Joined: Aug 06, 2008
Posts: 365
Location: Rockall
|
|
I use a circular buffer 1 page (256 bytes) long. When the in pointer and the out pointer get too close I yell STOP and when the gap gets big enough I shout GO!
Naturally I use CTS/RTS to do the yelling, but it works. |
_________________
Cheers,
Joey
|
| |
|
|
|
|
|
|
Posted: Sep 20, 2011 - 05:11 PM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
I use a circular buffer 1 page (256 bytes) long. When the in pointer and the out pointer get too close I yell STOP and when the gap gets big enough I shout GO
Crikey, if an AVR design (with perhaps only a 1K..2K memory) is so bad that you run the risk of hitting a high water mark in a 256 byte buffer I'd suggest you may not be servicing the buffer with a high enough priority! |
_________________
|
| |
|
|
|
|
|
|
Posted: Sep 21, 2011 - 12:53 PM |
|
Joined: Aug 06, 2008
Posts: 365
Location: Rockall
|
|
|
Quote:
Crikey, if an AVR design (with perhaps only a 1K..2K memory) is so bad that you run the risk of hitting a high water mark in a 256 byte buffer I'd suggest you may not be servicing the buffer with a high enough priority!
This AVR design has 128k of external memory in two paged banks
One of the things it allows me to do is upload BASIC programmes as raw text without having to 'dongle' the coms programme to do it slowly enough, as the AVR expects a typed program and can't tokenise lines fast enough to keep up with 19,200 baud. |
_________________
Cheers,
Joey
|
| |
|
|
|
|
|
|
Posted: Sep 21, 2011 - 11:53 PM |
|
Joined: May 03, 2009
Posts: 564
Location: Dallas, TX USA
|
|
|
clawson wrote:
Quote:
I use a circular buffer 1 page (256 bytes) long. When the in pointer and the out pointer get too close I yell STOP and when the gap gets big enough I shout GO
Crikey, if an AVR design (with perhaps only a 1K..2K memory) is so bad that you run the risk of hitting a high water mark in a 256 byte buffer I'd suggest you may not be servicing the buffer with a high enough priority!
It depends on what you are doing with the received data.
Consider when the serial data is messages that is controlling an intelligent type device.
And that each message causes a complex series of actions
which might take "a while" to complete.
Flow control becomes very useful to allow the sender code to be "dumb" and not worry about buffer overflows.
For those AVR chips that use internal USB and virtual com ports on top of USB for their serial connection,
the flow control is essentially built in because
the host will stop sending when the USB buffers fill.
For simple UARTS, to avoid buffer overruns in environments like this you need some sort of flow control mechanism,
either hardware lines like RTS/CTS, Xon/Xoff, or some sort of lower level message handshake protocol.
And as a last resort, delay the sending of messages
to account for the processing time of prior requests.
--- bill |
|
|
| |
|
|
|
|
|
|
Posted: Sep 22, 2011 - 12:43 AM |
|
Joined: Oct 05, 2006
Posts: 2297
Location: Poland
|
|
| I know U2 series AVRs have a hardware flow control. So you could use it like an FTDI chip. Unfortunatley the N*300 series baud rate is limited to about 115200kb/s when using USB. |
_________________
No RSTDISBL, no fun!
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
