<?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>UARTE ENDTX event latency</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/30494/uarte-endtx-event-latency</link><description>According to the User Guide, 
 After each byte has been sent over the TXD line, a TXDRDY event will be generated. 
 When all bytes in the TXD buffer, as specified in the TXD.MAXCNT register, have been transmitted, the UARTE transmission will end automatically</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 16 Feb 2018 10:01:58 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/30494/uarte-endtx-event-latency" /><item><title>RE: UARTE ENDTX event latency</title><link>https://devzone.nordicsemi.com/thread/121060?ContentTypeID=1</link><pubDate>Fri, 16 Feb 2018 10:01:58 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:fe91377b-4c22-49e0-9c1b-01cb296be7fc</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;If you need to add a delay after the ENDTX event, you must use a timer. I have added this in the code below:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;#define ENDTX_GPIOTE_CH 0
#define ENDTX_GPIOTE_CH_A 0
#define TIMER_CAPTURE_CH 1
#define TIMER_COMPARE_CC_NUM 0
#define TIMER_CAPTURE_DELAY_US 2

#define TIMER_RELOAD 1024
#define TIMER_RELOAD_CC_NUM 5

void timer_init(void)
{
    NRF_TIMER3-&amp;gt;BITMODE                 = TIMER_BITMODE_BITMODE_24Bit &amp;lt;&amp;lt; TIMER_BITMODE_BITMODE_Pos;
    NRF_TIMER3-&amp;gt;PRESCALER               = 4;
    NRF_TIMER3-&amp;gt;SHORTS                  = TIMER_SHORTS_COMPARE0_CLEAR_Msk &amp;lt;&amp;lt; TIMER_RELOAD_CC_NUM;
    NRF_TIMER3-&amp;gt;MODE                    = TIMER_MODE_MODE_Timer &amp;lt;&amp;lt; TIMER_MODE_MODE_Pos;
    NRF_TIMER3-&amp;gt;CC[TIMER_RELOAD_CC_NUM] = TIMER_RELOAD;
    NRF_TIMER3-&amp;gt;CC[TIMER_COMPARE_CC_NUM]= TIMER_CAPTURE_DELAY_US;
}

void timer_start(void)
{
    NRF_TIMER3-&amp;gt;TASKS_START = 1;
}

void attach_ENDTX_to_pin(uint32_t pinselect)
{
    NRF_GPIOTE-&amp;gt;CONFIG[ENDTX_GPIOTE_CH]     = GPIOTE_CONFIG_MODE_Task &amp;lt;&amp;lt; GPIOTE_CONFIG_MODE_Pos |
                                              GPIOTE_CONFIG_POLARITY_Toggle &amp;lt;&amp;lt; GPIOTE_CONFIG_POLARITY_Pos |
                                              pinselect &amp;lt;&amp;lt; GPIOTE_CONFIG_PSEL_Pos |
                                              GPIOTE_CONFIG_OUTINIT_High &amp;lt;&amp;lt; GPIOTE_CONFIG_OUTINIT_Pos;
    
    NRF_PPI-&amp;gt;CH[ENDTX_GPIOTE_CH_A].EEP      = (uint32_t)&amp;amp;NRF_UARTE0-&amp;gt;EVENTS_ENDTX;
    NRF_PPI-&amp;gt;CH[ENDTX_GPIOTE_CH_A].TEP      = (uint32_t)&amp;amp;NRF_TIMER3-&amp;gt;TASKS_CLEAR;
    NRF_PPI-&amp;gt;FORK[ENDTX_GPIOTE_CH_A].TEP    = (uint32_t)&amp;amp;NRF_GPIOTE-&amp;gt;TASKS_SET;
    NRF_PPI-&amp;gt;CH[TIMER_CAPTURE_CH].EEP       = (uint32_t)&amp;amp;NRF_TIMER3-&amp;gt;EVENTS_COMPARE[TIMER_COMPARE_CC_NUM];
    NRF_PPI-&amp;gt;CH[TIMER_CAPTURE_CH].TEP       = (uint32_t)&amp;amp;NRF_GPIOTE-&amp;gt;TASKS_CLR[ENDTX_GPIOTE_CH];
    
    
    NRF_PPI-&amp;gt;CHENSET = (1 &amp;lt;&amp;lt; ENDTX_GPIOTE_CH_A) | (1 &amp;lt;&amp;lt; TIMER_CAPTURE_CH);
}

