第二章：实时系统基础
各位同学，今天我们来聊聊实时系统。说实话，很多做嵌入式开发的朋友，对“实时”这两个字有误解。有人觉得跑个Linux就是实时，有人觉得用个RTOS就是实时。嗯，这里我得先泼盆冷水——实时不等于快，而是可预测。
我在项目中遇到过不少次，明明CPU占用率才30%，但系统就是会偶尔卡顿一下。为什么？因为任务调度出了问题。好，我们一步步来看。
2.1 实时操作系统概念
实时操作系统，英文叫RTOS。它和我们平时用的Windows、Linux最大的区别是什么？
我个人的理解是：RTOS能保证在确定的时间内完成任务。你想想看，一个汽车安全气囊，必须在碰撞后10毫秒内弹出。如果系统说“我尽量，但有时候可能会慢一点”——那后果不堪设想。
实时系统分两种：
- 硬实时：错过截止时间 = 系统崩溃。比如飞行控制、医疗设备。
- 软实时：偶尔超时还能接受，但会影响体验。比如视频播放、音频处理。
核心要点：RTOS不是让系统跑得更快，而是让系统的行为变得可预测、可量化。
我记得刚入行时，有个老工程师跟我说：“小伙子，别老盯着CPU主频看。你得看最坏情况下的响应时间。”这句话我到现在都记得。
2.2 任务调度
任务调度，说白了就是“谁先干活，谁后干活”。RTOS里最常用的调度策略有两种。
2.2.1 优先级抢占式调度
每个任务都有一个优先级。高优先级的任务可以打断低优先级的任务。听起来很简单对吧？但坑就在这里。
我曾经踩过一个坑：三个任务A、B、C，优先级依次降低。A和B都等着一个共享资源，C在占用这个资源。结果A一直抢不到，系统就卡死了。这就是经典的优先级反转问题。
避坑指南：我曾经在项目中遇到优先级反转导致电机失控。后来用了优先级继承协议才解决。记住：高优先级任务等低优先级任务释放资源，这是大忌。
2.2.2 时间片轮转调度
同优先级的任务，大家轮流干活。每个任务分到一个时间片，用完就换下一个。这种方式适合对实时性要求不那么苛刻的场景。
我个人习惯：关键任务用优先级调度，非关键任务用时间片轮转。这样既保证了实时性，又不会让CPU闲着。
2.2.3 调度策略对比
| 调度策略 | 特点 | 适用场景 | 潜在问题 |
|---|---|---|---|
| 优先级抢占 | 高优先级任务立即执行 | 硬实时系统 | 优先级反转、死锁 |
| 时间片轮转 | 公平分配CPU时间 | 软实时系统 | 实时性无法保证 |
| 混合调度 | 结合两者优点 | 复杂系统 | 实现复杂度高 |
2.3 中断管理
中断，是实时系统的灵魂。没有中断，CPU就得一直轮询，效率低得吓人。
中断处理分两部分：
- 中断服务程序（ISR）：响应硬件事件，要短小精悍
- 中断下半部（Bottom Half）：处理复杂逻辑，可以慢慢来
我建议：ISR里只做最必要的事。比如收到一个数据包，ISR里就把它放到缓冲区，然后唤醒一个任务去处理。千万别在ISR里做复杂的计算或打印日志。
小技巧：我习惯在ISR里用信号量通知任务。这样既快又安全。记住：ISR里不能调用可能阻塞的函数，比如malloc、printf。
为什么会这样？因为中断是异步的。你正在打印日志，突然来了个中断，打印还没完，中断又来了——系统就乱了。
2.4 时间同步机制
在硬件在环仿真中，时间同步是个大问题。你想想看，仿真模型跑在PC上，真实硬件跑在测试台上，两边的时间必须对齐。
常用的时间同步机制有：
- 硬件定时器：精度高，但资源有限
- 软件定时器：灵活，但精度受任务调度影响
- 网络时间同步（如PTP）：分布式系统必备
我记得有个项目，仿真步长要求1毫秒。但PC上的Windows不是实时系统，时间片是10毫秒。怎么办？我们用了高精度事件定时器（HPET），配合实时线程，才勉强达到要求。
经验之谈：时间同步不是越快越好，而是越准越好。我曾经见过有人把定时器频率设得特别高，结果CPU全花在中断处理上了，系统反而更慢。
下面这张图，是我总结的实时系统知识体系。你可以看到，任务调度、中断管理、时间同步，这三者是相互关联的。
最后说一句：实时系统没有银弹。不同的项目，不同的硬件，不同的需求，你得自己去权衡。我见过有人为了追求极致实时性，把所有中断都关掉——结果系统直接死机。也见过有人用Linux跑硬实时任务，结果被调度器坑得欲哭无泪。
嗯，今天就到这里。记住一句话：实时系统的本质，是对时间的承诺。你承诺了1毫秒响应，那就必须做到。做不到，就别承诺。
个人建议：刚开始学RTOS的同学，别急着上复杂功能。先跑通一个任务调度，再慢慢加中断、加同步。一步一个脚印，比什么都强。
公众号:蓝海资料掘金营，微信deep3321