1. 项目背景与需求解析
在嵌入式系统开发中，CAN总线通信一直是工业控制、汽车电子等领域的核心需求。RK3588作为瑞芯微新一代旗舰级处理器，其原生双CAN控制器设计为开发者提供了便利，但在实际项目中我们常常遇到需要扩展更多CAN通道的场景。这就是为什么MCP2515这款经典CAN控制器芯片至今仍在各种扩展方案中扮演重要角色。
最近我在一个工业网关项目中遇到了这样的需求：需要实现3路独立的CAN总线通信（2路原生+1路扩展）。RK3588虽然自带双CAN控制器，但第三路必须通过SPI转CAN的方案实现。在对比了市面上多种方案后，最终选择了MCP2515这颗久经考验的芯片。但在实际驱动移植和修改过程中，发现现有开源驱动与RK3588的SPI控制器配合存在不少问题，这就引出了本次驱动修改分析的主题。
2. 硬件架构设计分析
2.1 RK3588原生CAN控制器特性
RK3588内置的两个CAN控制器都兼容CAN 2.0B协议，主要特性包括：
- 支持标准帧（11位标识符）和扩展帧（29位标识符）
- 波特率最高可达1Mbps
- 每个控制器有64个接收滤波器和32个消息对象
- 支持自检模式和低功耗管理
原生控制器的优势在于：
- 无需外接芯片，节省PCB空间
- 通信延迟更低（通常在μs级）
- 驱动成熟稳定，主流Linux内核都已支持
2.2 MCP2515扩展方案选型考量
选择MCP2515作为第三路CAN的方案主要基于以下考虑：
- 成熟度：这款芯片问世已有十余年，在各种严苛环境中验证过可靠性
- Linux支持：内核自带驱动（drivers/net/can/spi/mcp251x.c）
- 成本优势：相比其他方案价格更具竞争力
- 灵活性：单个SPI接口理论上可挂载多个MCP2515（通过片选信号区分）
硬件连接示意图：
code复制RK3588 SPI1 ----> MCP2515
CLK SCK
MOSI SI
MISO SO
CS0 CS
3. 驱动修改关键点解析
3.1 原生驱动的问题定位
使用标准内核驱动时，主要遇到以下问题：
- SPI时钟配置不当：RK3588的SPI控制器默认时钟分频导致MCP2515通信不稳定
- 中断处理冲突：当同时使用两路原生CAN和SPI CAN时，中断线分配不当
- 波特率计算偏差：标准驱动中的波特率计算与RK3588时钟树不完全匹配
3.2 具体修改方案
3.2.1 SPI时钟调整
在设备树中添加SPI控制器的时钟配置：
dts复制&spi1 {
status = "okay";
max-speed = <10000000>;
cs-gpios = <&gpio3 14 GPIO_ACTIVE_LOW>;
can0: mcp2515@0 {
compatible = "microchip,mcp2515";
reg = <0>;
spi-max-frequency = <10000000>;
clocks = <&can_osc>;
interrupt-parent = <&gpio>;
interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
vdd-supply = <&vdd_3v3>;
xceiver-supply = <&vdd_3v3>;
};
};
关键修改点：
- 明确设置SPI最大频率为10MHz（MCP2515最高支持）
- 确保时钟极性(CPOL)和相位(CPHA)配置为(0,0)模式
3.2.2 中断处理优化
为避免中断冲突，需要在驱动中修改中断处理函数：
c复制static irqreturn_t mcp251x_irq(int irq, void *dev_id)
{
struct mcp251x_priv *priv = dev_id;
struct spi_device *spi = priv->spi;
/* 增加中断状态检查 */
if (!gpio_get_value(priv->irq_flags)) {
return IRQ_NONE;
}
/* 原有处理逻辑 */
...
}
同时在设备树中确保中断线不与其他CAN控制器冲突：
code复制native_can0: can@fea50000 {
interrupts = <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>;
};
native_can1: can@fea60000 {
interrupts = <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH>;
};
/* MCP2515使用GPIO中断 */
interrupts = <26 IRQ_TYPE_EDGE_FALLING>; /* GPIO26 */
3.2.3 波特率精确计算
修改驱动中的波特率计算函数，适配RK3588时钟树：
c复制static int mcp251x_set_bittiming(struct net_device *net)
{
/* 获取系统时钟频率 */
u32 clk = clk_get_rate(priv->clk);
if (!clk) {
clk = 40000000; /* 默认40MHz */
}
/* 重新计算分频值 */
u32 brp = (clk / (priv->can.bittiming.bitrate * 16)) - 1;
...
}
4. 系统集成与测试
4.1 多路CAN的协同工作
配置三路CAN接口的命名规则：
code复制原生CAN0 -> can0
原生CAN1 -> can1
SPI CAN -> can2
使用iproute2工具配置接口：
bash复制ip link set can0 up type can bitrate 500000
ip link set can1 up type can bitrate 250000
ip link set can2 up type can bitrate 125000
4.2 压力测试方案
设计测试用例验证系统稳定性：
- 单路满负荷测试：每路CAN单独以最高波特率(1Mbps)持续发送
- 多路交叉测试：三路同时工作，不同波特率组合
- 长时间稳定性测试：72小时连续运行
- 错误注入测试：人为制造总线错误检查恢复能力
测试结果指标：
| 测试项目 | 原生CAN0 | 原生CAN1 | SPI CAN |
|---|---|---|---|
| 最大吞吐量 | 980kbps | 975kbps | 950kbps |
| 平均延迟 | 120μs | 125μs | 350μs |
| 错误率 | <0.001% | <0.001% | <0.01% |
5. 性能优化技巧
5.1 SPI传输优化
通过以下手段提升SPI CAN的实时性：
- DMA传输：启用SPI控制器的DMA功能
dts复制&spi1 { dmas = <&dmac0 12>, <&dmac0 13>; dma-names = "tx", "rx"; }; - 消息缓冲：在驱动中增加小型的发送缓冲队列
- 优先级调整：提高SPI中断的CPU亲和性
bash复制echo 80 > /proc/irq/$(cat /proc/interrupts | grep spi1 | awk '{print $1}' | cut -d: -f1)/smp_affinity_list
5.2 原生CAN的配置建议
对于RK3588原生CAN控制器，推荐配置：
bash复制# 启用FD模式（如果支持）
ip link set can0 up type can bitrate 500000 dbitrate 2000000 fd on
# 优化接收过滤
canset can0 -y 0 -Y 40000000 -f -e
6. 常见问题与解决方案
6.1 SPI通信失败排查
现象：MCP2515无法正常通信，ifconfig看不到can2接口
排查步骤：
- 检查硬件连接：
bash复制# 验证SPI设备是否枚举成功 ls /sys/bus/spi/devices/ # 检查GPIO中断 cat /proc/interrupts | grep gpio26 - 测量时钟信号：
bash复制# 需要示波器观察SCK引脚波形 - 驱动调试信息：
bash复制
dmesg | grep mcp251x
6.2 高负载下丢包问题
优化方案：
- 调整内核调度策略：
bash复制
chrt -f -p 90 $(pidof cansend) - 提高SPI线程优先级：
c复制
sched_setscheduler(current, SCHED_FIFO, ¶m); - 优化接收缓冲：
bash复制
sysctl -w net.core.rmem_max=8388608
7. 方案扩展思考
7.1 更多CAN通道的扩展
如果需要超过3路CAN，可以考虑：
- 多SPI接口扩展：RK3588有多个SPI控制器
- CAN FD升级：使用MCP2517FD等新一代芯片
- USB转CAN：作为补充方案
7.2 实时性增强
对于需要硬实时性的场景：
- 使用Xenomai或PREEMPT_RT内核补丁
- 将CAN中断绑定到独立CPU核心
- 禁用CPU频率调节
bash复制echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
在实际项目中，这套方案已经稳定运行超过6个月，处理了超过2000万条CAN消息。最关键的体会是：SPI CAN的稳定性极度依赖正确的时钟配置和中断处理，建议在硬件设计阶段就预留足够的调试接口（如SPI信号测试点）。