<?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>TWIM and the proper utilization of the event handler</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/42161/twim-and-the-proper-utilization-of-the-event-handler</link><description>I have been working on a C++ library for the BME280 sensor to be used within the Nordic SDK and am so far only focused on using TWIM, Within this library I intend to use TWIM in a non-blocking manner by utilizing an event handler. The code I will be including</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Thu, 10 Jan 2019 22:44:56 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/42161/twim-and-the-proper-utilization-of-the-event-handler" /><item><title>RE: TWIM and the proper utilization of the event handler</title><link>https://devzone.nordicsemi.com/thread/165033?ContentTypeID=1</link><pubDate>Thu, 10 Jan 2019 22:44:56 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:8afd7276-83aa-4e3d-b86d-9a1fd428c889</guid><dc:creator>Patrick</dc:creator><description>&lt;p&gt;Thank you for the insights Susheel. I was confusing the use of the wait loop and you have cleared that up for me.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: TWIM and the proper utilization of the event handler</title><link>https://devzone.nordicsemi.com/thread/164427?ContentTypeID=1</link><pubDate>Tue, 08 Jan 2019 07:54:21 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ec7dda00-a461-44aa-b51a-0b6a9c4e6fa6</guid><dc:creator>Susheel Nuguru</dc:creator><description>[quote user=""]My first question is, is there any benefit to tracking m_xfer_done and m_read_done separately other than to make clear which transfer type finished?[/quote]
&lt;p&gt;I do not think that there is any extra benefit apart from keeping them separate. These TX and a new RX (Not TXRX) operations are asynchronous/non-blocking. What would happen if you did both TX and then and RX and then doing something else or waiting for this operations to be done. How would your application know if one has failed, then which one did fail? I do not see any big disadvantage in keeping this two separate.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
[quote user=""]My second question is, would there be any benefit to using nrfx_twim_xfer() with a TXRX transfer description? I assume that would allow me to eliminate one wait loop from my readRegister function and only require handling the appropriate transfer type in the event handler. I am also assuming I would only need a single m_xfer_done flag to wait on.[/quote]
&lt;p&gt;In this particular scenario for TXTX,yes your assumptions seems very much valid.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
[quote user=""]Lastly, is the do { __WFE(); } while(!BME280::m_tx_done); all that is needed to keep these functions non-blocking? The key part being __WFE().[/quote]
&lt;p&gt;&amp;nbsp;The example did not have anything else to do even after the non-blocking call. Some applications would like to do something else instead of blocking wait of the transfer. If your application has some other tasks that could be done which are not depending on this transfer, then you can eliminate the while loop and finish your task. But as soon as your application becomes dependable for this transfer to be complete to move on, then it needs to wait like this wrapping the __WFE on the condition of the transfer flag being set.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>