<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>UART Hardware handshaking controlling RTS/CTS over run</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/33155/uart-hardware-handshaking-controlling-rts-cts-over-run</link><description>After experiencing UART problems without handshaking I opted to enable hardware handshaking. 
 Where RTS &amp;amp; CTS are pins 5 &amp;amp; 7 respectively. 
 I was experiencing overrun (insufficient memory) issues without hardware handshaking, however I see the same</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Sat, 07 Apr 2018 08:19:32 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/33155/uart-hardware-handshaking-controlling-rts-cts-over-run" /><item><title>RE: UART Hardware handshaking controlling RTS/CTS over run</title><link>https://devzone.nordicsemi.com/thread/127278?ContentTypeID=1</link><pubDate>Sat, 07 Apr 2018 08:19:32 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6b1f3183-8e45-4431-a52a-8a328c6e8bb5</guid><dc:creator>venerley</dc:creator><description>&lt;p&gt;Thanks for your input. I must admit sadly I am reaching similar conclusion for my scenario, I just cannot get the level of control I appear to need from the SDK. I am thinking I might end up creating a simple diode OR&amp;nbsp;combining my custom line with&amp;nbsp;the Nordic RTS. You may be interested in this from &lt;a href="https://www.lairdtech.com/blog/uart-flow-control-rtscts-necessary-proper-operation-wireless-modules"&gt;Laird&lt;/a&gt;&amp;nbsp;and also the bottom of page 335 in the &lt;a href="http://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.4.pdf"&gt;nRF52832 product spec&lt;/a&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: UART Hardware handshaking controlling RTS/CTS over run</title><link>https://devzone.nordicsemi.com/thread/127267?ContentTypeID=1</link><pubDate>Fri, 06 Apr 2018 18:51:08 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:f9c473da-6ee6-4e75-a0bb-85da253409c4</guid><dc:creator>hmolesworth</dc:creator><description>&lt;p&gt;I am also interested in the RTS/CTS operation. As far as I am aware, it is actually a hardware implementation on the UART and so can be enabled or disabled but otherwise not affected by software. In my tests it does not work well with terminal programs like Termite, since the mode of operation seems inverted. There are two interpretations of RTS/CTS operation, traditional modem style and more recent embedded systems. These are my notes:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;/ * Traditional Modem Flow Control
 * If flow control is enabled, a transmission will be automatically suspended when CTS is deactivated and
 * resumed when CTS is activated again.
 * A byte that is in transmission when CTS is deactivated will be fully transmitted before the transmission is
 * suspended.
 * nRF52 DTE Output pin to DCE - asserts to request transmit
 * nRF52 DTE Input pin from DCE - asserts to allow transmit
 *
 * Hardware Flow Control
 * &amp;quot;RTS/CTS handshaking&amp;quot; the DTE asserts RTS whenever it is ready to receive data from the DCE, and the DCE
 * asserts CTS whenever it is ready to receive data from the DTE. Unlike the original use of RTS and CTS with
 * half-duplex modems, these two signals operate independently from one another.
 * nRF52 DTE Output pin to DCE - asserts to allow DCE to transmit
 * nRF52 DTE Input pin from DCE - asserts to allow nRF52 DTE transmit
 */&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;One assumes that the latter is used on the nRF52832, but being active low it doesn&amp;#39;t seem to work in the way Termite expects. Traditional modem operation I think was active low, but embedded system mode I thought was active high. &amp;quot;Assert&amp;quot; in the case of nRF52832 is active low.&lt;/p&gt;
&lt;p&gt;In your particular case you might just use the RTS/CTS as io ports and manually control them, since it looks like only occasionally they need to be inactive.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>