在 8051 这类资源受限的单片机平台上，RTOS 内核设计不仅需要考虑任务调度、中断响应和功能完整性，还必须严格控制 RAM 占用。
对于一个长期维护的嵌入式操作系统而言，内存优化并不一定意味着重新设计内核。有时，在功能需求明确的前提下，重新审视资源对象的最大数量，同样能够带来实际收益。
近期，HRTOS 4.0 对内核资源配置进行了进一步收敛：OS_RESOURCE_MAX 从 8 调整为 6，OS_MSGQ_MAX 从 4 调整为 3，而任务控制块 OS_TCB 的结构保持不变。
这次调整的重点，是在维持现有任务管理机制的基础上，进一步优化内核对象的静态资源配置。
一、调整了哪些配置？
本次修改涉及两个内核配置宏。
#define OS_RESOURCE_MAX 6
#define OS_MSGQ_MAX 3调整前后的对比如下：
| 配置项 | 调整前 | 调整后 | 变化 |
|---|---|---|---|
OS_RESOURCE_MAX |
8 | 6 | 减少 2 个 |
OS_MSGQ_MAX |
4 | 3 | 减少 1 个 |
OS_TCB 结构 |
原有定义 | 保持不变 | 无变化 |
这里需要明确：减少的是内核允许配置的资源对象与消息队列最大数量，并不意味着删除了对应的内核机制。
如果系统通过固定长度数组管理这些对象，那么减少最大数量可以缩小相应数组的容量，进而降低静态内存需求。
具体节省的字节数，则需要结合实际数组定义、结构体大小和编译器生成的内存布局进行确认。
二、为什么不直接修改任务控制块？
HRTOS 的任务控制块 OS_TCB 负责保存任务调度与等待管理所需的信息。
当前结构如下：
typedef struct
{
u8 base_prio; /* 静态优先级 */
u8 cur_prio; /* 动态优先级 */
u8 state; /* 任务状态 */
u8 wait_type; /* 等待类型 */
u8 wait_flag; /* 等待结果 */
u8 wait_obj; /* 等待对象 ID */
u16 wait_tick; /* 超时等待 tick */
} OS_TCB;从结构可以看出，任务控制块不仅保存静态优先级和当前优先级，还统一记录任务状态、等待类型、等待结果、等待对象以及超时计数。
这种设计将多种等待场景所需的信息集中在任务控制块中，有利于统一管理任务等待与唤醒过程。
本次调整没有修改 OS_TCB，意味着任务控制块的字段布局和对应的管理机制不因这两个配置宏的变化而改变。
对于已经进入稳定维护阶段的内核，能够通过配置层面的调整解决资源需求，而不必随意修改核心数据结构，有助于控制变更范围，降低回归验证的成本。
三、统一资源对象设计
HRTOS 使用统一的 OS_RESOURCE 结构管理内核资源对象。
typedef struct
{
u8 value;
u8 owner;
u8 wait_cnt;
u16 wait_mask;
u8 pending_signal;
} OS_RESOURCE;该结构包含资源值、所有者信息、等待任务数量、等待任务位图以及中断侧的待处理信号计数。
其中，owner 主要用于互斥锁相关场景；wait_cnt 和 wait_mask 用于维护等待任务信息；pending_signal 用于记录 ISR 中断计数。
等待队列采用 16 位位图表示任务集合：
-
bit0 对应 task0；
-
bit1 对应 task1；
-
依此类推；
-
bit15 对应 task15。
与为每个资源对象单独维护一组任务编号相比，位图可以紧凑地表达固定任务集合。不过，位图是否在执行效率和代码体积上更优，还取决于具体实现和目标编译器。
本次将 OS_RESOURCE_MAX 从 8 调整为 6，意味着在采用固定容量对象数组的前提下，系统允许同时配置的这类资源对象数量减少了两个。
这项修改不改变单个 OS_RESOURCE 的字段定义，而是调整对象数量上限。
四、消息队列数量调整
HRTOS 的消息队列结构如下：
typedef struct
{
u8 *buf;
u8 _size;
u8 head;
u8 tail;
u8 count;
} os_msgq_t;消息队列使用缓冲区指针、队列容量、读写位置和当前消息数量管理数据。
其中：
-
buf指向实际消息缓冲区； -
_size表示队列容量； -
head用于记录写入位置； -
tail用于记录读取位置； -
count用于记录当前队列中的消息数量。
本次将 OS_MSGQ_MAX 从 4 调整为 3，即将消息队列对象的最大数量减少一个。
需要注意，减少消息队列对象数量与减少单个消息队列的缓冲区容量是两件不同的事情。
前者主要影响队列控制结构的数量；后者则可能直接影响消息缓冲区的内存需求。本次配置调整针对的是前者，并不能据此推断每个消息队列的容量发生了变化。
五、为什么资源受限平台需要关注这些细节？
在 8051 平台上，内存通常是影响系统设计的重要约束。
与资源充足的平台相比，8051 RTOS 需要更加谨慎地安排任务控制块、任务栈、内核对象和消息缓冲区等资源。
内核对象的数量上限看起来只是几个宏定义，但它反映了系统对资源规模的规划。
如果某项配置长期高于实际需求，那么固定容量数组可能会占用本可以留给其他模块的内存。
反过来，如果上限设置得过低，也可能导致应用无法创建足够的资源对象。因此，合理的做法不是一味追求最小值，而是在实际使用需求与资源预算之间找到合适的平衡。
对于 HRTOS 这样的 8051 操作系统，内存优化需要综合考虑：
-
任务数量和任务栈需求；
-
资源对象数量；
-
消息队列数量及各队列缓冲区容量；
-
中断与任务上下文保存开销；
-
应用程序自身的数据需求。
单独调整某个宏，只是整体资源管理的一部分；最终效果仍应以实际编译结果和目标硬件验证为准。
六、稳定维护阶段的优化思路
HRTOS 4.0 当前更加重视已有内核的稳定性和细节完善，而不是频繁增加功能或修改版本号。
在这一阶段，修改应当尽可能明确、可验证，并且控制影响范围。
本次配置调整有几个特点：
-
只修改资源对象和消息队列的数量上限；
-
保持任务控制块结构不变；
-
保持资源对象和消息队列的字段定义不变；
-
将验证重点放在内存占用、资源创建边界以及相关功能回归上。
这样的修改范围相对集中，但仍然需要验证：减少对象数量后，资源创建达到上限时的行为是否正确，相关接口是否能够正确拒绝超出配置上限的请求，以及现有应用是否依赖原先更大的对象数量。
只有这些检查都符合预期，才能确认调整不会影响既有功能。
总结
HRTOS 4.0 本次内核资源配置调整，将 OS_RESOURCE_MAX 从 8 降至 6，将 OS_MSGQ_MAX 从 4 降至 3，同时保持 OS_TCB 结构不变。
这不是对内核机制的大规模重构，而是针对固定容量内核对象进行的一次配置收敛。
对于资源受限的 8051 平台，操作系统的内存管理不仅取决于数据结构如何设计，也取决于对象数量上限是否合理。
稳定的内核不仅需要功能完善，也需要资源配置清晰、内存占用可控，并且每次调整都能够通过编译结果和回归测试进行验证。
这也是 HRTOS 4.0 持续打磨过程中值得坚持的方向。