How to use NetX / NetXDuo in Azure RTOS (ThreadX) in conjunction with the ThreadX Modules feature?

[nettercm]

Background:

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.  Each application is isolated from other applications and from the ThreadX kernel.  Applications run in a less privileged mode compared to the ThreadX kernel.  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().  

Question:   what's the right way of using NetX / NetXDuo in this case?   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".    It's not immediately clear what the creators of ThreadX / NetX have envisioned.  

If part of the application, it means every application would contain its own copy of the network stack.  Even if we are OK w/ the resulting inefficiency, it's not even clear how that would work.  What if 2 applications both want to use the network stack on the same ethernet port?

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?  In ThreadX, one gets the txm_xyz() versions of all the tx_xyz() APIs.  There are no nxm_xyz() versions of the NetX nx_xyz() APIs....  There are many many nx_xyz() APIs...

Thoughts?

[EdwinHz]

Hi @nettercm,

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 "ThreadX Module" 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.

That said, as you mentioned it isn't very clear what the creators envisioned, but I would highly recommend going to the Azure Community and asking the creators themselves, as they would most likely be able to provide you with a much better answer than mine.

Still, I hope this helps.

BR,
Edwin.