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

开发与问题
1

使用官方CAN sample例子，can_send和can_get测试CAN数据收发耗时，发现效率比较低。

具体测试方法如下，MCU扩展板的CAN5, CAN6连接在一起，短接120欧姆跳线。

分别执行

./canhal_get bypass &

和

./canhal_send bypass 6

并在两个线程中分别在发送前一刻和接收到数据的那一刻记录时间戳（单位us），计算两者的时间差，记为一次通讯耗时，经过长时间测试，发现，这个耗时大约300微妙。

由于目前使用的关节只能采用一问一答方式来控制，并且我需要5路canfd总线，控制31个关节。所以，如果通过Acore来操作MCU侧的CAN实现数据收发的话，看上去性能达不到要求。

我想，可否在MCU1侧开发程序，MCU1完成所有关节的数据发送和接收，然后，将所有关节（6个）的数据按照1ms的周期和Acore交互，这样效率应该会比较高吧。但是，这样的话，需要MCU侧开发程序。这样的开发方式不知道官方是否支持。

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 性能的关键，值得投入开发。

3

MCU侧目前开发的使用手册都在RDK手册，您指的MCU1侧开发程序 在手册中是否有相关内容？没有的话可能需要向内部确认了，看看这边是否还有更加具体的开发需求描述？