在一个真正复杂的实时操作系统中，能够运行只是基础，能够观察系统运行状态、定位资源使用情况并辅助分析异常，才意味着系统逐渐具备完整的工程化能力。

对于 8051 这样资源极其有限的单片机平台而言，实现一套完整的系统级 Debug 机制并不容易。

因此，在完成 HRTOS 4.0 内核、任务调度、同步通信、中断管理以及大量实际硬件验证之后，HRTOS 进一步增加了独立的 HRTOS Debug 调试与运行状态监控组件。

此次版本已经完成实际测试，现正式介绍这一组件。

---

一、为什么 8051 RTOS 也需要 Debug？

很多 8051 项目中的 RTOS 调试方式比较简单：

• 打印任务状态

• 打印变量

• 查看某个计数器

• 出现死机以后人工分析

• 通过串口输出部分运行信息

这种方式对于简单多任务程序尚可，但当系统逐渐复杂以后，会出现一个非常明显的问题：

系统能够运行，但开发者不知道系统究竟是怎样运行的。

例如：

• 当前到底有哪些任务？

• 哪个任务正在运行？

• 任务优先级是多少？

• 哪个任务正在等待？

• 任务等待了什么对象？

• 任务栈用了多少？

• 栈空间是否已经接近极限？

• 当前系统 CPU 负载是多少？

• 有多少任务处于等待状态？

• 消息队列当前积压了多少数据？

• 哪些资源存在等待？

• 是否存在待删除任务？

这些信息如果无法直接观察，就很难对一个复杂实时系统进行工程级分析。

因此，HRTOS Debug 的设计目标并不是简单增加几个打印函数，而是：

让 HRTOS 内核内部的重要运行状态能够被系统化地观察。

---

二、HRTOS Debug 的定位

HRTOS Debug 是 HRTOS 生态中的独立调试与运行状态监控组件。

它不改变 HRTOS 的核心调度模型，也不替代 Shell，而是专注于：

运行状态获取 → 数据分析 → 调试输出

目前主要覆盖以下几个方面：

模块	监控内容
CPU	CPU 使用率
TASK	任务状态、任务优先级
STACK	任务栈申请、使用率、剩余空间
WAIT	任务等待状态及等待对象
EVENT	Event 等待信息
RESOURCE	资源状态、所有者、等待数量
MSGQ	消息队列数量及当前数据量
DELETE	待删除任务状态

这意味着 Debug 已经不是单纯的“任务查看器”，而是开始覆盖 HRTOS 内核中的多个核心对象。

---

三、任务状态监控

任务是 RTOS 的核心对象之一。

HRTOS Debug 可以对任务进行统一查看。

例如测试结果：

========== Task Test ==========

[Single Task]
Task 0: State=1, Priority=0, DeletePending=0
Task 1: State=1, Priority=1, DeletePending=0
Task 2: State=0, Priority=0, DeletePending=0
...
Task 15: State=0, Priority=0, DeletePending=0

[Task State All]
Task 0: 1
Task 1: 1
Task 2: 0
...
Task 15: 0

[Task Priority All]
Task 0: 0
Task 1: 1
Task 2: 0
...
Task 15: 0

[Delete Pending All]
Task 0: 0
Task 1: 0
...
Task 15: 0

Delete Pending Count: 0

从这些信息可以直接观察：

• 当前任务状态

• 当前任务优先级

• 删除等待状态

• 全部任务状态

• 全部任务优先级

• 待删除任务数量

在当前测试中，系统配置了 16 个普通任务槽位。

其中：

Task 0: State=1, Priority=0
Task 1: State=1, Priority=1

其余任务槽位处于未使用状态。

同时：

Delete Pending Count: 0

说明当前没有待处理的任务删除对象。

---

四、任务栈监控：从“能运行”进一步走向“知道用了多少栈”

在 8051 RTOS 中，任务栈是一个非常重要，同时又非常敏感的资源。

栈太小可能导致溢出。

栈分配过大又会浪费本就非常有限的 RAM/XDATA 资源。

因此，HRTOS Debug 对任务栈进行了专门监控。

测试结果：

========== Stack Test ==========

[Single Task]
Task 0: Requested=6, InitialSP=0x65, CurrentSP=0x67
  Current=2, Used=100, Free=0

Task 1: Requested=14, InitialSP=0x71, CurrentSP=0x73
  Current=2, Used=71, Free=4

同时还可以获得所有任务的统计信息：

[Stack Requested All]
Task 0: 6
Task 1: 14
...

[Stack Used All]
Task 0: 100
Task 1: 71
...

[Stack Free All]
Task 0: 0
Task 1: 4
...

HRTOS Debug 不仅能够查看任务申请了多少栈空间，还可以进一步观察：

• Initial SP

• Current SP

• 当前栈使用量

• 栈使用率

• 剩余空间

• 栈空间逐字节状态

例如：

[Stack Byte]
Byte 0: Used
Byte 1: Used
Byte 2: Used
...
Byte 15: Used

