1. 实时系统概述：硬实时与软实时区别、RTOS选型、实时性指标
大家好，我是你们这门课的主讲。咱们直接开门见山——实时系统到底是个什么东西？
很多人一听“实时”，就以为是“快”。其实不然。实时系统的核心不是快，而是确定性。说白了，就是系统必须在规定的时间内完成规定的任务。晚了一毫秒，可能整个系统就崩了。
我早年做工业机器人控制器的时候，就吃过这个亏。当时选了一个通用Linux，觉得CPU主频够高就行。结果机械臂在高速运动时，关节角度计算偶尔会延迟几个毫秒。你猜怎么着？机器人直接抖成了帕金森。从那以后，我再也不敢轻视“实时”这两个字。
1.1 硬实时 vs 软实时：差之毫厘，谬以千里
先搞清楚这两个概念。它们决定了你整个系统的设计基调。
| 特性 | 硬实时 (Hard Real-Time) | 软实时 (Soft Real-Time) |
|---|---|---|
| 截止时间后果 | 错过截止时间 = 系统失效/灾难 | 错过截止时间 = 性能下降，但系统仍可运行 |
| 典型应用 | 安全气囊、飞行控制、心脏起搏器 | 视频播放、网络电话、游戏引擎 |
| 设计哲学 | 最坏情况执行时间 (WCET) 必须保证 | 平均情况执行时间 (ACET) 可接受 |
| 抖动容忍度 | 几乎为零 | 可容忍一定范围 |
| 验证方式 | 形式化验证 + 穷举测试 | 统计概率 + 压力测试 |
核心判断标准：如果任务超时，你是“系统挂了”还是“体验变差”？前者选硬实时，后者选软实时。
举个例子。你开车时踩刹车，ABS系统必须在几毫秒内响应。晚1毫秒，车轮抱死，车就侧滑了。这是硬实时。而你用手机看视频，偶尔卡顿一下，画面延迟了50毫秒，你骂一句“破网”，但视频还在播。这是软实时。
我个人习惯把硬实时叫做“命根子系统”，软实时叫做“体验系统”。设计时，千万别把命根子当体验做，也别把体验当命根子做。否则，两边都做不好。
1.2 实时操作系统(RTOS)选型：别被花哨的PPT骗了
选RTOS，我见过太多人踩坑了。有人看社区活跃就选，有人看功能多就选。结果项目做到一半，发现调度延迟根本压不下去。
我建议你从以下四个维度去评估：
- 调度器类型：抢占式优先级调度是底线。支持时间片轮转吗？支持同优先级任务调度吗？
- 中断延迟：从硬件中断触发到ISR开始执行，这个时间必须可预测。我见过某些“轻量级”RTOS，中断关闭时间长达几十微秒，直接废了。
- 资源开销：RAM和ROM占用。对于Cortex-M0这种只有几KB RAM的芯片，FreeRTOS是首选。对于Cortex-A系列，可以考虑更复杂的方案。
- 生态与认证：如果你做医疗或航空，必须选有安全认证的RTOS（如VxWorks Cert、SafeRTOS）。别指望用开源项目去拿DO-178C认证，那是一条死路。
| RTOS | 适用场景 | 中断延迟 | 认证 | 我的评价 |
|---|---|---|---|---|
| FreeRTOS | MCU、IoT、消费电子 | 低 (~1us) | 无 | 入门首选，生态好，但别用于安全关键系统 |
| RT-Thread | 国产替代、IoT、智能家居 | 低 (~2us) | 无 | 组件丰富，文档中文友好，适合快速开发 |
| VxWorks | 航空航天、工业控制、医疗 | 极低 (~0.5us) | DO-178C, IEC 61508 | 贵，但稳定。我当年做卫星地面站就用的它 |
| Zephyr | 多架构、蓝牙、无线协议 | 低 (~1.5us) | 部分安全认证进行中 | Linux基金会项目，潜力大，但学习曲线陡 |
| μC/OS-III | 工业、汽车、教学 | 低 (~1us) | IEC 61508 (部分版本) | 经典教材级RTOS，代码质量高，但商业授权贵 |
避坑指南：我曾经在一个项目中选了某款“网红”RTOS，社区很活跃，但它的内存管理模块有隐藏bug，导致系统运行72小时后随机死机。排查了整整两周。后来换回FreeRTOS，问题消失。所以，选RTOS时，稳定性 > 功能丰富度。别追新，追稳。
1.3 实时性三大指标：延迟、抖动、吞吐量
这三个指标，是衡量实时系统性能的“三驾马车”。你优化了半天，最终都要落到这三个数字上。
1.3.1 延迟 (Latency)
延迟就是“从事件发生到系统响应”的时间。它包含两部分：中断延迟 + 任务调度延迟。
- 中断延迟：硬件中断信号到达CPU，到CPU开始执行ISR的第一条指令。这取决于CPU架构和RTOS关中断的时间。
- 任务调度延迟：ISR退出后，到高优先级任务真正获得CPU的时间。这取决于调度器算法和当前任务是否在临界区。
我习惯用逻辑分析仪抓GPIO翻转来测延迟。在ISR入口和任务入口各翻转一次，看波形间隔。这个方法土，但准。
1.3.2 抖动 (Jitter)
抖动是延迟的变化量。硬实时系统最怕的不是延迟大，而是抖动大。因为抖动意味着不确定性。
举个例子。一个任务每次执行需要100us，但有时是100us，有时是150us，有时是200us。这个波动就是抖动。对于音频播放，抖动会导致声音断续；对于电机控制，抖动会导致转速不稳。
我的经验：降低抖动最有效的方法是减少关中断的时间。把临界区拆小，把中断嵌套打开，把高优先级任务的中断响应路径优化到极致。我曾经把一个系统的抖动从50us降到了5us，就靠这一招。
1.3.3 吞吐量 (Throughput)
吞吐量是单位时间内系统处理的任务量。它和延迟、抖动是三角关系。
- 你追求低延迟，可能就要牺牲吞吐量（因为频繁切换任务）。
- 你追求高吞吐量，可能就要容忍一定的延迟和抖动（因为批量处理）。
所以，设计时一定要明确：你的系统是延迟敏感型还是吞吐量敏感型？
1.4 知识体系总览：一张图看懂本章
下面这张SVG图，把本章的核心逻辑串起来了。你可以把它当作思维导图来用。
1.5 本章小结：你该带走什么？
- 硬实时 vs 软实时：判断标准是“错过截止时间的后果”。别把命根子系统当体验做。
- RTOS选型：先看中断延迟和调度确定性，再看生态和认证。稳定性 > 功能丰富度。
- 三大指标：延迟、抖动、吞吐量。它们互相制约，设计时要有取舍。
最后一句心里话：做实时系统，本质上是在跟“不确定性”作斗争。你每关一次中断，每加一个锁，每多一层抽象，都是在往系统里注入不确定性。我的建议是——能不用锁就不用锁，能不用动态内存就不用动态内存，能不用中断嵌套就不用中断嵌套。简单，才是实时系统的最高境界。