Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #25243 > unrolled thread

UART behavior for CTS/RTS - Kinetis bugs?

Back to article view | Back to comp.arch.embedded

Contents

  UART behavior for CTS/RTS - Kinetis bugs? Dave Nadler <drn@nadler.com> - 2016-10-27 13:21 -0700
    Re: UART behavior for CTS/RTS - Kinetis bugs? Don Y <blockedofcourse@foo.invalid> - 2016-10-27 13:41 -0700
      Re: UART behavior for CTS/RTS - Kinetis bugs? Dave Nadler <drn@nadler.com> - 2016-10-28 10:42 -0700
        Re: UART behavior for CTS/RTS - Kinetis bugs? Don Y <blockedofcourse@foo.invalid> - 2016-10-28 11:15 -0700
          Re: UART behavior for CTS/RTS - Kinetis bugs? Don Y <blockedofcourse@foo.invalid> - 2016-10-28 11:21 -0700
          Re: UART behavior for CTS/RTS - Kinetis bugs? antispam@math.uni.wroc.pl - 2016-10-29 00:17 +0000
            Re: UART behavior for CTS/RTS - Kinetis bugs? Don Y <blockedofcourse@foo.invalid> - 2016-10-28 19:28 -0700
              Re: UART behavior for CTS/RTS - Kinetis bugs? upsidedown@downunder.com - 2016-10-29 13:57 +0300
        Seriial ports on PCs. (was Re: UART behavior for CTS/RTS - Kinetis bugs?) Paul <paul@pcserviceselectronics.co.uk> - 2016-10-29 09:03 +0100
          Re: Seriial ports on PCs. (was Re: UART behavior for CTS/RTS - Kinetis bugs?) upsidedown@downunder.com - 2016-10-29 14:12 +0300
            Re: Seriial ports on PCs. (was Re: UART behavior for CTS/RTS - Kinetis bugs?) Paul <paul@pcserviceselectronics.co.uk> - 2016-10-30 09:34 +0000
    Re: UART behavior for CTS/RTS - Kinetis bugs? Tim Wescott <seemywebsite@myfooter.really> - 2016-10-27 16:39 -0500
      Re: UART behavior for CTS/RTS - Kinetis bugs? Dimiter_Popoff <dp@tgi-sci.com> - 2016-10-28 01:02 +0300
      Re: UART behavior for CTS/RTS - Kinetis bugs? lasselangwadtchristensen@gmail.com - 2016-10-27 15:31 -0700
      Re: UART behavior for CTS/RTS - Kinetis bugs? David Brown <david.brown@hesbynett.no> - 2016-10-28 10:17 +0200
        Re: UART behavior for CTS/RTS - Kinetis bugs? Grant Edwards <invalid@invalid.invalid> - 2016-10-28 14:23 +0000
          Re: UART behavior for CTS/RTS - Kinetis bugs? David Brown <david.brown@hesbynett.no> - 2016-10-28 16:34 +0200
          Re: UART behavior for CTS/RTS - Kinetis bugs? Don Y <blockedofcourse@foo.invalid> - 2016-10-28 12:02 -0700
        Re: UART behavior for CTS/RTS - Kinetis bugs? Don Y <blockedofcourse@foo.invalid> - 2016-10-28 11:50 -0700
        Re: UART behavior for CTS/RTS - Kinetis bugs? upsidedown@downunder.com - 2016-10-29 01:51 +0300
          Re: UART behavior for CTS/RTS - Kinetis bugs? upsidedown@downunder.com - 2016-10-29 13:59 +0300
    Re: UART behavior for CTS/RTS - Kinetis bugs? Wolfgang Mahringer <yeti201@gmx.at> - 2016-10-28 16:45 +0200
    Re: UART behavior for CTS/RTS - Kinetis bugs? Hul Tytus <ht@panix.com> - 2016-10-28 22:28 +0000

Page 2 of 2 — ← Prev page 1 [2]

#25274

On Sat, 29 Oct 2016 01:51:19 +0300, upsidedown@downunder.com wrote:

>On Fri, 28 Oct 2016 10:17:43 +0200, David Brown
><david.brown@hesbynett.no> wrote:
>
>>> I believe that the only reasonable thing to do would be to finish sending 
>>> the character, then wait until CTS is asserted before sending.
>>> 
>>
>>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.
>>
>
>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

[toc] | [prev] | [next] | [standalone]

#25261

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

[toc] | [prev] | [next] | [standalone]

#25268

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 <drn@nadler.com> wrote:
> Hi all - Perhaps some of you have encountered this?

> The post linked below shows the Kinetis UART continues to transmit after the receiver has de-asserted CTS:
> https://community.nxp.com/thread/432154
> 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-assert 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 from the start bit when CTS is again asserted (which in turn introduces a race condition around the end of character transmission)? Or finish the current character transmission and then pause (another race condition for "current 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 never had this impact an application, but using some parts like SiLabs bluegiga for SPP don't give that option (at the layer of controlling the Bluetooth device, or supporting a non-protocol client expecting a simple ASCII data stream). Even worse, these things drop status messages into the (application data) stream with no consistent header/delimiter - good luck catching all possible Bluetooth events.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web