HRTOS 4.0 正式支持中断嵌套：高优先级中断可打断低优先级中断，也可打断内核运行

在前面的开发过程中，HRTOS 4.0 已经完成了大量内核功能开发和稳定性测试。

近期，HRTOS 4.0 又完成了一项比较重要的内核能力：

支持中断嵌套。

这意味着，在 HRTOS 4.0 中，一个正在执行的低优先级中断，可以被更高优先级的中断抢占。

更进一步：

正在执行内核代码时，也可以被高优先级中断打断。

这使 HRTOS 4.0 的中断处理机制进一步向真正的实时操作系统能力靠近。

一、什么是中断嵌套？

在最简单的中断处理方式中，当 CPU 进入一个中断服务程序之后，通常会暂时禁止其他中断。

例如：

主程序
│
├── 中断A发生
│
▼
中断A
│
│ 处理中……
│
▼
返回主程序

这种方式比较简单，但是存在一个问题：

如果中断 A 正在执行，而此时又来了一个更加紧急的中断 B，那么 B 只能等待 A 执行完成。

对于实时系统来说，这意味着高优先级事件可能产生额外的响应延迟。

中断嵌套则不同。

当低优先级中断正在执行时，如果更高优先级中断到来，就可以立即抢占当前中断。

例如：

主程序
│
├── 中断A
│ │
│ ├── 中断B
│ │ │
│ │ └── 返回中断A
│ │
│ └── 中断A继续执行
│
└── 返回主程序

这里的关键就是：

中断 B 不需要等待中断 A 完全执行结束。

二、HRTOS 4.0 的中断嵌套

HRTOS 4.0 在内核层面对中断进行了进一步的优先级划分。

目前系统的优先级体系中，中断处于较高的优先级层级。

简单来看，可以理解为：

普通任务
↓
高优先级任务
↓
中断
↓
嵌套中断

也就是说，当系统正在执行普通任务时，中断可以抢占任务。

而当系统已经进入一个中断处理过程之后，更高优先级的中断还可以继续抢占当前中断。

这就是中断嵌套。

三、真正重要的一点：中断可以打断内核

这也是 HRTOS 4.0 这次中断机制比较重要的一个地方。

很多时候，我们容易理解成：

中断可以打断任务。

但实际上，一个实时操作系统运行过程中，并不只是任务代码。

CPU 还会执行大量内核代码，例如：

• 任务调度
• 任务切换
• 延时处理
• 任务管理
• 临界区相关处理
• 内核状态维护

如果高优先级中断只能在任务运行期间响应，而内核运行期间不能响应，那么系统的实时性仍然会受到影响。

HRTOS 4.0 的设计目标则是：

在满足中断安全要求的情况下，让高优先级中断能够抢占正在运行的内核代码。

也就是说：

任务
│
▼
进入内核
│
│
├──────── 高优先级中断
│ │
│ ▼
│ 中断处理
│ │
│ ▼
│ 返回原执行现场
│
▼
继续执行内核

CPU 并不需要等整个内核操作完成之后才响应高优先级中断。

这对于实时系统尤其重要。

四、为什么“中断打断内核”比较难？

因为这并不是简单地把中断打开就结束了。

真正困难的地方在于：

如何保证被打断的内核现场能够正确恢复。

假设 CPU 正在执行内核代码：

内核代码
↓
保存/修改寄存器
↓
处理中
↓
高优先级中断发生
↓
进入中断

此时 CPU 中存在大量当前执行上下文。

如果没有正确保存，那么中断返回之后，原来的内核代码就可能无法继续正常执行。

因此，中断嵌套实际上涉及一个非常核心的问题：

上下文保护与恢复。

五、HRTOS 4.0 对上下文进行保护

当高优先级中断抢占当前执行环境时，需要保证被抢占现场能够完整恢复。

可以简单理解成：

当前执行现场
│
▼
保存上下文
│
▼
执行高优先级中断
│
▼
恢复上下文
│
▼
继续执行原来的代码

这样，无论被打断的是：

普通任务

还是：

低优先级中断

甚至：

内核代码

只要满足系统规定的嵌套条件，都可以在中断结束之后恢复原来的执行流程。

这也是中断嵌套能够正常工作的基础。

六、为什么需要中断优先级？

如果所有中断都可以无限制地互相打断，那么系统最终可能陷入一个非常复杂的状态。

例如：

中断A
└─ 中断B
└─ 中断C
└─ 中断D
└─ 中断E

嵌套层级不断增加，会带来：

• 上下文保存开销增加
• RAM 使用量增加
• 栈空间压力增加
• 中断响应关系复杂
• 调试难度增加

因此，嵌套并不是越深越好。

对于 HRTOS 4.0 来说，中断嵌套采用的是有限层级设计。

目前系统设计支持有限的嵌套层级，而不是无限递归式嵌套。

这样可以在：

实时性、资源占用和系统复杂度

之间取得平衡。

七、HRTOS 4.0 的中断优先级设计

HRTOS 4.0 当前的优先级体系可以概括为：

这里的设计思路非常明确：

任务是系统的基本执行单元，而中断拥有更高的实时响应优先级。

当高优先级中断发生时，可以抢占普通任务。

当系统已经处于中断处理状态时，如果符合更高优先级的嵌套条件，还可以进一步进入嵌套中断。

八、一次中断嵌套的完整过程

假设系统当前正在执行任务：

任务A

此时发生中断：

任务A
↓
中断1

CPU 保存任务执行现场，然后进入中断 1。

