<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>MCUXpresso SDKのトピックRe: How to use NetX / NetXDuo in Azure RTOS (ThreadX) in conjunction with the ThreadX Modules featur</title>
    <link>https://community.nxp.com/t5/MCUXpresso-SDK/How-to-use-NetX-NetXDuo-in-Azure-RTOS-ThreadX-in-conjunction/m-p/1747303#M4523</link>
    <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/180565"&gt;@nettercm&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;This is a very good question that I'm afraid I will most likely not be able to answer fully. I believe using this implementation of "&lt;SPAN&gt;ThreadX Module&lt;/SPAN&gt;" components would mean that each application contains its own copy of the network stack. This would in fact be inefficient, but I believe the same component implementation would prevent collisions if two applications would want to use the same ethernet port, as it would only load one at a time.&lt;/P&gt;
&lt;P&gt;That said, as you mentioned it isn't very clear what the creators envisioned, but I would highly recommend going to the &lt;A href="https://techcommunity.microsoft.com/t5/azure/ct-p/Azure" target="_self"&gt;Azure Community&lt;/A&gt; and asking the creators themselves, as they would most likely be able to provide you with a much better answer than mine.&lt;/P&gt;
&lt;P&gt;Still, I hope this helps.&lt;/P&gt;
&lt;P&gt;BR,&lt;BR /&gt;Edwin.&lt;/P&gt;</description>
    <pubDate>Thu, 26 Oct 2023 19:00:38 GMT</pubDate>
    <dc:creator>EdwinHz</dc:creator>
    <dc:date>2023-10-26T19:00:38Z</dc:date>
    <item>
      <title>How to use NetX / NetXDuo in Azure RTOS (ThreadX) in conjunction with the ThreadX Modules feature?</title>
      <link>https://community.nxp.com/t5/MCUXpresso-SDK/How-to-use-NetX-NetXDuo-in-Azure-RTOS-ThreadX-in-conjunction/m-p/1742971#M4511</link>
      <description>&lt;P&gt;Background:&lt;/P&gt;&lt;P&gt;Azure RTOS aka ThreadX has a feature, called "modules", that takes advantage of the CPU's memory protection unit / memory management unit (MPU or MMU used in must MPU mode) and which allows for separate applications to be loaded / unloaded at runtime.&amp;nbsp; Each application is isolated from other applications and from the ThreadX kernel.&amp;nbsp; Applications run in a less privileged mode compared to the ThreadX kernel.&amp;nbsp; When an application calls a ThreadX API, e.g., tx_thread_create(), that actually translates (via macro...) to a call into txm_thrad_create(), which first switches to a higher CPU privilege mode before calling the actual implementation, _tx_thread_create().&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Question:&amp;nbsp; &amp;nbsp;what's the right way of using NetX / NetXDuo in this case?&amp;nbsp; &amp;nbsp;Would the NetX TCP/IP stack (along with any addons that the application might need such as mqtt, azure_iot, websocket, etc. etc.) be part of the application, or part of the "Kernel".&amp;nbsp; &amp;nbsp; It's not immediately clear what the creators of ThreadX / NetX have envisioned.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;If part of the application, it means every application would contain its own copy of the network stack.&amp;nbsp; Even if we are OK w/ the resulting inefficiency, it's not even clear how that would work.&amp;nbsp; What if 2 applications both want to use the network stack on the same ethernet port?&lt;/P&gt;&lt;P&gt;On the other hand, if the network stack is part of the Kernel, then are we expected to implement the switch to kernel mode ourselves?&amp;nbsp; In ThreadX, one gets the txm_xyz() versions of all the tx_xyz() APIs.&amp;nbsp; There are no nxm_xyz() versions of the NetX nx_xyz() APIs....&amp;nbsp; There are many many nx_xyz() APIs...&lt;/P&gt;&lt;P&gt;Thoughts?&lt;/P&gt;</description>
      <pubDate>Thu, 19 Oct 2023 13:48:08 GMT</pubDate>
      <guid>https://community.nxp.com/t5/MCUXpresso-SDK/How-to-use-NetX-NetXDuo-in-Azure-RTOS-ThreadX-in-conjunction/m-p/1742971#M4511</guid>
      <dc:creator>nettercm</dc:creator>
      <dc:date>2023-10-19T13:48:08Z</dc:date>
    </item>
    <item>
      <title>Re: How to use NetX / NetXDuo in Azure RTOS (ThreadX) in conjunction with the ThreadX Modules featur</title>
      <link>https://community.nxp.com/t5/MCUXpresso-SDK/How-to-use-NetX-NetXDuo-in-Azure-RTOS-ThreadX-in-conjunction/m-p/1747303#M4523</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/180565"&gt;@nettercm&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;This is a very good question that I'm afraid I will most likely not be able to answer fully. I believe using this implementation of "&lt;SPAN&gt;ThreadX Module&lt;/SPAN&gt;" components would mean that each application contains its own copy of the network stack. This would in fact be inefficient, but I believe the same component implementation would prevent collisions if two applications would want to use the same ethernet port, as it would only load one at a time.&lt;/P&gt;
&lt;P&gt;That said, as you mentioned it isn't very clear what the creators envisioned, but I would highly recommend going to the &lt;A href="https://techcommunity.microsoft.com/t5/azure/ct-p/Azure" target="_self"&gt;Azure Community&lt;/A&gt; and asking the creators themselves, as they would most likely be able to provide you with a much better answer than mine.&lt;/P&gt;
&lt;P&gt;Still, I hope this helps.&lt;/P&gt;
&lt;P&gt;BR,&lt;BR /&gt;Edwin.&lt;/P&gt;</description>
      <pubDate>Thu, 26 Oct 2023 19:00:38 GMT</pubDate>
      <guid>https://community.nxp.com/t5/MCUXpresso-SDK/How-to-use-NetX-NetXDuo-in-Azure-RTOS-ThreadX-in-conjunction/m-p/1747303#M4523</guid>
      <dc:creator>EdwinHz</dc:creator>
      <dc:date>2023-10-26T19:00:38Z</dc:date>
    </item>
  </channel>
</rss>

