当前位置：首页 > news >正文

从裸机到RTOS再到AMP：一个嵌入式老鸟的RK3568异构系统选型心路历程

news 2026/5/26 19:28:57

从裸机到RTOS再到AMP：一个嵌入式老鸟的RK3568异构系统选型心路历程

作为一名在嵌入式领域摸爬滚打十余年的工程师，我经历过从8位单片机到32位MCU，再到如今复杂SoC的技术变迁。每次架构升级都伴随着技术选型的阵痛，而RK3568项目的系统选型过程，堪称我职业生涯中最具挑战性的一次决策。本文将完整还原这段心路历程，希望能为面临同样困惑的同行提供参考。

1. 项目背景与技术需求

我们的项目是一个工业边缘计算网关，需要同时处理实时控制任务和复杂的数据分析功能。核心需求可以概括为以下几点：

实时性要求：部分控制回路响应时间需保证在1ms以内
计算能力：需要运行轻量级机器学习模型进行数据预处理
网络功能：支持多种工业协议转换和云端通信
开发效率：团队熟悉传统RTOS开发，但对Linux生态相对陌生

面对这些需求，我们最初考虑了三种技术路线：

方案类型	优势	劣势
裸机(HAL)	极致实时性，低延迟	开发效率低，功能扩展困难
单一RTOS	较好的实时性，已有开发经验	复杂功能实现成本高
Linux+RTOS AMP	兼顾实时与复杂功能	系统复杂度高，调试困难

2. 裸机方案的尝试与放弃

我们最初考虑采用传统的裸机开发方式，使用RK3568提供的HAL库。这种方案在资源受限的MCU项目中屡试不爽，但在RK3568这样的多核Cortex-A55平台上却遇到了意想不到的挑战。

裸机开发的主要痛点：

外设驱动开发工作量巨大
- 需要从头实现GMAC、USB3.0等复杂外设驱动
- 缺乏标准协议栈支持（如TCP/IP、USB协议栈）
多核利用率低下
- 裸机环境下难以充分发挥四核CPU优势
- 核间通信机制需要自行实现
开发工具链不完善
- 调试手段有限，缺乏成熟的性能分析工具
- 错误排查困难，系统稳定性难以保证

// 典型的裸机状态机代码示例 void main_loop() { static enum {IDLE, PROCESSING, WAITING} state = IDLE; switch(state) { case IDLE: if(data_ready()) { state = PROCESSING; } break; case PROCESSING: process_data(); state = WAITING; break; case WAITING: if(ack_received()) { state = IDLE; } break; } }

经过两周的尝试后，团队意识到裸机方案虽然能满足实时性要求，但开发效率太低，难以在项目周期内完成所有功能开发。

3. RT-Thread方案的评估

放弃裸机方案后，我们转向评估RT-Thread作为单一操作系统的可能性。RT-Thread作为国产开源RTOS，既有实时性保证，又提供了相对丰富的中间件支持。

RT-Thread的核心优势：

完善的实时性保障
- 全抢占式调度，调度时间复杂度O(1)
- 支持优先级继承协议，避免优先级反转
丰富的组件生态
- 内置文件系统、网络协议栈、GUI等中间件
- 60+官方软件包支持（MQTT、WebClient等）
熟悉的开发模式
- 类似FreeRTOS的任务编程模型
- 支持MSH命令行交互，调试方便

# RT-Thread的MSH命令行示例 msh />psr thread pri status sp stack size max used left tick error -------- --- ------- ---------- ---------- ------ ---------- --- tshell 20 running 0x00000060 0x00001000 15% 0x0000000a 000 tidle0 31 ready 0x00000054 0x00000400 45% 0x00000014 000 timer 4 suspend 0x00000074 0x00000800 08% 0x00000005 000

然而，在实际评估中我们发现，对于需要运行复杂数据分析功能的场景，RT-Thread仍存在明显局限：

内存管理不足：标准配置仅支持静态内存分配，动态内存管理效率较低
多核支持有限：虽然支持SMP，但任务调度算法针对单核优化
性能瓶颈：运行TensorFlow Lite等框架时性能不如Linux环境

4. AMP架构的最终选择

经过前两种方案的尝试，我们最终将目光投向了AMP（Asymmetric Multi-Processing）架构，即Linux与RT-Thread分别运行在不同CPU核上的异构系统方案。

4.1 AMP架构设计

RK3568的AMP实现采用了以下核心设计：

核隔离配置
- CPU0-1：运行Linux系统，处理非实时任务
- CPU2-3：运行RT-Thread，处理实时控制任务
核间通信机制
- 共享内存：用于大数据交换
- 硬件邮箱：用于小数据量实时通信
- 中断触发：用于事件通知
资源划分原则
- 外设分配：实时外设（如PWM、CAN）由RT-Thread独占
- 内存划分：通过DTS固定内存区域
- 中断管理：GIC-400中断控制器动态分配

// 设备树中的资源划分示例 reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; rtos_reserved: rtos@8000000 { reg = <0x0 0x08000000 0x0 0x01000000>; }; }; amp { compatible = "rockchip,amp"; cpu-mask = <0xC>; /* CPU2-3 */ memory-region = <&rtos_reserved>; };

4.2 开发环境搭建

AMP系统的开发环境搭建比单一系统复杂得多，主要步骤包括：

获取SDK

repo init -u ssh://git@gitlab.com/rockchip-amp/repo_manifest.git -b master repo sync

编译Linux内核

cd kernel make ARCH=arm64 rockchip_linux_defconfig make ARCH=arm64 -j8

编译RT-Thread

cd rt-thread scons --menuconfig scons -j8

生成完整固件
```
./build.sh amp
```

4.3 实际开发中的挑战与解决方案

在实际开发过程中，我们遇到了几个关键挑战：

挑战一：核间通信延迟不稳定

最初测试发现核间通信延迟在10μs到500μs之间波动，完全无法满足实时性要求。通过以下优化将延迟稳定在20μs以内：

禁用Linux核的CPU频率调节
设置RT-Thread核的CPU亲和性
使用硬件邮箱替代软件中断

挑战二：内存访问冲突

由于Linux和RT-Thread共享部分内存区域，偶尔会出现数据损坏。解决方案包括：

严格划分内存区域

关键数据结构添加缓存一致性处理

void shared_data_update(struct shared_data *data) { rt_hw_cpu_dcache_clean(data, sizeof(*data)); rt_hw_cpu_icache_invalidate(data, sizeof(*data)); }

挑战三：调试困难

AMP系统的调试比单一系统复杂得多，我们建立了以下调试体系：

Linux侧：使用ftrace和perf进行性能分析
RT-Thread侧：利用SEGGER SystemView进行实时跟踪
核间交互：自定义调试协议通过UART输出

5. 不同场景下的架构选型建议

基于我们的实践经验，针对不同场景推荐以下架构选择：

项目特征	推荐架构	理由
简单控制，资源受限	裸机/HAL	节省资源，实时性最佳
中等复杂度，需联网	单一RTOS	平衡实时性与功能丰富性，开发效率较高
复杂功能，混合关键性	Linux+RTOS AMP	兼顾非实时复杂功能与硬实时要求，充分发挥多核性能
高性能计算，弱实时	纯Linux	开发生态丰富，适合算法密集型应用