如果此时又发生更高优先级的中断：

任务A
↓
中断1
↓
中断2

那么中断 2 可以抢占中断 1。

中断 2 执行完成后：

中断2
↓
恢复中断1现场
↓
继续执行中断1

中断 1 完成之后：

中断1
↓
恢复任务A现场
↓
继续执行任务A

整个过程形成了完整的执行现场嵌套。

九、甚至可以在内核执行过程中发生中断

HRTOS 4.0 更进一步考虑了这种情况：

任务A
↓
进入内核
↓
执行内核代码
↓
高优先级中断发生
↓
进入中断
↓
中断处理完成
↓
恢复内核现场
↓
继续执行内核
↓
返回任务A

这里有一个非常关键的区别：

中断发生的时候，CPU 并不是一定处于用户任务代码中。

它可能正在：

执行 HRTOS 内核本身。

因此，内核代码本身也必须能够承受中断抢占。

这也是我在 HRTOS 4.0 中重点验证的一部分。

十、开发过程中也遇到过实际问题

中断嵌套并不是一次实现就能够直接稳定运行。

在实际测试过程中，我也遇到过一些比较典型的问题。

其中一个问题就是：

不同层级的中断处理过程中，对数据的访问必须严格区分。

特别是在嵌套中断环境下，如果多个执行层级错误地使用同一份数据，就可能产生非常隐蔽的问题。

例如：

普通中断
↓
访问数据A

嵌套中断
↓
再次修改数据A

如果没有正确处理，就可能导致数据被覆盖，最终出现看起来与中断本身无关的异常。

这类问题在普通中断测试中可能很难暴露，但在中断嵌套环境下会非常明显。

因此，中断嵌套不仅仅是“让一个中断能够进入另一个中断”。

真正重要的是：

建立完整、可靠的多层执行上下文。

十一、有限嵌套比无限嵌套更加实际

HRTOS 4.0 并没有追求无限制的中断嵌套。

对于 8051 这样的资源受限 MCU 来说，这是没有必要的。

有限层级的设计更加适合实际应用。

它可以避免因为无限嵌套导致：

栈空间不断增长
↓
RAM资源消耗增加
↓
系统稳定性下降

同时也让开发者能够明确知道系统最多存在多少层中断执行现场。

对于嵌入式实时系统来说：

可控，往往比理论上的无限能力更加重要。

十二、为什么 HRTOS 4.0 需要这个能力？

HRTOS 的核心价值之一，就是实时响应。

在实际嵌入式系统中，经常会出现这样的需求：

例如：

普通任务
负责显示、通信、数据处理

↓

普通中断
负责外部事件

↓

高优先级中断
负责更加紧急的实时事件

如果高优先级事件必须等待当前任务甚至当前中断执行完成，那么系统的响应时间就会增加。

而通过中断嵌套，可以让更加紧急的事件获得更高的响应优先级。

因此：

中断嵌套并不是为了增加一个“看起来很高级”的功能，而是为了提高实时系统处理紧急事件的能力。

十三、从普通 RTOS 到更加完整的实时内核

HRTOS 4.0 目前的内核设计已经逐渐形成了比较完整的执行优先级体系：

普通任务
↓
高优先级任务
↓
中断
↓
嵌套中断

不同执行环境拥有不同的实时优先级。

这使整个系统能够根据事件紧急程度，对 CPU 执行权进行更加精细的管理。

对于资源非常有限的 8051 MCU 来说，这种能力尤其具有意义。

十四、HRTOS 4.0 的一次重要升级

如果说前面的开发重点主要集中在：

任务调度、任务管理以及内核稳定性

那么中断嵌套则进一步扩展了 HRTOS 的实时处理能力。

目前 HRTOS 4.0 已经完成：

• 任务调度
• 优先级抢占
• 时间片
• 任务创建与删除
• 多任务运行
• 中断处理
• 中断嵌套
• 有限层级的中断抢占
• 高优先级中断抢占内核执行

等核心能力的开发和验证。

这意味着 HRTOS 4.0 的内核已经不仅仅是一个简单的“任务调度器”。

而是在逐步形成一个更加完整的实时操作系统内核。

十五、后续工作

目前 HRTOS 4.0 的内核已经进入相对稳定的阶段。

接下来工作的重点会逐渐转向：

示例程序、驱动、文档以及实际应用。

目前示例程序已经完成了基础功能和显示类功能，包括：

• 数码管
• LCD1602
• OLED

传感器部分也正在继续推进。

后续还会逐步完善：

• 传感器例程
• 通信例程
• 控制类例程
• 综合项目
• API 文档
• 开发教程

让 HRTOS 不仅能够运行，而且能够真正用于实际项目开发。

十六、结语

从最开始设计 HRTOS，到现在 HRTOS 4.0 已经经历了很多次迭代。

这一次中断嵌套功能的完成，对我来说也是 HRTOS 4.0 一个比较重要的节点。

因为它解决的不只是：

“中断能不能运行？”

而是进一步解决：

“更高优先级的中断能不能及时抢占当前执行环境？”

以及：

“当 CPU 正在执行内核代码时，高优先级事件能不能及时得到响应？”

HRTOS 4.0 当前已经完成了一周连续压力测试，累计完成 8842轮连续压力测试。

在此基础上，中断嵌套能力也已经完成开发和实际验证。

对于一个运行在 8051 MCU 上的实时操作系统来说，这又是向完整实时内核迈进的一步。

HRTOS 4.0，还在继续完善。