1. CAN总线驱动开发实战：从Linux内核到车载网络
深夜的车间里，示波器上跳动的波形暴露了一个诡异现象：ECU发送的关键帧在应用层偶尔丢失，但CAN卡抓包显示总线数据完整。这不是简单的丢帧问题，而是驱动层到应用层的"断流"现象。经过三天排查，最终发现问题出在驱动中netif_rx()的调用时机上——NAPI轮询和中断上下文的冲突导致skb被提前释放。这类问题在小流量实验室测试中难以发现，只有在实车高负载路试时才会显现。
在车载和物联网系统中，CAN总线如同人体的血管网络，承担着关键的数据传输任务。与智能化的以太网不同，CAN总线缺乏TCP/IP的自动重传和流控机制，其可靠性和实时性完全依赖于驱动和协议栈的稳定性。本文将深入探讨Linux环境下CAN总线驱动的开发要点，分享实战中的经验教训。
1.1 Linux CAN驱动框架解析
Linux的CAN子系统采用典型的三层架构：Socket CAN层、核心层和设备驱动层。对于初学者来说，can_raw、can_bcm、can_gw等协议可能令人困惑，但其核心思想很简单：将CAN帧映射为Linux网络数据包。
Socket CAN是Linux CAN子系统的设计亮点，它通过BSD Socket API来操作CAN设备，使得CAN设备在网络层面可见。这种设计带来了诸多优势：
- 使用标准的
send()、recv()函数收发CAN帧 - 通过
ioctl()设置滤波规则 - 支持
select()、epoll()等多路复用机制 - 上层应用几乎无需学习新的API
在驱动层，开发者主要需要实现struct net_device的几个关键回调函数：
ndo_open()：设备打开时的初始化ndo_start_xmit()：数据发送处理ndo_stop()：设备关闭时的清理工作
硬件中断收到帧后，驱动需要构造skb（socket buffer）并向上层传递；应用层发送的帧则会通过ndo_start_xmit()回调到达驱动，由驱动将其送入硬件FIFO。虽然原理简单，但实际开发中会遇到各种细节问题。
1.2 硬件抽象与芯片特性处理
CAN控制器主要分为两类：MCU内置型（如NXP的FlexCAN、TI的DCAN）和外挂SPI接口型（如MCP2515、MCP2518）。不同类型的控制器在驱动实现上有所差异。
内置控制器通常通过平台总线（platform bus）访问，而外挂控制器则使用SPI总线。无论哪种类型，寄存器操作都必须严格遵循最新版芯片手册。我曾遇到过国产芯片的验收滤波器配置问题——旧版手册要求"保留位填0"，但实际需要填1才能正常工作。
配置时序是另一个容易出问题的环节，特别是从睡眠模式唤醒后的延迟时间。如果唤醒后立即发送帧，第一帧很可能会丢失。以下是一个配置验收滤波器的示例代码片段：
c复制void setup_filter(struct my_can_priv *priv)
{