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

Groups > comp.arch.embedded > #25244

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

Show all headers | View raw

On 10/27/2016 1:21 PM, 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

No.

> 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?

Of course, serial (EIA232) comms are highly application dependant.
A TWX would handle this differently than a modern PC, etc.  But...

Clear-To-Send indicates *clear* (i.e., "OK") to (begin to) send.

The transmitter should sample it at the start of transmission
and defer the transmission until it is asserted (and "stable").

As most transmitters (serializers) are decoupled from the "holding
register", this often means that AT LEAST one character can be
expected to be received after the receiver drops CTS.  Of course,
as the receiver has no idea if the transmitter is *just* starting
a transmission (all it knows is the results of the previous transmission
and often doesn't have fine-grained temporal information about that,
either -- nor the waveform distortions/skew in transit; i.e., you
can't reliably infer what the transmitter is doing even with a
'scope probe on its TxD!), that character is possible regardless
of whether you're driving the line with a 1402 or something fresh
out of today's foundries!

As Tx buffers have increased in depth, there are more possibilities
for additional characters to be received after dropping CTS.  I.e.,
flaws in how this information is "expedited" up/down the buffer.

And, if you want to support XON/XOFF (and variants thereof), then you
have to also expect some amount of additional delay (i.e., if you have
to SEND an XOFF character, you have to ensure YOUR transmitter is
idle -- which means waiting for 1 or more enqueued characters to
clear it -- AND for the receiving UART to be able to receive the
sent character and "process" it.  Whether that is done in the driver
or a higher level protocol handler can affect the latency in how quickly
the remote transmitter actually "paces off".

Bottom line, leave a bit of space in your Rx FIFO for several characters.
I design my drivers to store the received character AND associated
flags (i.e., 2 bytes per character).  This allows the higher level
protocol handler to notice if a character was received with a parity
or framing error, overrun, etc.

It also provides a convenient place to inject a "FIFO overrun" flag.
I.e., "at this point in the character stream, the receive FIFO overflowed
because something didn't stop sending as expected.  As such, one or
more characters are lost, here."

[It also lets you promote BREAK (long space) handling to that protocol
level instead of trying to handle it AND RECOVER FROM IT in the driver;
drivers should always be lean/efficient -- do as little as possible]

If you know exactly the protocol characteristics of the device with which
you EXPECT to communicate, then you can (gamble on) tailoring the driver
and handler to that particular device (at your own peril as "things
inevitably change")

> 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.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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