Re: UART behavior for CTS/RTS - Kinetis bugs?

From	Dimiter_Popoff <dp@tgi-sci.com>
Newsgroups	comp.arch.embedded
Subject	Re: UART behavior for CTS/RTS - Kinetis bugs?
Date	2016-10-28 01:02 +0300
Organization	TGI
Message-ID	<nuttfl$nk9$1@dont-email.me> (permalink)
References	<93dc2e49-2495-4149-8f09-305b9038f599@googlegroups.com> <i_6dnfD3zY2R6Y_FnZ2dnUU7-bWdnZ2d@giganews.com>

Show all headers | View raw

On 28.10.2016 г. 00:39, Tim Wescott wrote:
> On Thu, 27 Oct 2016 13:21:01 -0700, Dave Nadler 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.
>
> I believe that the only reasonable thing to do would be to finish sending
> the character, then wait until CTS is asserted before sending.
>

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             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

Thread

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

csiph-web