Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #25266
| 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> |
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
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