RTS/CTS flow control

I would do so, you can't be sure about the receive buffer size.

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)

It's all application dependent. CTS/RTS Transitions in the middle of a block are (very) bad form, but they can happen.

Even if there were official recommendations, that does not mean the authors of the device followed them.

-- Les Cargill

Wikipedia indicates that current standard re-named RTS as RTR (ready to receive) but it doesn't indicate that it specifies a particular number of characters that may be sent/received after a handshake line is de-asserted.

When it's implemented in the UART's hardware, I would expect RTS and CTS handshaking to apply for individual character frames.

On the whole, however, I think that it is really application specific. It would be quite fair for a device's spec to state that up to N characters may be sent following reset of the handshake line.

--
Rich Webb     Norfolk, VA

that standard is a peer standard parallel to DCE/DTE stuff - it's for peer links. What applies depends on who done it. I smell standards creep - we done did DCE-DCE stuff a lot back on the day...

I would not, but it shouldn't matter. The 16550 at least puts "character available" bit status as higher priority than "modem status". If it were the other way, then you'd drop characters. That sounds hierarchical, and having CTS/RTS control receipt of characters would tangle that hierarchy. It would also involve (unnecessary) complexity.

I plead observer bias, but I never saw CTS/RTS used to control flow within a packet. There is no telling what demons made the device he's interfacing to, though.

"If you have to shoot, shoot. Don't talk." - Tuco, "The Good The Bad and the Ugly". (shoot=characters, talk=signals).

Always sound advice.

-- Les Cargill

There is a signaling standard:

John E. McNamara's book is probably the best to be had on the subject. Old editions, or newer. It covers the RS-232 standard with clarity, breadth and depth.

When I get a moment, I'll find my copy and look up CTS/RTS to see if there is a narrow specification in cases where CTS/RTS are used. May not be.

In practice, most devices I've experienced will assert it in relationship to their internal, low level buffers and not at all on some logical block basis. It's just about making sure that their buffers don't overrun.

Jon

Personally, I do not do it that way, but instead implement the incoming CTS signal as a interrupt handler. This applies regardless of whether I am using any inbuilt UART flow control hardware, or am implementing flow control using GPIO lines (this assumes the GPIO hardware has the ability to generate a interrupt on any change).

As for handling the outgoing RTR signal, I raise RTR (to request the peer stops transmission) when my buffer space has dropped to around 5 bytes and lower RTR again when the available buffer space has increased to around 10 bytes. This is at 9600 baud with code running on bare AVR/ARMs without a OS.

Is the third party device a unstructured character based device like a logger/printer/etc, or is it running a higher level protocol with it's own built in congestion control which you could use ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

That's my experience also. Brought memories of very nasty debugging sessions with a cash register using RS-232 for product info and price lookups. We found that on this particular system, negating CTS would stop the processor from writing more data to the UART, but would not stop the UART from sending what was already in its internal FIFO, overflowing the receive buffers on the other side.

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]

Hi Vladimir, RTS being asserted means that the receiver can accept at least one byte. So you have to check CTS prior to sending every character, just as hardware UARTs do. I remember an ancient 65xx UART which would lose the incoming byte if CTS got negated during reception... the only one I have seen of the kind, though :-). No idea how "official" this is but this is pretty much what you will have to do to make things work unless you have control over the two sides - in which case you would not have asked here, I guess.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

If you want to see that kind of bug in a modern MCU's UART, check out the errata section of the datasheet for the Atmel SAM7S series. On some revisions, there's a small window (about 18 clock cycles IIRC) during character reception where a character can be lost if the UART is in Hardware Handshaking mode and CTS changes.

While you are there, also check out the errata item which effectively says we (Atmel) implemented software flow control, which made it all the way into the finished product before we found out that it could never work as designed. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Hi Without information about how third party device implements RTS/CTS flow control you can not do too much. You have to know their Tx and Rx FIFO deepness.

Tell us what kind of device is it?

--------------------------------------- Posted through

Just to clarify the wording on that because it's ambiguous; I don't work for Atmel and I am just a normal end user of their products.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Hah, so it is not only the MOSTEK people of 30 or 40 years ago to have designed the bug in. Well, we all make mistakes. I am not an Atmel MCU user so I don't know how clear they are; currently I am getting into a Freescale one for tiny purposes (mcf52211), errata sheet looks pretty modest. But I am just beginning to talk to its BDM today, hopefully there will be no nightmares to follow.

