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


Groups > comp.arch.embedded > #25266

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

From Don Y <blockedofcourse@foo.invalid>
Newsgroups comp.arch.embedded
Subject Re: UART behavior for CTS/RTS - Kinetis bugs?
Date 2016-10-28 11:50 -0700
Organization A noiseless patient Spider
Message-ID <nv06lv$si9$1@dont-email.me> (permalink)
References <93dc2e49-2495-4149-8f09-305b9038f599@googlegroups.com> <i_6dnfD3zY2R6Y_FnZ2dnUU7-bWdnZ2d@giganews.com> <nuv1if$hmq$1@dont-email.me>

Show all headers | View raw


On 10/28/2016 1:17 AM, David Brown 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.

... unless the transmitter was restarted before the receiver finished
counting out the remaining bit-times.  In that case, the receiver can
see all sorts of data -- including transitions between logic levels
that are NOT SYNCHRONIZED with its sample clock (which is typically
"set" at the start bit -- of the transmission that had been aborted -- and
not re-set until the next "ready for start bit" portion of the algorithm)

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

Each side *can* be ready all the time -- if designed to be.  OTOH,
if other activities and buffer lengths prevent a consumer from
processing all of the data made available to it before additional
data are presented, then the actual clock rate of the processor
is immaterial.

[E.g., I've seen SPARCstations (LX -- 50MHz) "lose time" because they
missed timer interrupts -- and those are far less frequent than even a
SLOW serial port!  <http://www.pcvr.nl/tcpip/append_b.htm>]

If, for example, a consumer waits until an entire "message" is
available before processing ANY of it, then there is a very real
possibility that the next message can arrive before it's finished
with the previous:  where to *put* it?

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