双接口型PCAN-USB驱动

1、背景

• 作为半年前一篇文章《记一次更换PCAN固件的经历》的续集 （重点在此文结尾的总结和后续计划章节）。

• PEAK-System官方论坛早年的一篇帖子。

• 双接口指的是支持同时使用网络和字符设备两种接口，或最低限度不需要重新编译和切换驱动。

2、实现要点

• 核心逻辑：基于Linux内核主线源码（位于drivers/net/can/usb/peak_usb目录）和PEAK-System官方驱动而改写， 只有这样才能确保正确性和开发进度。在实现基本功能的基础上，其余的特性才是锦上添花。

• 程序内部的数据和状态的共享：更多的考虑是软件工程方面的设计问题， 而非底层技术（包括硬件和操作系统）。当然，理念设计和代码实现并非泾渭分明， 所以在实际的编码中往往需要将两者放到一起考虑。可简单举例以作说明：
  • 例1：由于网络接口和字符设备的接收渠道均是USB接口，所以一份数据就需要分发到两个地方， 因而需要一份URB、两份内部缓冲区；而对于发送，这两个接口的数据来源不同， 因此在数据通道容量足够的前提下，URB和内部缓冲区都是两份。
  • 例2：需要控制下位机的通断，但又不能在网络和字符设备两个接口各自开关的时间节点切换一次下位机状态， 所以需要维护内部的阶段值、引用计数，这就需要借用原子性接口、锁机制等等。 此外，需要共享的还有设备基准时间值。
  • 例3：两种接口对数据所用的储存方式不同——网络接口可沿用sk_buff那一套规则， 字符设备则需要自行设计特定数据结构的数组或队列，并维护内部的读写指针。 这两种方式必须能很好地与URB对接。

• 改进运行效率：网络接口目前看起来能优化的空间并不大，字符设备倒是存在一些低效操作可以优化， 可以考虑的其中一种手段是使用内存映射减少内核空间与用户空间的数据复制次数。

• 提升操作便利度（懒人刚需）：例如下位机插入即激活网络接口、通过传递模块参数值进行更多的定制化、 内核更新可自动编译（尽管官方驱动也有此特性，但它是一个版本一个压缩包，而本项目是在同一个目录下进行升级）等等。

• 避旧趋新：最典型的例子是procfs接口可以完全放弃（Linux官方在很早之前就已提倡任何新代码不应再使用此机制， 除非需要兼容极少数旧设备，而PEAK-System官方驱动虽然保留此接口，但新近的上位机程序pcanview并不使用）， ioctl能免则免，这两者可考虑使用sysfs代替，结构清晰，代码简洁。此外，官方驱动里单项读写接口也没必要移植过来， 仅实现批量读写接口即可，有利于提升吞吐量，改进运行效率。

• 未来还可能增加更多特性，无法在此一一阐述，感兴趣可自行查阅源码。

3、对官方驱动和上位软件的若干吐槽

• 代码臃肿：一个驱动项目里完全集成了USB、PCI、ISA、Dongle等接口的基础版和专业版/升级版的功能， 还有很多兼容旧版逻辑的代码，即便不至于说成屎山，也是相悖于Unix哲学的典型。最初的想法是直接改官方代码， 但看了几天代码之后，脑壳疼，打消了这个不切实际的想法，只整理了需要用到的逻辑，另开新项目重写。顺带一提， 文首那篇官方论坛的帖子里有用户提问未来是否支持同时使用两种接口，官方回复is not a conceivable option， 也已暗示连作者都改不动了……

• CPU占用过高：pcanview运行起来能占一个CPU核100%的计算资源！通过strace命令的追踪， 发现主要耗费在ppoll系统调用，极有可能是将该系统调用的超时参数值设为0，马不停蹄的轮询有无数据就绪…… 究竟是犯了一个低级错误，还是有什么特殊的考虑，这就不得而知了……

• 界面简陋功能不全：Linux版pcanview采用的是字符界面（基于ncurses），而不像Windows版那样用图形界面， 要说是为了迎合一部分命令行爱好者的口味并且顺便实现拓宽软件适用范围的效果，倒也说得过去， 但功能特性没有Windows版的齐全又该作何解释？

• 更新进度缓慢：这个套件应该很多年前就开始做了，但Linux版的pcanview直到Ubuntu 22.04还是很简陋…… 个人猜想主要不是技术原因，而更多是商业上的考虑。pcanview是基础版软件，不收费，无利可图， 何况Linux版的用户很少，所以投入的资源也少，这也顺便解释了上一点的原因。

• 上位软件闭源：能理解，但不舒服。对官方来说，也是好坏参半，不需多作解释。

4、后续计划

• 字符设备接口支持发送操作：目前仅支持接收操作。

• 按需添加更多的定制化参数。

• 增强驱动的健壮性，包括但不限于提高容错性、对新内核的接口变动适配。

• 研究官方驱动里的时间校正算法，看有无改进之处。

• 跟随上位机软件（即pcanview）的变动而及时适配，或自行开发一个新的（可能性很小， 除非极需此类分析软件且pcanview完全不够用）。

• 使用平价的STM32或类似的芯片重做一个下位机（必做，但精力所限，产出之日遥遥无期）。

• 研究更底层的CAN主控逻辑、此类分析软件普遍的功能特性，或升级成CAN-FD（需另开项目）， 这些均是视工作需求或个人需要才决定做不做，时间上也会不确定。

• 以上这些将会直接体现在项目代码中，本文不再更新。