UART behavior for CTS/RTS - Kinetis bugs?

Hi all - Perhaps some of you have encountered this?

The post linked below shows the Kinetis UART continues to transmit after th e receiver has de-asserted CTS:

formatting link
Freescale engineers claim their part is OK and its the other guys fault...

Here's my question: As this is an asynchronous link, the receiver can de-as sert CTS at any time. What is the transmitter supposed to do? For example, suppose CTS is de-asserted in the middle of transmitting a character: Must the transmitter immediately stop, and restart transmitting the character fr om the start bit when CTS is again asserted (which in turn introduces a rac e condition around the end of character transmission)? Or finish the curren t character transmission and then pause (another race condition for "curren t character")? Is there any specification on how this should be handled? Or even any consensus?

Thanks in advance, Best Regards, Dave

PS: I've always used a protocol layer that corrects dropped characters so n ever had this impact an application, but using some parts like SiLabs blueg iga for SPP don't give that option (at the layer of controlling the Bluetoo th device, or supporting a non-protocol client expecting a simple ASCII dat a stream). Even worse, these things drop status messages into the (applicat ion data) stream with no consistent header/delimiter - good luck catching a ll possible Bluetooth events.

Reply to
Dave Nadler
Loading thread data ...

I believe that the only reasonable thing to do would be to finish sending the character, then wait until CTS is asserted before sending.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

It is the normal thing to do indeed, all UARTs I have touched (the MC6850 ACIA being the first one some ages ago) do it this way. Except one - a Mostek 6550 or something like that. It would break the character up... thus making its CTS input unusable to me. Well, this was also a few ages ago, one or two less than the 6850 though :-).

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

formatting link

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

formatting link

Reply to
Dimiter_Popoff

yes, the uart should check CTS right before sending the start bit

It seems the problem is that that uart has already committed to sending before the other end has gotten the full stopbit and a chance to set CTS

maybe using two stop bits on the transmit side would work

-Lasse

Reply to
lasselangwadtchristensen

Yes, anything else would disrupt the low-level behaviour of the UART, which is designed to transfer in units of one character. If the transmitter broke off in the middle of the character, a receiver would see the start of the character followed by high bits.

I also think it is odd to see something using hardware flow control in modern devices. Hardware flow control can be a real pain when you have buffers, FIFOs, DMA, etc. Flow control is usually handled at a higher protocol level now. Rather than using CTS/RTS, or XON/XOFF, you define it at a higher level such as replying to telegrams with NACK's. Or you just note that since your UART is running at perhaps 115kbps or less, and your microcontrollers are running at 50 MHz or more, you don't need any kind of flow control - each side is ready all the time.

Reply to
David Brown

Which is an entirely valid character assuming no parity. It has a 50% chance of being a valid character with parity enabled. Stopping the transmitter in mid-character is simply 100% broken.

Why? If hardware flow control is implemented properly (which means it's in HW), then it's completely transparent regardless of buffers, FIFOs, DMA, etc. Trying to implement hardware flow control in software is usually futile.

--
Grant Edwards               grant.b.edwards        Yow! Civilization is fun! 
                                  at               Anyway, it keeps me busy!! 
 Click to see the full signature
Reply to
Grant Edwards

Often it is /not/ implemented entirely in hardware. Even if the hardware handles the FIFOs, DMA, etc., there are often other aspects such as timing and timeouts that get extra complications when there is hardware flow control. It is certainly possible to handle, but it is an extra complication - and IME it is rarely used these days.

Reply to
David Brown

Hi Dave,

As others have pointed out, the current character in the transmitter shift register is sent correctly.

Many years ago I had to deal with lots of modem datalinks, some also with hardware handshaking. I found, that one needs to expect up to *two* more characters after asserting CTS. Usually, you get no or one more character, but be prepared to get two. I assumed this has to do with some internal buffers in the UART logic.

HTH Wolfgang

--
From-address is spam trap 
Use: wolfgang (dot) mahringer (at) sbg (dot) at
Reply to
Wolfgang Mahringer

Note that there is also the possibility of the transmitter being resumed/restarted before the aborted character *time* has expired.

+42

There's no way this can be useful unless you were operating in simplex or in an interlocked protocol (like the *original* use of RTS/CTS; not the current RTR/CTS interpretation). How else would the receiver know when it is "appropriate" to alter the state of this control signal?

[Yet another case where most documentation is incomplete. Where's the figure indicating how much (time) BEFORE the start bit the CTS signal is examined -- to go/no-go the transmission of THIS character?]

Its no harder to implement flow control in software than it is to handle the receipt of characters! The EXACT SAME timeliness issues apply (if you can get around to *noticing* that you've received more characters than you can buffer BEFORE you actually lose characters, then you obviously can toggle a DI/O to inform the remote transmitter of this.

The issue is deciding how much "slack" you need in your buffer to accommodate variations in Rx ISR latency -- how LATE are you to notice the receipt of a character (and how deep is the hardware FIFO in the UART to tolerate that lateness without loss of data).

And, at the same time, how late do you expect the transmitting device to be in noticing the change in the state of the incoming pacing signal. If you're feeding the transmitter from an ISR (not DMA), then you add a test to check the state of the line before stuffing the next character into the transmitter.

The only real "complication" comes from having to now monitor the handshaking signal to determine when it is appropriate to RESUME the transmitter ISR (cuz the transmitter is now essentially "ready, but disabled" -- unable to generate a new "event" to signal the loading of the next character)

Reply to
Don Y

Dave - as someone mentioned here, there are all sorts various ways of using the rs232 uarts. I am currently debugging a file interchange routine which is causing all sorts of trouble but it is intended to follow the following form, which is a somewhat common setup. Two machines are interconnected via a 9 pin cable with the recieve and transmit lines switched midway, ala a "null modem". The rts and cts lines are switched in the same fashion. When either machine is willing to accept data, it raises rts which causes cts to be raised at the other machine. When the other machine wants to send data, it checks to see cts is high and, if so, transmits as long as cts is high.

Hul

Dave Nadler wrote:

Reply to
Hul Tytus

The last time I used true RTS/CTS handshaking was with a serial matrix printer a few decades ago.

The CTS pin is sometimes used to control the Data Direction pin on an RS-485 two wire half duplex transceiver. Unfortunately, the garden variety 14550 family UARTs turn off the CTS pin, when the last character is moved into the transmit shift register, _not_ when the last stop bit is actually transmitted from the UART.

Reply to
upsidedown

Correction: The RTS pin is more often used for data direction control

Reply to
upsidedown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.