第2章实时系统概念

第2章：实时系统概念

大家好，我是你们的老朋友。今天我们来聊聊实时系统的基本概念。说实话，很多工程师做了好几年嵌入式开发，对「实时」的理解还停留在「跑得快」这个层面。嗯，这其实是个误区。

我在做运动控制项目时，遇到过不少坑。比如一个伺服驱动器，CPU占用率才30%，但电机就是会偶尔抖动一下。查了三天，最后发现是任务调度出了问题。从那时起，我就特别重视实时系统的底层原理。

什么叫实时系统？说白了，就是系统必须在规定时间内完成指定任务。注意，不是「越快越好」，而是「准时完成」。

我习惯这样定义：实时系统是一个能在确定时间内对外部事件做出响应的系统。这个「确定时间」是关键。你想想看，如果电机控制指令晚到了1毫秒，可能整个机械臂就撞上了。

核心要点：实时 ≠ 快速，实时 = 可预测 + 准时

实时系统有三个基本特征：

这里有个经典问题：错过截止时间会怎样？

硬实时系统：错过截止时间 = 系统崩溃或灾难。比如安全气囊控制器，必须在碰撞后几毫秒内点火。晚1毫秒，人就没了。我在汽车电子项目中做过ABS控制器，那真是「死线」——错过就是事故。

软实时系统：错过截止时间 = 性能下降，但系统还能跑。比如视频播放器，偶尔卡顿一下，用户骂两句，但不会出人命。

避坑指南：我曾经把软实时的调度算法直接用在硬实时项目上，结果测试时发现偶尔会丢一个控制周期。嗯，那次教训让我记住了：硬实时系统必须做最坏情况分析，不能只看平均性能。

调度算法是实时系统的灵魂。我重点讲两个经典算法：RMS和EDF。

RMS是静态优先级算法。它的规则很简单：周期越短的任务，优先级越高。

为什么？你想想看，周期短的任务意味着它更频繁地需要CPU，给它高优先级，才能保证它不被饿死。

RMS有一个可调度性判定条件：

U = Σ(Ci/Ti) ≤ n(2^(1/n) - 1)

其中：
U = CPU利用率
Ci = 任务i的最坏执行时间
Ti = 任务i的周期
n = 任务数量

当n→∞时，这个上限趋近于ln2 ≈ 0.693。也就是说，用RMS调度，CPU利用率超过69.3%时，理论上就可能出现任务超时。

我的经验：实际项目中，我一般把CPU利用率控制在60%以下。为什么留余量？因为中断处理、系统开销这些都没算进去。我曾经在一个六轴机器人控制器上，RMS调度跑到了68%，结果偶尔会丢一个脉冲。降到55%后，稳如老狗。

EDF是动态优先级算法。谁离截止时间最近，谁就先跑。

EDF的优点是CPU利用率可以到100%（理论上）。但代价是：实现复杂，而且过载时系统行为不可预测——所有任务都可能一起崩。

我画了一张图，帮你理解两者的区别：

很多人把Linux这样的分时系统和实时系统搞混。我简单说说区别：

分时系统追求的是「每个人都能用上电脑」，所以它用时间片轮转，让大家轮流用CPU。实时系统追求的是「关键任务必须准时完成」，所以它用优先级，让重要任务优先跑。

记住一句话：分时系统是「尽量快」，实时系统是「必须准时」。这两个哲学完全不同。

我在移植RTOS时，经常看到有人把Linux的nice值当优先级用。嗯，那玩意儿是分时系统的概念，不是实时优先级。在实时系统里，优先级是绝对的——高优先级任务不跑完，低优先级任务就别想动。

实时系统的核心就三个词：确定性、可预测、准时。硬实时和软实时的区别在于错过截止时间的后果。RMS和EDF是两种经典调度算法，各有优劣。最后，别把分时系统和实时系统搞混了——它们的设计哲学完全不同。

下一章，我们会深入RTOS的内核结构，看看任务是怎么创建和切换的。到时候我会分享一些移植过程中的血泪史，嗯，都是干货。

公众号:蓝海资料掘金营，微信deep3321