UART behavior for CTS/RTS - Kinetis bugs?

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 
http://www.wescottdesign.com 

I'm looking for work -- see my website!

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

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

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

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.

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!! 
                              gmail.com

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.

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

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)

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:

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.

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