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

Groups > comp.arch.embedded > #25267

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

Show all headers | View raw

On 10/28/2016 7:23 AM, Grant Edwards wrote:
> On 2016-10-28, 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.
>
> Which is an entirely valid character assuming no parity.  It has a 50%
> chance of being a valid character with parity enabled.

Note that there is also the possibility of the transmitter being
resumed/restarted before the aborted character *time* has expired.

> Stopping the transmitter in mid-character is simply 100% broken.

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

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

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)

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