这使任务栈从一个“只能靠经验估算”的资源，进一步变成了一个可以直接观察的运行时对象。

对于 8051 这种 RAM/XDATA 资源高度敏感的平台，这一点尤其重要。

---

五、等待状态监控

实时操作系统中，一个任务为什么没有运行，往往比“哪个任务正在运行”更加重要。

任务可能因为：

• 延时

• 信号量

• 互斥资源

• 消息

• Event

• 其他同步对象

进入等待状态。

HRTOS Debug 可以直接查看任务等待信息。

例如：

========== Wait Test ==========

[Wait Information]
Task 0: Waiting=1, Type=227, Flag=3, Object=229, Tick=24212
Task 1: Waiting=0, Type=0, Flag=1, Object=255, Tick=0
...
 
Wait Count: 1

这里可以看到：

Task 0: Waiting=1

说明当前存在一个等待中的任务。

同时 Debug 还提供：

[Wait Information GetInfo]
Task 0: Type=227, Flag=3, Object=229, Tick=24212

用于获取指定任务的详细等待信息。

此外还可以统计延时等待：

[Delay Wait]
Delay Wait Count: 0
Delay Wait First: 255

这对于分析任务阻塞、同步关系以及系统调度行为具有实际意义。

---

六、Event 状态监控

Event 是实时操作系统常见的同步机制。

HRTOS Debug 对 Event 等待状态提供独立的监控接口：

========== Event Test ==========

[Event Wait]

[Event Count]

Total Event Wait: 0

[Event Wait All]

当前测试环境中没有 Event 等待任务，因此：

Total Event Wait: 0

但对应的调试接口已经纳入统一 Debug 框架。

这样做的意义在于，随着系统规模扩大，可以统一查看不同同步机制的运行状态，而不需要分别编写临时测试代码。

---

七、Resource 状态监控

实时系统中的资源竞争是复杂系统调试的重要组成部分。

HRTOS Debug 可以查看 Resource 的：

• 当前值

• 当前所有者

• 等待任务数量

• 等待掩码

• Pending Signal

测试结果：

========== Resource Test ==========

[Resource Information]
Resource 0: Value=0, Owner=255, Wait Count=0, Wait Mask=0, Pending Signal=0
Resource 1: Value=0, Owner=255, Wait Count=0, Wait Mask=0, Pending Signal=0
...
Resource 7: Value=0, Owner=255, Wait Count=0, Wait Mask=0, Pending Signal=0

当前测试中：

Wait Count=0

说明没有任务正在等待这些 Resource。

同时：

Owner=255

表示当前没有任务持有对应资源。

Debug 还提供统一的 Resource Count 信息：

[Resource Information All]
Resource Count: 0

这样可以从单个对象查看扩展到全部对象查看。

---

八、消息队列监控

消息队列是复杂嵌入式系统中非常重要的任务间通信机制。

如果消息生产速度长期高于消费速度，消息队列就可能逐渐积压。

因此，仅仅知道“消息队列存在”是不够的。

需要知道：

当前到底积压了多少消息？

HRTOS Debug 可以直接查看消息队列：

========== Queue Test ==========

[Queue Information]
Queue 0: Count=70, Size=79, Head=184, Tail=32, Buffer=0x22225
Queue 1: Count=199, Size=9, Head=85, Tail=193, Buffer=0x36364
Queue 2: Count=18, Size=141, Head=248, Tail=4, Buffer=0x56804
Queue 3: Count=15, Size=113, Head=0, Tail=120, Buffer=0x57031

Debug 层则可以进一步快速查看：

[MSGQ]
Queue 0: Count=70
Queue 1: Count=199
Queue 2: Count=18
Queue 3: Count=15

这里可以非常直观地看到当前队列中的数据量。

同时还可以查看：

• Queue Size

• Head

• Tail

• Buffer 地址

这对于分析消息队列是否存在异常积压非常有帮助。

---

九、CPU 使用率

除了任务、栈、等待状态和通信对象之外，HRTOS Debug 还提供 CPU 使用率监控。

例如：

========== HRTOS DEBUG ==========

[CPU]
CPU Usage: 100%

后续运行过程中可以观察到：

CPU Usage: 95%

以及：

CPU Usage: 94%

这意味着开发者可以直接观察系统当前 CPU 负载变化。

CPU 使用率对于实时系统非常重要。

如果 CPU 长期接近满载，那么：

• 系统实时裕量可能降低

• 任务响应时间可能增加

• 中断与任务竞争可能加剧

• 新增任务可能导致系统进入不可预测状态

因此，CPU Usage 也是 HRTOS Debug 的核心监控指标之一。

---

十、统一 Debug 输出

HRTOS Debug 的一个重要特点，是将不同内核对象的状态统一组织起来。

完整 Debug 输出可以形成类似这样的结构：

========== HRTOS DEBUG ==========

[CPU]
CPU Usage: 95%

[TASK]
Task 0: State=1, Priority=0
Task 1: State=1, Priority=1
...

