计划没有变化快，周一计划的任务几乎没怎么做，时间完全交给了一个BUG；
最近大家在做新主板的功能，同事说DeviceNet不通，尽管我对DeviceNet一点不懂，不过好歹之前测过CAN模块在新主板上的功能，于是负责起了这个bug；
电脑连上CAN分析仪，包都看不到，上哪通去？搞硬件的同时出差了，没人懂连线的方法，算了，自己试吧；反复接线，终于接通了，在我这的环境，改了改代码，能够看到数据包了；
同事拿过去一看，依然不行，然后问我怎么改的代码，我跟她一起看的时候，注意到我们的代码里的波特率居然跟标准的不一样？？什么？这。。。改成一样的，拿到同事环境，果然那边也通了；问了下上面，说是跟具体硬件有关，以前是故意这样写的；
连上DeviceNet模块吧，一试，不通啊！！同事说把发送周期调大一点吧，改之，果然，通了；
好吧！这是为什么？？难道是别的线程的优先级太高了，抢占了当前发送线程？？于是我把相关的3个线程绑定到一个CPU上，而且只有他们3个线程；他们的优先级也规划好；启动，依然不通；
打日志吧；看到错误是发送缓冲区已满；还是怀疑优先级影响了调度，于是将填充队列线程的优先级降低，不受其他线程影响；启动，依然不通；但是这个填充线程还是调用了，证明，两个更高优先级的线程主动放弃了CPU；
于是在库写函数的前后加日志，以确定是否写入卡住了；果然，经过一些拍之后，就会出现一次卡主的情况，这时候写线程进入睡眠，于是填充数据线程又开始向队列放数据，放着放着就满了；
确认是底层问题，还是考虑，是否应用层线程优先级比系统中断高，抢了系统中断的情况，于是将应用成的中断优先级都改低，最高不超过系统中断；启动之，依然不通；
好了，这回可以安心查驱动代码了；
从库函数一路过去，是通过ioctl陷入内核的，于是打了各种日志；
在dmesg中发现驱动的发送队列果然被填满了，于是进入了睡眠，证实了之前猜测的情况；
看驱动代码，思路是当第一个包过来之后，就会开启一个标记，有这个标记则靠中断来驱动发送，即每次中断过来都会发送数据；于是考虑是否是中断问题？
在中断的入口处打印时间，果然，发现中断的触发时间很长，甚至接近1ms才有一次中断触发，两次写数据之间甚至隔了几十ms，这不扯呢么？
周六又过来查了一天，觉得作为软件人员，我已经尽力了，周一跟上面汇报一下，联合其他人一起确认下；可能我需要一个懂中断的硬件人员，帮我测测中断频率什么的；
未完待续…
续…
isa就是这么慢…