【线程】中的实时操作系统（RTOS）- 程序员专属福利送上！

摘要：实时操作系统（RTOS）因其在实时性、稳定性、可靠性以及资源效率等方面的显著优势，在军事、医疗、航天、工业和物联网（IoT）等领域扮演着至关重要的角色。然而，由于硬件平台的多样性，RTOS的开发和调试环境往往缺乏像 Visual Studio 或 Linux

“天方夜谭：把实时操作系统（RTOS）移植到一个Windows线程里面”

提出问题

实时操作系统（RTOS）因其在实时性、稳定性、可靠性以及资源效率等方面的显著优势，在军事、医疗、航天、工业和物联网（IoT）等领域扮演着至关重要的角色。然而，由于硬件平台的多样性，RTOS的开发和调试环境往往缺乏像 Visual Studio 或 Linux + GDB 这样的通用工具。这给开发者带来了不少挑战。

对于仅拥有 RTOS 源代码但缺乏实际硬件的开发者而言，学习 RTOS 通常局限于阅读代码，并在脑海中想象其运行过程。这种方式不仅缺乏直观性，也对深度理解 RTOS 的运行原理和调试其内核带来了一定障碍。

疯狂的想法

阿布在调试一款商用 RTOS 时，也遇到了类似的问题。尽管阿布拥有硬件设备，但每次修改代码后都需要经历编译、烧写二进制文件、配置专用调试设备等繁琐步骤，这种重复性的工作效率低下且令人疲惫。阿布注意到，这款 RTOS 运行在单核CPU上，且不支持内存管理单元（MMU）。这种环境与普通的单线程运行模式有很多相似之处。于是，阿布萌生了一个想法：为什么不尝试将 RTOS 移植到 Windows x86 系统上呢？

与市面上常见的“将 RTOS 任务替换为 Windows 线程”的移植方式不同，阿布发现这种方法的一个致命缺陷是，任务调度仍由 Windows 内核主导，与原生 RTOS 的运行逻辑相去甚远。这种移植方式会阉割掉很多 RTOS 的核心功能。因此，阿布选择了一种更加完整的移植方法：通过 Visual Studio 对 RTOS 进行编译，确保没有遗漏任何代码。

果然，在编译涉及任务切换的相关代码时，阿布遇到了编译器错误。正如章节“CPU眼里的上下文”所描述，任务切换需要保存和恢复大量 CPU 寄存器，这部分代码通常是高度硬件相关的，并且通常使用汇编语言编写。为了解决这一问题，阿布使用 x86 汇编语言改写了大约二十多行的相关代码，将 CPU 寄存器保存和恢复的逻辑重新实现，并通过修改 RIP 寄存器，让 CPU 能够跳转到不同的任务，并执行相应代码。最终，这种方法成功实现了 RTOS 在单个 Windows 线程中的任务切换（我们称该线程被为 RTOS 线程）。从 Windows 线程的视角来看，它只是在兢兢业业的、机械的运行一系列CPU指令，完全没有意识到 RTOS 任务切换的存在。

通过这种方式，阿布成功让 RTOS 在 Visual Studio 中运行，能够调试其每一行代码，并审查内核中每一个数据结构。深入掌控 RTOS 运行细节的体验令人激动，此刻，操作系统的复杂理论似乎都变得不再高深。

然而，此时的 RTOS 仍需要任务代码主动调用诸如 Sleep 或 Mutex 等函数，才能触发任务切换。这种情况跟“非抢占式的操作系统”非常相似。具体工作流程如图所示。

为了实现自主任务切换，阿布引入了“时钟中断”。通过 Windows 定时器机制，每隔 10 毫秒触发一次回调函数。在回调函数中，通过调用 SuspendThread 暂停 RTOS 线程，使用 GetThreadContext 获取其当前上下文，随后修改 RIP 寄存器指向 RTOS 的时钟中断处理函数。接着，将新的上下文通过 SetThreadContext 写回，最后调用 ResumeThread 恢复 RTOS 线程运行。这样，RTOS 就能够在处理时钟中断时自主进行任务切换。具体工作流程如图所示。