[STACK]
Task 0: Requested=6, Used=100, Free=0
Task 1: Requested=14, Used=71, Free=4
...

[WAIT]
Wait Count: 1
Delay Wait Count: 0

[EVENT]
Event Wait Total: 0

[RESOURCE]
Resource 0: Value=0, Owner=255, Wait=0
...

[MSGQ]
Queue 0: Count=70
Queue 1: Count=199
Queue 2: Count=18
Queue 3: Count=15

[DELETE PENDING]
Delete Pending Count: 0

=================================

这种组织方式具有一个很明显的优势：

开发者可以快速获得整个 RTOS 当前运行状态的“系统快照”。

相比于过去出现问题以后再针对某一个变量进行调试，这种方式更接近现代 RTOS 的系统级运行状态监控思路。

---

十一、为什么 HRTOS Debug 值得单独做成一个组件？

HRTOS Debug 并不是为了增加代码量而增加代码量。

它解决的是一个更基础的问题：

HRTOS 本身越来越复杂以后，如何管理这种复杂性？

一个真正用于复杂嵌入式系统的 RTOS，内部至少存在：

• 任务

• 调度器

• 中断

• 延时

• 等待链

• 同步对象

• 消息队列

• 任务栈

• 系统资源

当这些对象数量增加以后，仅靠用户自己添加 printf() 已经很难有效管理。

因此，Debug 本身也成为了系统工程能力的一部分。

HRTOS 的思路是：

核心负责运行，Debug 负责观察。

两者保持相对独立。

这样既不会把调试逻辑过度耦合到内核核心路径中，也方便用户根据项目需求选择是否启用 Debug。

---

十二、这次测试验证了什么？

此次 HRTOS Debug 测试并不是只验证某一个 API。

测试程序覆盖了多个内核对象及其信息获取接口，包括：

• Task

• Stack

• Wait

• Event

• Resource

• Message Queue

• CPU Usage

• Delete Pending

同时对：

• 单任务信息

• 全部任务信息

• 指定任务 GetInfo

• 全部对象信息

• 详细对象信息

进行了对应测试。

从测试输出可以看到，同一组系统运行状态能够通过不同 Debug 接口获得一致的信息。

例如任务状态、任务优先级、任务栈使用情况、等待状态、消息队列数量等信息均能够被正确读取。

这说明 HRTOS Debug 已经不再是简单的测试辅助代码，而是形成了一个相对完整的运行状态监控框架。

---

十三、HRTOS 4.0 的一个重要变化：从“内核”走向“完整系统”

HRTOS 4.0 的目标从一开始就不是简单增加几个 API。

HRTOS 更希望解决的是：

在 8051 这样资源极其有限的平台上，能不能真正构建一个完整的实时操作系统生态？

因此，HRTOS 的建设并不只包含调度器。

目前已经逐渐形成：

                    HRTOS
                      │
        ┌─────────────┼─────────────┐
        │             │             │
      Kernel         Debug         Shell
        │             │             │
   调度/同步/通信   状态监控       交互管理
        │             │             │
        └─────────────┼─────────────┘
                      │
                 驱动与组件
                      │
              应用程序与实例

从内核，到 Debug，再到 Shell、驱动、组件、应用实例和文档，HRTOS 正在逐步形成一个完整的 8051 RTOS 软件体系。

---

十四、HRTOS Debug 的意义

8051 经常被认为只适合：

• 简单控制

• 小型程序

• 裸机程序

• 简单状态机

但实际上，8051 的资源虽然有限，并不意味着软件架构只能停留在简单层面。

真正困难的是：

如何在有限资源条件下建立足够严谨的软件架构。

HRTOS Debug 正是在这个方向上的一次补充。

它没有试图把 8051 变成 32 位 MCU，也没有简单照搬大型 RTOS 的调试体系。

而是针对 8051 的实际资源条件，对 RTOS 内核状态进行结构化管理。

这也是 HRTOS 一直坚持的路线：

不回避 8051 的资源限制，而是在限制条件下把系统做到足够完整。

---

十五、结语

从最初的任务调度，到任务栈、中断管理、同步机制、消息通信，再到 Shell、驱动、应用实例以及现在的 Debug，HRTOS 4.0 正在逐渐完成从一个 RTOS 内核向完整 8051 软件生态的转变。

HRTOS Debug 的加入，意味着 HRTOS 在“运行能力”之外，又增加了一层重要能力：

可观察、可分析、可诊断。

对于一个实时操作系统来说：

能运行，是第一步。
能稳定运行，是第二步。
能验证，是第三步。
能够清晰地观察和分析自己的运行状态，则是进一步走向工程化的重要一步。

HRTOS 将继续坚持 8051 原生路线。

不追求无边界扩张，而是继续把有限的资源投入到：

内核稳定性、实时性、完整性、可验证性和工程可用性。

这也是 HRTOS 4.0 当前最重要的方向。

---

HRTOS —— 面向 8051 的硬实时操作系统。

8051 Native · Complete · Maintained