提高RDK-S100的CAN-IPC通讯效率的方案

开发与问题
2

你好，@eric_qiang。关于你提到的 RDK-S100 CAN-IPC 通讯效率问题（300us 延迟）以及 MCU 侧开发的可行性，结论如下：

核心结论

  1. 官方完全支持 MCU 侧开发：RDK-S100 的设计初衷就是“算控一体”，官方提供了完整的 MCU 开发 SDK、编译工具链和启动流程。你提出的“MCU1 集中收发，Acore 周期性交互”方案是官方推荐的高性能架构。
  2. 300us 延迟是 IPC 机制的正常开销：你测试的 can_send/can_get 是 Acore 通过 IPC（进程间通信）调用 MCU 资源的模式，涉及上下文切换和数据拷贝，300us 的延迟对于高频实时控制（尤其是 31 个关节）确实存在瓶颈。
  3. 优化方案可行且必要：将 CAN 驱动逻辑下沉到 MCU1（FreeRTOS 环境），由 MCU 直接操作硬件收发，再通过共享内存或精简 IPC 与 Acore 交互，可将控制周期稳定在 1ms 甚至更高频率，完全满足你的需求。

推荐架构方案

方案对比

方案 架构 延迟 适用场景
当前方案 Acore 应用 → IPC → MCU 驱动 → CAN ~300us+ 低频调试、非实时控制
推荐方案 MCU1 应用 → CAN 硬件
:up_down_arrow: (共享内存/IPC)
Acore 应用		 <50us (MCU 侧)
~1ms (交互周期)		 多关节高频实时控制

实施步骤

第一步：确认开发环境
官方提供了详细的 MCU 开发指南，你需要准备 Ubuntu 22.04 环境（推荐 WSL2）和 SDK。

第二步：MCU 侧开发 (MCU1)
在 MCU 侧编写 FreeRTOS 程序，直接调用 HAL 库操作 CAN 控制器：

  1. 任务划分：
    • 发送任务：周期性（如 1ms）向 5 路 CANFD 总线发送关节指令。
    • 接收任务：监听 CAN 中断或轮询接收关节反馈，解析数据。
    • 通信任务：通过 IPC/共享内存与 Acore 交换数据（如：将 31 个关节的反馈打包成一个结构体，每 1ms 更新一次）。
  2. 代码位置：通常在 SDK 的 ./Target/Target-hobot-lite-freertos-mcu1/target/ 目录下开发。
  3. 关键 API：使用官方 CAN HAL 库（参考 can_multi_ch 示例），避免使用 Acore 侧的 canhal_send/get 工具。

第三步：Acore 侧适配
Acore 侧不再直接操作 CAN，而是：

  1. 读取 MCU 共享内存中的数据（关节反馈）。
  2. 运行控制算法（如力矩控制、轨迹规划）。
  3. 将计算结果写入共享内存（关节指令）。
  4. 利用 ROS 节点或其他进程进行上层决策。

关键资源与排查建议

  1. 参考案例：

    • 社区已有类似多路 CAN 控制案例，参考 RDK-S100 的 MCU 端报错（用户控制 27 个电机，200Hz 频率），说明该方案已验证可行。
    • 查看 SDK 中 app/Can/can_multi_ch 示例，这是多路 CAN 并发收发的基础模板。

  2. 注意事项：

    • 实时性保障：在 MCU 侧开发时，注意 FreeRTOS 任务优先级的设置，确保 CAN 收发任务优先级高于其他非实时任务。
    • 数据同步：Acore 与 MCU 的数据交互需注意原子操作或信号量机制，防止数据读写冲突。
    • 版本差异：确保使用的 SDK 版本与板卡固件版本匹配，不同版本的 HAL 库接口可能有细微差异。

下一步行动建议

  1. 阅读 MCU 开发环境准备教程 搭建编译环境。
  2. 在 MCU 侧尝试移植 can_multi_ch 示例，实现 5 路 CAN 的独立收发测试。
  3. 设计 Acore-MCU 通信协议（结构体定义），实现 1ms 周期的数据交换。

如果在 MCU 代码编译、烧录或 HAL 库使用中遇到具体问题，欢迎随时发帖交流，社区和官方 FAE 都会提供支持。这种架构是发挥 S100 性能的关键，值得投入开发。