RTOS / REAL-TIME
T
围绕时间约束设计
将关键任务的响应行为与时间要求纳入系统设计。
- 关注关键任务的响应时间与截止时间。
- 明确调度、抢占、中断与资源竞争的行为。
- 评估关键路径的执行开销和最不利情况。
- 在目标硬件与规定条件下验证实时要求。
WHY HRTOS / 05 · SYSTEM DESIGN
RTOS vs GPOS
实时系统与通用操作系统的关键差异，不在于一个绝对追求速度、另一个完全不关心时间， 而在于系统设计如何处理时间约束、任务响应、调度干扰与最坏情况。
REAL-TIME CONSTRAINTS
SCHEDULING
DETERMINISM
DESIGN PRINCIPLES / 05
01
DESIGN OBJECTIVES
核心区别：设计目标与约束
THE FUNDAMENTAL DIFFERENCE
不只是运行得快，
更要理解时间。
RTOS（实时操作系统）强调任务响应的可预测性， 将优先级、截止时间、响应延迟和资源竞争纳入内核设计与系统分析。
GPOS（通用操作系统）通常需要兼顾吞吐量、公平性、 交互体验、兼容性与广泛的应用场景。 这些目标可能与特定实时任务的要求形成取舍，但不意味着通用系统必然无法用于实时场景。
时间约束
任务是否需要在明确的时间范围内完成，而不仅是尽快完成。
响应可预测性
调度、中断和资源竞争会如何影响关键任务的响应过程。
验证证据
在明确的硬件、配置和负载条件下，判断时间要求是否得到满足。
02
SIDE-BY-SIDE
两类系统通常关注什么？
GPOS / GENERAL-PURPOSE
G
兼顾多类系统目标
在复杂应用生态中平衡多种性能与使用需求。
- 关注整体吞吐量、交互体验与系统公平性。
- 需要兼顾大量应用、设备和运行场景。
- 可能采用复杂的调度与资源管理机制。
- 也可以通过实时调度、内核配置和系统工程满足某些实时需求。
以上是常见设计侧重点，不是对所有操作系统的绝对分类。 实时能力最终取决于具体实现、配置、硬件、负载和任务要求。
03
TIMING ANALYSIS
真正的分界：能否满足时间约束
对实时任务而言，平均执行时间很短，并不必然意味着截止时间能够得到满足。 某些低概率但高延迟的情况，也可能影响系统是否符合要求。 因此，关键不是简单比较平均速度，而是分析任务执行时间、调度等待、 中断干扰、临界区与资源阻塞，并判断它们是否处于系统允许的时间范围内。
明确任务期限
确定截止时间与可接受的响应范围。
分析执行与干扰
识别执行开销、调度等待与中断影响。
评估响应时间
结合运行条件分析关键任务的响应过程。
验证约束是否满足
使用测试与分析证据评估目标是否达成。
04
DEADLINE SEMANTICS
如何理解超时？
硬实时任务
如果截止时间是系统要求的一部分，任务错过期限就意味着该项实时要求未得到满足。 在安全关键或严格控制场景中，后果可能非常严重。
软实时任务
超时通常意味着服务质量下降，而不一定导致整个系统失效。 可以接受的延迟和超时频率，需要由具体应用需求决定。
硬实时与软实时描述的是任务的时间要求及其违约后果， 不能简单地用来断言某一类操作系统的所有任务都具有相同的实时属性。
05
8051 ARCHITECTURE
为什么 8051 需要专门考虑内核结构？
应用任务与业务逻辑
HRTOS 专用内核
调度 · 上下文 · 中断 · 资源
8051 CPU / 存储器 / 定时器
硬件约束必须进入内核设计
在 8051 这类资源受限的单片机上，实时行为与具体处理器结构紧密相关。 寄存器组、堆栈空间、内存类型、编译器调用约定和中断机制， 都会影响上下文管理与任务切换的开销。
如果中断处理、上下文保存、调度和资源管理缺少整体设计， 就很难单独评估某一个内核功能对响应时间的实际影响。
寄存器与上下文管理
有限的内部与外部 RAM
中断响应与嵌套机制
切换开销与可维护性
因此，8051 实时内核需要在功能完整性、内存占用、运行开销与可维护性之间作出明确取舍。
06
KERNEL · ENGINEERING · VALIDATION
HRTOS 的设计方向
BUILT FOR 8051
HRTOS 面向 8051 单片机，围绕任务调度、中断处理、上下文切换和资源管理构建专用内核， 并通过配套组件支持实际工程开发。
01
内核层 / Kernel
关注调度规则、中断行为、上下文管理和资源约束之间的协同， 而不是将它们视为彼此独立的功能。
02
工程层 / Engineering
通过 Shell、Modbus RTU、驱动、示例、技术文档和回归测试， 支持从内核使用到应用集成的开发过程。
03
验证层 / Validation
结合目标芯片、编译结果、运行测试与最坏情况执行时间分析， 持续提高关键行为的可观察性和可分析性。
04
长期方向 / Roadmap
在明确硬件与运行条件的基础上，持续改善关键路径的可预测性， 并以测试结果和分析证据支撑技术判断。
07
FROM CONCEPT TO MECHANISM
System View 映射
RTOS 的设计目标需要落实到具体系统机制。对于 HRTOS， 可以从以下几个方面观察时间约束如何贯穿内核。
01
执行流模型
观察关键代码路径与上下文变化。
02
调度模型
分析任务优先级、抢占规则与等待时间。
03
中断模型
理解响应入口、嵌套行为与中断屏蔽窗口。
04
时间分析
评估执行开销、干扰因素与响应时间。
这些模型用于帮助理解和分析系统，并不意味着仅凭架构描述就能证明所有执行场景均满足严格的时间上界。
KEY TAKEAWAY / 05
实时能力，最终要回到时间约束。
RTOS 与 GPOS 的区别，应从设计目标、时间约束和具体实现来理解， 而不是把两类系统简单划分为“确定”与“不确定”。
对 HRTOS 而言，重点是针对 8051 的处理器结构和资源限制， 将中断、调度、上下文管理与时间分析纳入统一的工程设计， 并通过持续验证逐步提高关键实时行为的可预测性。