# Linux+Preempt-RT vs AMP (Linux+RTOS) — 实时系统方案对比

> 目标平台：RK3568（4×Cortex-A55 + 1×Cortex-M0）
> 应用场景：电力二次保护设备 CAN 通讯

---

## 一、两种方案一句话概括

| 方案 | 核心思路 |
|------|------|
| **Linux + Preempt-RT** | 给 Linux 内核打实时补丁，让原本"不可抢占"的内核路径变得可抢占，把最坏延迟从 200μs+ 压到 20μs 以内。所有代码（协议栈、业务逻辑、驱动）都在同一个 Linux 里跑。 |
| **AMP (Linux + RTOS)** | 硬件分家：1~3 个 A55 核跑 Linux 做复杂业务（网络、文件系统、协议栈上层），另外的核（A55 或 M0）跑 RT-Thread/Baremetal 做硬实时任务（CAN 收发、保护逻辑、ADC 采集）。中间靠共享内存 + 中断（rpmsg）通信。 |

---

## 二、实时性能对比

### 2.1 中断响应延迟

这是最核心的指标——从 CAN 控制器收到一帧到 CPU 开始处理的时间：

| 指标 | Linux+RT | AMP (RT-Thread 裸核) |
|------|:---:|:---:|
| **典型中断延迟** | 5~15 μs | < 1 μs |
| **最坏中断延迟** | 15~30 μs | < 3 μs |
| **延迟抖动 (jitter)** | ±10 μs | ±1 μs |
| **确定性** | 概率性（99.9% 在预算内） | 确定性（100% 在预算内） |

> 来源：创龙文档，RT 内核 cyclictest 测试 max < 20μs；裸核无操作系统调度开销，中断延迟仅取决于 CPU 频率和中断控制器。

### 2.2 你的 CAN 场景对号入座

| 场景 | 延迟要求 | Linux+RT 够不够 | AMP 必要性 |
|------|:---:|:---:|:---:|
| CAN 帧收发（标准 1Mbps） | < 100μs | ✅ 轻松满足 | 不必要 |
| CAN FD 高速收发（5Mbps） | < 50μs | ✅ 基本满足 | 有富余 |
| 保护动作出口（从判断到出口继电器） | < 1ms | ✅ 满足 | 不必要 |
| 多通道同步 ADC + CAN 突发 | < 10μs jitter | ⚠️ 临界 | **AMP 更安全** |
| 微秒级 SOE 打时戳 | < 5μs jitter | ❌ 不够 | **必须 AMP** |
| 100μs 周期实时控制（如 SVG/APF） | < 50μs jitter | ❌ 不够 | **必须 AMP** |

---

## 三、功能效果对比

### 3.1 Linux+Preempt-RT

```
┌──────────────────────────────────────────────┐
│  单块 Linux 内核 (PREEMPT_RT)                 │
│                                              │
│  ┌──────────┐ ┌───────────┐ ┌─────────────┐ │
│  │ CAN协议栈 │ │ 保护逻辑   │ │ 文件系统/NET │ │
│  │ SCHED_FIFO│ │ SCHED_FIFO │ │ 普通线程    │ │
│  │ prio=80   │ │ prio=70    │ │             │ │
│  └──────────┘ └───────────┘ └─────────────┘ │
│  ┌──────────────────────────────────────────┐│
│  │      全部共享同一个内核、同一套驱动        ││
│  └──────────────────────────────────────────┘│
└──────────────────────────────────────────────┘

优点：
  ✅ 所有代码一个工程，开发/调试/GDB 全统一
  ✅ SocketCAN 接口直接用，驱动现成
  ✅ POSIX 线程、文件系统、网络全有
  ✅ 丢帧、超时等异常处理逻辑好写

缺点：
  ✗ 最坏延迟 20μs（够99%场景，但不是"硬实时"）
  ✗ 内核态某些路径仍不可抢占（如某些 spinlock 临界区）
  ✗ 系统负载高时抖动会增大
```

### 3.2 AMP (Linux + RT-Thread)

```
┌──────────────────┐  rpmsg(共享内存+中断)  ┌──────────────────┐
│  Core0: Linux    │ ◄══════════════════►  │  Core2: RT-Thread │
│  (CA55)          │                       │  (CA55, 裸核)     │
│                  │                       │                   │
│  • CAN 协议栈上层 │ ←── CAN 帧、控制命令  │  • CAN FD 直接收发 │
│  • 定值管理       │                       │  • SOE 打时戳      │
│  • 录波文件存储   │ ──── 录波数据 ──────► │  • 保护逻辑判断    │
│  • MQTT 上送     │                       │  • GPIO 出口继电器 │
│  • GUI/调试      │                       │  • 100μs 周期控制  │
│                  │                       │                   │
│  应用层, 复杂业务  │                       │  实时层, 确定性任务 │
└──────────────────┘                       └──────────────────┘

优点：
  ✅ 真正的硬实时（裸核中断延迟 < 1μs）
  ✅ 实时任务不受 Linux 调度器影响
  ✅ 实时核崩溃不影响 Linux 核（故障隔离）
  ✅ Linux 核可以做复杂的事（录波分析、文件压缩、网络通讯）

缺点：
  ✗ 两套代码、两个编译链、两种调试方式
  ✗ rpmsg 通信有开销（~10-50μs 的单次传输延迟）
  ✗ 核间通信协议需自己设计（Linux侧和RT-Thread侧的数据结构要对齐）
  ✗ 没有 SocketCAN 这样的现成接口，裸核 CAN 驱动需要自己写/移植
```

---

## 四、开发难度对比

### 4.1 技能要求

