C++基于Socket的Fast CAN通信延迟过高问题及优化方案咨询

• 原生SocketCAN工具集：Linux内核自带的CAN子系统，对树莓派MCP2515硬件支持完善，无额外依赖开销，是当前场景下性能最优的底层通信接口，你现有代码的基础就是SocketCAN，不需要更换底层实现。
• CANopenNode：轻量级开源CANopen协议栈，资源占用极低，专门适配嵌入式Linux场景，原生支持PDO/SDO等CANopen标准通信对象，比自研协议解析逻辑稳定性更高、延迟更低。
• ros_canopen：ROS生态官方适配的CANopen桥接组件，直接对接ROS话题/服务与CANopen通信对象，经过大量机器人场景验证，无需自研桥接逻辑，落地效率高。

你当前的性能瓶颈完全来自软件实现的不合理，和硬件、总线无关：1M波特率CAN总线每秒可承载近10000帧标准报文，你的300~500Hz需求仅占用不足10%带宽，核心问题是读写共用互斥锁+超时轮询读的设计导致锁抢占延迟过高。
优化方向如下：

• 移除多余的读写互斥锁：SocketCAN的RAW socket内核层面已经支持多线程并发读写，你自行添加的mutex是最大的延迟来源，直接删除读写函数中的锁操作即可将写请求延迟从百ms级降到1ms以内。
• 替换超时轮询为IO多路复用：去掉SO_RCVTIMEO超时设置，读线程用poll/epoll监听socket可读事件，无报文时线程休眠，有报文时直接读取，既不会丢包也不会占用CPU，完全不会阻塞写操作。
• 新增无锁写队列缓冲：上层写请求先推入无锁环形缓冲区，写线程独立从队列取帧写入socket，读写逻辑完全解耦，避免上层业务波动影响CAN通信稳定性。
• 硬件与系统优化：将MCP2515连接的SPI总线速率提升到10MHz以上（默认SPI速率极低会成为硬件瓶颈），给读写线程设置SCHED_FIFO实时调度策略，优先级设置为90以上，有条件可以给树莓派打上实时内核补丁，消除偶发调度延迟。
• 协议优化：电机控制、传感器数据等高频传输内容全部使用CANopen PDO传输，PDO无需握手确认，传输延迟比SDO低一个数量级，完全满足你的实时性要求。

按照以下步骤迭代，改动量小且见效快：

1. 第一步优化现有自研代码：删除所有读写锁，将读逻辑改为poll监听模式，仅需修改不到20行代码，即可解决90%的延迟问题，实测写请求延迟可稳定在100us以内。
2. 第二步接入CANopenNode协议栈：替换自研的CANopen协议解析逻辑，使用协议栈原生的PDO回调处理收发报文，避免自研协议的额外开销与bug，协议处理延迟可控制在50us以内。
3. 第三步对接ROS接口：将CANopenNode的PDO接收回调与ROS话题发布逻辑绑定，ROS的控制指令订阅回调直接将数据推入写队列，整个链路端到端延迟可稳定在1ms以内，完全满足性能要求。

内容的提问来源于stack exchange，提问作者boubside