为什么cmsis要求最大的优先级为64

Question

我正在尝试使用ThreadX在我的项目上实现CMSIS。我在文件cmsis_os2.c中发现，最大优先级为64是必须的。我想把它保持到32 (ram优化)，所以有人解释了为什么我应该使用64而不是32。它是否麻烦使用32并简单地修改cmsis文件？这是我找到的代码：

/* Ensure the maximum number of priorities is modified by the user to 64. */
#if(TX_MAX_PRIORITIES != 64)
#error "CMSIS RTOS ThreadX Wrapper: TX_MAX_PRIORITIES must be fixed to 64 in tx_user.h file"
#endif

Answer 1

CMSIS使用enum osPriority_t枚举优先级。在我看来，这是一个糟糕的想法，但它限制了实现，如果不打破抽象，就很难改变。

在ThreadX中，具有64个而非32个优先级的优先级会带来128个字节的开销(因此不会对RAM进行过多的优化)。如果这确实是一个问题，那么您可以在移植层将CMSIS 64优先级映射为32个级别，只需在使用本机API创建任务时将优先级除以2即可。但是，这可能会修改调度，因为优先级为Nx2和(Nx2)+1的任务都将映射到相同的优先级N。

更改优先级数量的另一个问题是，将代码移植到不同的CMSIS RTOS2实现可能会改变调度行为，而这反而会破坏抽象对象。

您必须注意CMSIS的RTOS2优先级，因为实际上只有47个从8到55个用于用户任务，这可以从枚举中看到。保留0、1和56，2到7不进行枚举。这些映射到本机优先级的方式取决于实现，如果要更改实现，则仍然必须考虑保留的值。因此，不确保整数优先级在osPriorityLow到osPriorityRealtime7的范围内，就直接传递整数优先级是不可取的。总的来说，这不是一个完美的抽象概念。

ThreadX可能是不寻常的，因为它与优先级级别的数量有关。在任何情况下，拥有一个可配置的优先级级别也是不寻常的。在许多RTOS中，它是一个8或16位整数。

Answer 2

这是一个CMSIS问题，而不是Azure RTOS问题。你得问问CMSIS的人。