| 技能点 | Linux+RT | AMP |
|--------|:---:|:---:|
| Linux 应用编程 (POSIX, SocketCAN) | ✅ 需要 | ✅ 需要 |
| Linux 内核/驱动 | 基本了解即可 | 不需要（Linux 侧） |
| RTOS 编程 (RT-Thread) | 不需要 | **必须掌握** |
| 裸核编程 (中断、寄存器、Linker Script) | 不需要 | **必须掌握** |
| 交叉编译链 | 1 套 (aarch64-linux-gnu-) | **2 套** (Linux + bare-metal) |
| JTAG 调试 | 不需要 | **需要**（调试裸核） |
| 共享内存/核间通信协议设计 | 不需要 | **需要** |
| ARM 架构知识（Cache、MMU、内存屏障） | 基本了解即可 | **需要深入理解** |

### 4.2 开发工作量估算

假设最终目标都是实现一个完整的 CAN 协议栈（含定时发送、突发上送、遥控、定值、文件传输）：

| 阶段 | Linux+RT | AMP |
|------|:---:|:---:|
| 环境搭建 | 1 天 (换 RT 内核镜像即可) | 1~2 周 (AMP SDK 环境、双编译链、JTAG) |
| CAN 驱动 | 0 天 (SocketCAN 现成) | 1~2 周 (移植/写裸核 CAN 驱动) |
| 协议栈开发 | 2~4 周 (POSIX C，GDB 调试) | 4~8 周 (双端开发 + rpmsg 协议) |
| 实时优化 | 1 周 (SCHED_FIFO + 绑核 + 锁内存) | 1~2 周 (裸核本来就有确定性) |
| 调试/稳定性 | 1 周 (GDB/valgrind/perf 工具链成熟) | 2~4 周 (核间问题难复现、难定位) |
| **总计** | **约 5~8 周** | **约 9~18 周** |

### 4.3 调试难度

```
Linux+RT:
  GDB → 打断点 → 看变量 → 搞定
  所有线程在一个进程空间，crash 日志清晰

AMP:
  Linux 核: GDB 可调
  裸核: JTAG (硬件调试器) + printf 通过串口
  跨核问题: 裸核死掉，Linux 侧完全不知道发生了什么
           只能靠看共享内存 dump + 猜
```

---

## 五、针对你的场景的建议

### 首先确认：你需要的"实时"到底是哪个级别？

> 对照 [docs/05-实时性与系统优化.md](docs/05-实时性与系统优化.md) 第 7-17 行的需求表：

| 你的需求场景 | 实时级别 | 推荐方案 |
|------|:---:|------|
| CAN 帧收发（1Mbps, 最大 8 字节） | 软实时 | **Linux+RT** ✅ |
| CAN FD 收发（5Mbps, 64 字节） | 软实时 | **Linux+RT** ✅ |
| 遥控选择-返校-执行（ms 级） | 软实时 | **Linux+RT** ✅ |
| 定时遥测上送（100ms~1s） | 非实时 | **Linux+RT** ✅ |
| 保护动作出口（从采样到跳闸 < 30ms） | 硬实时 | **Linux+RT** ⚠️ 基本够 |
| 微秒级 SOE 打时戳 | 硬实时 | **AMP** ✅ |
| 100μs 周期快速控制环 | 硬实时 | **AMP** ✅ |

### 结论：分阶段路线

```
阶段 1 (当前): Linux+RT — 跑通 CAN 协议栈
  ├── 标准 Linux 内核上把协议栈功能全部开发完
  ├── 用 SocketCAN 收发，GDB 调试
  ├── 功能稳定后 → 切 RT 内核
  ├── 加 SCHED_FIFO + 绑核 + mlockall
  └── cyclictest 验证 → 基本满足 90% 的电力保护需求

阶段 2 (未来，如果有需要): AMP 硬实时
  前提条件:
  ├── 业务确实需要 <5μs 确定性（如 SOE 打时戳、100μs 控制环）
  ├── 准备好了 JTAG 调试器
  ├── 团队有人熟悉 RT-Thread 或裸核编程
  └── 架构拆分: Linux 做协议栈 + 界面，裸核做收发 + 保护逻辑
```

### 为什么不一开始就上 AMP？

1. **创龙的文档也这么建议的**（[docs/05](docs/05-实时性与系统优化.md) 第 147-157 行）——先跑通功能，再优化
2. **AMP 最大的坑不是写代码，是调试**——两个核的状态不同步，出了 bug 很难定位
3. 电力保护设备里，**绝大多数通讯场景不到 1ms 级别**——CAN 帧 1Mbps 下一帧才 ~100μs，RT 内核的 20μs 中断延迟完全够
4. 你当前的 CAN 协议栈设计（遥控超时 30 秒、遥测周期 500ms）也是 ms~s 级别，不是 μs 级别

---

## 六、补充：还有一个中间方案 — Linux + M0 协处理

RK3568 内部有一颗 **Cortex-M0**（不是 A55），可以跑极简裸核代码：

```
A55 (Linux+RT):      M0 核:
  CAN 协议栈  ←── mailbox/IPCC ──→  CAN FD 收发
  保护逻辑                           GPIO 快速出口
  文件系统                           SOE 打时戳
```

- M0 频率低（~200MHz），但中断响应极快
- Rockchip AMP SDK 主要就是面向 M0 核的
- 不需要占用 A55 核，Linux 侧 4 核全保留
- 适合把"极少量的硬实时逻辑"剥离出去

这个方案比 AMP(A55+RT-Thread) 更轻量，但需要评估 M0 算力是否够你的保护逻辑。