int main(void)
{
    ...init_uart...
    timer_init();
    timer_start();
    attach_ENDTX_to_pin(22);
}&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;This will toggle the pin after&amp;nbsp;TIMER_CAPTURE_DELAY_US microseconds.&lt;/p&gt;
&lt;p&gt;You can use the EGU (event generation unit) to do something useful instead of toggling the pin, but as you can see, the pin will go low (in this case) 2µs after the last byte is sent.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;img src="https://devzone.nordicsemi.com/resized-image/__size/320x240/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-745295b87438461683340a52d3b88dd1/pastedimage1518775315858v1.png" alt=" " /&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: UARTE ENDTX event latency</title><link>https://devzone.nordicsemi.com/thread/121000?ContentTypeID=1</link><pubDate>Thu, 15 Feb 2018 15:54:50 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:99f9a45c-b81f-414d-a158-742c573fd852</guid><dc:creator>KV</dc:creator><description>&lt;p&gt;Thanks Edvin.&lt;/p&gt;
&lt;p&gt;For our use case, the transmit section and receive section of hardware cannot be enabled at the same time. If I have to wait until all the bytes are completely transmitted, this method may not work because the transmit section would be turned off before the stop bit of the last byte is transmitted. Ther could be framing errors on other side.&lt;/p&gt;
&lt;p&gt;Some MCUs have TX_COMPLETE interrupt which is asserted after stop bit is sent out.&lt;/p&gt;
&lt;p&gt;How do I address this scenario?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: UARTE ENDTX event latency</title><link>https://devzone.nordicsemi.com/thread/120980?ContentTypeID=1</link><pubDate>Thu, 15 Feb 2018 12:53:54 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a5b0084f-91ee-4299-af19-8346849e26d8</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;If you want to test yourself, here is the piece of code that I used to test:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="text"&gt;void attach_ENDTX_to_pin(uint32_t pinselect)
{
    NRF_GPIOTE-&amp;gt;CONFIG[ENDTX_GPIOTE_CH] =   GPIOTE_CONFIG_MODE_Task &amp;lt;&amp;lt; GPIOTE_CONFIG_MODE_Pos |
                                            GPIOTE_CONFIG_POLARITY_Toggle &amp;lt;&amp;lt; GPIOTE_CONFIG_POLARITY_Pos |
                                            pinselect &amp;lt;&amp;lt; GPIOTE_CONFIG_PSEL_Pos |
                                            GPIOTE_CONFIG_OUTINIT_High &amp;lt;&amp;lt; GPIOTE_CONFIG_OUTINIT_Pos;
    
    NRF_PPI-&amp;gt;CH[ENDTX_GPIOTE_CH_A].EEP  =   (uint32_t)&amp;amp;NRF_UARTE0-&amp;gt;EVENTS_ENDTX;
    NRF_PPI-&amp;gt;CH[ENDTX_GPIOTE_CH_A].TEP  =   (uint32_t)&amp;amp;NRF_GPIOTE-&amp;gt;TASKS_CLR[ENDTX_GPIOTE_CH];
    
    NRF_PPI-&amp;gt;CHENSET = (1 &amp;lt;&amp;lt; ENDTX_GPIOTE_CH_A);
}

int main(void)
{
    ...init_uart...
    
    attach_ENDTX_to_pin(22);    //use e.g. pin 20 to use LED4 (nRF52832)
    
    printf(&amp;quot;Start: \r\n&amp;quot;);

}&lt;/pre&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: UARTE ENDTX event latency</title><link>https://devzone.nordicsemi.com/thread/120978?ContentTypeID=1</link><pubDate>Thu, 15 Feb 2018 12:50:19 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:7e96c0fc-0717-4d24-9a35-6136a9a8e8a8</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;I tested with 115200 baud rate, and a PPI set up to change a pin at the ENDTX event. As you can see, the event is set at the very end of the last payload bit, and right before the stop bit. Screenshot below shows the TX line on Channel 0 and the pin that switched on ENDTX on Channel 1.&lt;/p&gt;
&lt;p&gt;&lt;img src="https://devzone.nordicsemi.com/resized-image/__size/320x240/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-745295b87438461683340a52d3b88dd1/pastedimage1518698603869v1.png" alt=" " /&gt;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;I also tested it with the 1M baudrate. As you can see there is a tiny delay, but it is less than 0.3µs.&lt;/p&gt;
&lt;p&gt;&lt;img src="https://devzone.nordicsemi.com/resized-image/__size/320x240/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-745295b87438461683340a52d3b88dd1/pastedimage1518698821055v2.png" alt=" " /&gt;&lt;/p&gt;
&lt;p&gt;The same delay is on the 115200 baudrate, but of course it is neglectable with that baudrate.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Edvin&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>