从裸机到RTOS再到AMP一个嵌入式老鸟的RK3568异构系统选型心路历程作为一名在嵌入式领域摸爬滚打十余年的工程师我经历过从8位单片机到32位MCU再到如今复杂SoC的技术变迁。每次架构升级都伴随着技术选型的阵痛而RK3568项目的系统选型过程堪称我职业生涯中最具挑战性的一次决策。本文将完整还原这段心路历程希望能为面临同样困惑的同行提供参考。1. 项目背景与技术需求我们的项目是一个工业边缘计算网关需要同时处理实时控制任务和复杂的数据分析功能。核心需求可以概括为以下几点实时性要求部分控制回路响应时间需保证在1ms以内计算能力需要运行轻量级机器学习模型进行数据预处理网络功能支持多种工业协议转换和云端通信开发效率团队熟悉传统RTOS开发但对Linux生态相对陌生面对这些需求我们最初考虑了三种技术路线方案类型优势劣势裸机(HAL)极致实时性低延迟开发效率低功能扩展困难单一RTOS较好的实时性已有开发经验复杂功能实现成本高LinuxRTOS 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架构的最终选择经过前两种方案的尝试我们最终将目光投向了AMPAsymmetric 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: rtos8000000 { reg 0x0 0x08000000 0x0 0x01000000; }; }; amp { compatible rockchip,amp; cpu-mask 0xC; /* CPU2-3 */ memory-region rtos_reserved; };4.2 开发环境搭建AMP系统的开发环境搭建比单一系统复杂得多主要步骤包括获取SDKrepo init -u ssh://gitgitlab.com/rockchip-amp/repo_manifest.git -b master repo sync编译Linux内核cd kernel make ARCHarm64 rockchip_linux_defconfig make ARCHarm64 -j8编译RT-Threadcd rt-thread scons --menuconfig scons -j8生成完整固件./build.sh amp4.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平衡实时性与功能丰富性开发效率较高复杂功能混合关键性LinuxRTOS AMP兼顾非实时复杂功能与硬实时要求充分发挥多核性能高性能计算弱实时纯Linux开发生态丰富适合算法密集型应用对于RK3568平台特别建议资源分配策略实时任务内存预留不少于16MB为RT-Thread保留至少两个专用CPU核性能调优重点确保RT-Thread核的隔离性禁用中断共享优化共享内存访问模式减少缓存抖动开发流程建议先独立开发验证各子系统功能再逐步集成测试核间通信最后进行整体性能优化在项目后期我们还发现了一些值得分享的实践经验电源管理Linux侧的DVFS会影响RT-Thread核的实时性建议固定频率启动顺序应先启动RT-Thread再启动Linux避免资源冲突调试接口预留专用UART给RT-Thread与Linux控制台分离
从裸机到RTOS再到AMP：一个嵌入式老鸟的RK3568异构系统选型心路历程
发布时间：2026/5/20 17:53:36
从裸机到RTOS再到AMP一个嵌入式老鸟的RK3568异构系统选型心路历程作为一名在嵌入式领域摸爬滚打十余年的工程师我经历过从8位单片机到32位MCU再到如今复杂SoC的技术变迁。每次架构升级都伴随着技术选型的阵痛而RK3568项目的系统选型过程堪称我职业生涯中最具挑战性的一次决策。本文将完整还原这段心路历程希望能为面临同样困惑的同行提供参考。1. 项目背景与技术需求我们的项目是一个工业边缘计算网关需要同时处理实时控制任务和复杂的数据分析功能。核心需求可以概括为以下几点实时性要求部分控制回路响应时间需保证在1ms以内计算能力需要运行轻量级机器学习模型进行数据预处理网络功能支持多种工业协议转换和云端通信开发效率团队熟悉传统RTOS开发但对Linux生态相对陌生面对这些需求我们最初考虑了三种技术路线方案类型优势劣势裸机(HAL)极致实时性低延迟开发效率低功能扩展困难单一RTOS较好的实时性已有开发经验复杂功能实现成本高LinuxRTOS 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架构的最终选择经过前两种方案的尝试我们最终将目光投向了AMPAsymmetric 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: rtos8000000 { reg 0x0 0x08000000 0x0 0x01000000; }; }; amp { compatible rockchip,amp; cpu-mask 0xC; /* CPU2-3 */ memory-region rtos_reserved; };4.2 开发环境搭建AMP系统的开发环境搭建比单一系统复杂得多主要步骤包括获取SDKrepo init -u ssh://gitgitlab.com/rockchip-amp/repo_manifest.git -b master repo sync编译Linux内核cd kernel make ARCHarm64 rockchip_linux_defconfig make ARCHarm64 -j8编译RT-Threadcd rt-thread scons --menuconfig scons -j8生成完整固件./build.sh amp4.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平衡实时性与功能丰富性开发效率较高复杂功能混合关键性LinuxRTOS AMP兼顾非实时复杂功能与硬实时要求充分发挥多核性能高性能计算弱实时纯Linux开发生态丰富适合算法密集型应用对于RK3568平台特别建议资源分配策略实时任务内存预留不少于16MB为RT-Thread保留至少两个专用CPU核性能调优重点确保RT-Thread核的隔离性禁用中断共享优化共享内存访问模式减少缓存抖动开发流程建议先独立开发验证各子系统功能再逐步集成测试核间通信最后进行整体性能优化在项目后期我们还发现了一些值得分享的实践经验电源管理Linux侧的DVFS会影响RT-Thread核的实时性建议固定频率启动顺序应先启动RT-Thread再启动Linux避免资源冲突调试接口预留专用UART给RT-Thread与Linux控制台分离
