Build Module without resident code

Question

Build Module without resident code

HugPeter-9392 246

Hello
I wonder if it is possible to build a module without access to the source code of the resident firmware.

We think about a core (resident firmware) that contains ThreadX, device drivers, protocol stacks, services, etc. The application logic gets placed into a module. I wonder if such a module can also be build without access to the core (resident firmware). We think about allowing OEM and end customers to replace a module that contains application logic.

HugPeter-9392 246 Reputation points

2022-03-21T07:34:06.62+00:00

For clarification: Core (resident firmware) and module (XX binary in the figure above) need to exchange data and control. But the two need to be separate when building them. The source code of the core (resident firmware) should not be needed when a customer or OEM creates a custom module binary.
António Sérgio Azevedo 7,671 Reputation points Microsoft Employee Moderator

2022-03-21T15:11:47.943+00:00

Hello @HugPeter-9392 ,

As per the documentation here : "Memory protection for the loaded module is optional, based on the properties specified in the module preamble. When memory protection is specified, the processor's memory management hardware is configured such that all threads of the module are only allowed access to the module's code and data memory. "

It is my understanding that what you need to do in your scenario is to enable memory protection. Let me know if I got it right?

Thanks!

Accepted answer

0 additional answers

Your answer

HugPeter-9392 246 Reputation points

2022-03-21T07:34:06.62+00:00

For clarification: Core (resident firmware) and module (XX binary in the figure above) need to exchange data and control. But the two need to be separate when building them. The source code of the core (resident firmware) should not be needed when a customer or OEM creates a custom module binary.
António Sérgio Azevedo 7,671 Reputation points Microsoft Employee Moderator

2022-03-21T15:11:47.943+00:00

Hello @HugPeter-9392 ,

As per the documentation here : "Memory protection for the loaded module is optional, based on the properties specified in the module preamble. When memory protection is specified, the processor's memory management hardware is configured such that all threads of the module are only allowed access to the module's code and data memory. "

It is my understanding that what you need to do in your scenario is to enable memory protection. Let me know if I got it right?

Thanks!

Answer 1

Scott Azure RTOS 4,051

Hi @HugPeter-9392 , what you are describing is exactly what Modules was designed to do. The OEM will flash the ThreadX kernel and manager application into the chip. And build the module library for the third-party app developers to link to (you make this library available to the app developers to link their application to). Memory protection is irrelevant - the resident manager can choose whether a module requires memory protection or not. If you would like to discuss offline, please email azure-rtos-support@microsoft.com and I'll get back to you there or if you'd like a phone call, we can do that too.

HugPeter-9392 246 Reputation points

2022-03-22T07:56:17.07+00:00

Hello Scott
When I understand you correctly, the following picture shows a preferred way to structure a solution.

What I want to highlight is that third party developers that develop the modules within the red rectangle do not need access to the source code of the remaining modules and the Platform Core. Such third party developer need header files and the static library named 'Library A' in the figure. But nothing more.

Platform Core contains ThreadX, the Module Manger. It optionally contains e.g. services and communication stacks that are always present. But services and communication stacks could also be moved into a module.

Module Manager is the only interaction point from/to/between modules

Thanks
Scott Azure RTOS 4,051 Reputation points

2022-03-22T17:06:51.833+00:00

Hi @HugPeter-9392

I think we are both saying the same thing. The third-party developers only need the static "ThreadX module library" and header files.

The static "ThreadX module library" is everything in https://github.com/azure-rtos/threadx/tree/master/common_modules/module_lib/src and (e.g. for Cortex-M4 gcc) https://github.com/azure-rtos/threadx/tree/master/ports_module/cortex_m4/gnu/module_lib/src

These are just shell functions that allow the module to call kernel functions. Is there something else you're trying to do that I'm not understanding?

Share via

Build Module without resident code

0 additional answers

Your answer