I can well see what a huge "oops" it can be to discover a bug like this CTS one after you have designed the part in, oh no.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

To be honest strict RS-232 flow control is a mess that tends to be honoured more in the breach than the observance. The traditional form applied strictly isn't very useful, so it is not really a question of following the standard but of how you break it. The traditional unidirectional form works as follows:

1) DTE has data to send; asserts RTS. 2) DTE waits for DCE to assert CTS. 3) DTE sends its data. 4) DTE drops RTS. 5) DCE drops CTS in response. That's _it_. There's no question as to what happens if the DCE drops CTS while data is being sent: it isn't permitted. The DCE can indicate when it is ready to begin receiving but after that it has no way of indicating a full buffer or any other such condition. Not very useful, but that's the way it was originally defined.

To get around this many devices relax things somewhat and allow the DCE to drop CTS during a transmission. This isn't standardised so the questions you ask about are at best loosely defined. What it means if CTS drops in the middle of a character, whether it has to accept any further data after that, or any other questions you might have, ultimately there is no answer.

However, I _can_ tell you if you want to interface to a modern

16550-compatible peecee serial port if you drop CTS it will assume the character being sent is received. It will also carry on sending after that for a few extra characters - I presume it is emptying the transmit buffer (16 bytes for a 16550), and that this seems to be independent of the OS. To combat this I've generally used at least a 64 byte recieve buffer and deasserted CTS when it is more than half full. That seems sufficient slack for everything to hold together, although you may be able to get away with less. I also ensure that CTS is dropped during the stop bit to try and avoid ambiguity - that means a quick response for that element of the ISR. I haven't found anything that needs it but if drifting off spec I'd rather go for a belt-and-braces approach.

The more modern bidirectional flow control with a Ready To Recieve signal is standardised, but is a reflection of something that was being done in practice earlier, so again you can't guarantee much. The spec (I have the F revision in front of me now) does say that the signal takes effect 'following the completion of any "in process" transmission' but does not define how much data constitutes a 'transmission' so far as I can see. As a result I'd use a similar approach to described above - be prepared to accept a little more data even after CTS or RTR is de-asserted.

--
Andrew Smallshaw
andrews@sdf.lonestar.org

Quite useful controlling a DCE using a half duplex communication channel e.g. single frequency radio modem, but not very useful otherwise.

That's understandable for a standard that was written to specify how you talked to modems (many of which were half-duplex). There are still plenty of industrial devices (I would guess tens of millions) out there that use 1200 baud, Bell-202 half-duplex communications.

--
Grant Edwards               grant.b.edwards        Yow! This is a NO-FRILLS
                                  at               flight -- hold th' CANADIAN
                              gmail.com            BACON!!

You have not said what 'your end' is running on ? If you have full control, and access then check the 'wait' lines as often as you can.

- and I often like to margin these things as well, so you design a Test-before-send code, and then see what happens, if instead you send

2-4-8-16 etc bytes AFTER the wait signal. That gives you an idea of how much (or little) margin the remote unit has.

Most should signal well BEFORE they are full, but it depends on how much resource they had, and as others have mentioned, FIFOs can get into the mix.

Also, continual stream tests can be useful, with some visual tracking if possible. Using this, we uncovered a case where not all wait signals were equal...

-jg

history must be the reasons that something that be rather simple could be so screwed up in so many ways.

if the uart HW checked the RST before starting a new byte, and set the clear the CTS when ever the fifo has one byte left it couldn't possible overflow

-Lasse

Yes, It is fixed in the rev C SAM7S devices.

As for the original question, you need to check what is on the other end. As mentioned, the NS16550 will send anything remaining in the 16 level FIFO after/CTS is deasserted, so be prepared to receive up to 16 (or mayby 17) extra characters.

BR Ulf Samuelsson

Yes, you are right that history is the reason for this kind of interfaces.

Early telex/teletype machines operated at 45 or 110 bit/s in a 20/60 mA current loop configuration.

Instead of leased current loop lines, dialup audio (phone) lines were later used to carry this text based message transfers using 0-300 Baud FSK audio modems.