在 ThreadX 权限中绘制模块和模块管理器之间的界限答案

【问题标题】：Drawing the line between Module and ModuleManager in ThreadX priviliges在 ThreadX 权限中绘制模块和模块管理器之间的界限
【发布时间】：2022-08-15 23:44:35
【问题描述】：

在支持 MPU 的平台中将 Module 和 ModuleManager 与 ThreadX 一起使用 \"default_module_start\" 是否被视为 ModuleManager 的一部分并且可以调用 Tx API，即使它位于 app_module.c 中？ E.G tx_thread_create 在 default_module_start 中工作，但在模块线程中不起作用并通过异常；

另一个问题是为什么 ModuleManager 不只是使用 Tx API 来处理威胁，而是使用完全不调用 Tx API 的自定义函数

标签： rtos threadx azure-rtos

【解决方案1】：

函数 demo_module_start 是模块的一部分（此函数在 sample_threadx_module.c 中）。它在模块上下文中运行。这个函数在模块启动时被 txm_module_thread_shell_entry.c 调用。

模块在非特权模式下运行，但它们调用 ThreadX API（也称为内核函数）。为了执行 ThreadX API，模块使用 SVC 指令（用于 ARM 处理器）进入主管（特权）模式。因此，在模块库中，所有内核调用只是将函数参数传递给内核的简单调用，而实际的 ThreadX 函数是在内核（特权）模式下执行的。

让我知道这是否回答了您的问题或者您还有其他问题。

编辑：

您可以从模块线程调用 TX API。默认情况下，它们通过 SVC 指令进入内核。如果您想直接从模块调用 TX API（即不进行捕获），则该模块需要处于特权模式执行，您可以通过修改模块前导码中的模块属性进行配置（例如，参见 https://github.com/azure-rtos/threadx/blob/master/ports_module/cortex_m7/gnu/example_build/txm_module_preamble.S - 更改从 0x00000007 到 0x00000000 的属性）。

创建模块线程与创建普通线程有点不同。管理器将 TXM_MODULE_THREAD_ENTRY_INFO 放入模块线程堆栈，为线程分配内核堆栈，构建模块线程堆栈（与普通线程具有不同的返回模式）。

经理可以拥有您想要分配的任何优先级。大多数（如果不是全部）我们的模块管理器示例都将优先级分配为 1 (https://github.com/azure-rtos/threadx/blob/master/ports_module/cortex_m7/gnu/example_build/sample_threadx_module_manager.c)。

【讨论】：

谢谢你的澄清，我的问题是为什么不能我从“模块线程条目”（通过故障处理程序、内存冲突）调用 Tx API，但我可以在“default_module_start”中调用它们。 Q2：为什么 ModuleManager 不只是使用 Tx API 来处理威胁，而是使用完全不调用 Tx API 的自定义函数（例如 txm_module_manager_thread_create）？这两个线程有什么区别？为什么当 MM 是管理模块且具有特权的模块时，ModuleManager 的优先级（4）低于模块
嗨@Hamdim，请参阅我编辑的答案。