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

Groups > comp.arch.embedded > #25264

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

Show all headers | View raw

On 10/28/2016 10:42 AM, Dave Nadler wrote:
> On Thursday, October 27, 2016 at 4:42:07 PM UTC-4, Don Y wrote:
>> ...A TWX would handle this differently than a modern PC, etc....
>
> Of course, as a 'modern' PC hasn't had a serial port in a decade ;-)
>
> Seriously Don, you haven't answered the question:
> Is there any specification on how this should be handled?
> Or even any consensus?

No, there is no "specification".  The reason I threw out the TWX/PC
comparison is to highlight how different devices can handle the same
circumstances.  And, "concensus" depends on your specific application.

[Originally, RTS/CTS were used to handshake the flow of data from
DTE to DCE:  RTS to indicate a *desire* to send data to the DCE;
CTS to indicate a *willingness* to ACCEPT data from the DTE.  I.e.,
assert RTS, wait for CTS, send data as long as CTS is valid.  There
was not a similar handshake from DCE to DTE!  Now, RTS is effectively
RTR:  "Ready to Receive", not "Request to Send"!  There's a big
difference in intent.]

In your case, you have two specific devices talking to each other.
You can possibly tune your implementation to that scenario.

In my projects, I typically only know ONE end of the link (the end
that I'm coding) and have to *hope* the other party (which will
be decided by the end user and may change, over time) will be
reasonable in its implementation.  So, my driver and handler
tends to be very aggressive in ensuring that data is not lost
(because its often not possible to NAK a transmission; if I miss
it, its gone!)

And, as some devices may *not* be reasonable (e.g., legacy devices
where the UART driver handles all the handshaking by toggling
digital I/O ports), I have to safeguard the incoming data stream
that *I* will be processing so I can see when it has not been
cooperative (which is why I add a "FIFO overrun" flag to the
per-character flags *in* the FIFO).  E.g., if I can receive the
two different messages:
     Stop Now
     Do Not Stop
(because someone did a lousy job designing the protocol -- which is
surprisingly common!), then I need to be able to note that
     Stop <OVERRUN>
     <OVERRUN> Stop
are both potentially ambiguous.  Was the first message "Stop ... Resume"?
Or, "Stop Now"?  Was the second "Continue ... Stop"?  Or, "Do Not Stop"?

> The interface at issue here is between the Bluegiga/SiLabs Bluetooth
> module and the Kinetis microcontroller.
> The Bluegiga Bluetooth module is a black box; its behavior is fixed.
> I cannot change the receive buffering in this module.

Do you know if it is 'processor-based' or 'dedicated hardware'?
(see below)

> Sounds like most of you think that:
>
> 1) the Kinetis part should be more careful in assuring a valid CTS
>
> 2) the Bluegiga module is faulty:
>    - for not processing at least one character after de-asserting CTS

That's what appears to be the case (see below)

>    - for extremely short CTS de-assertion pulse, and

Why is it a *pulse*?  Does the module effectively use CTS as an
acknowledgement for each character received?  I.e., as if the developer
had written the Rx ISR to drop CTS, read the receive holding register
and then reassert CTS when the character had been "processed"?

[I.e., you can see how this *might* make sense and isn't strictly
problematic -- *if* it was coded to handle the character that is likely
in transit on the heels of the previously received character]

Try watching the signals (data and flow control) with a logic
analyzer and see if there is a fixed, almost immutable relationship
between them.  Almost as if "Received Data Available" was wired
to "Clear to Send", in hardware.  And, waited for the processing
of the character to "reset" the CTS "flag".

>    - for consequently dropping characters transmitted by the Kinetis

If there is *no* incoming FIFO in the device (i.e., just the receiver
holding register), then the above scenario would make sense.  Any
delays in the device's *processing* of the previously received character
would effectively cause the next character to be dropped (or, the
previous overwritten).

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