333_S32K144 CAN回调函数
完整的S32K144的学习汇总如下：
https://github.com/GreyZhang/g_s32k144
继续S32K144的学习，还是进一步深入CAN相关的知识细节。这一次学习小结一下CAN的几个回调函数，因为这个会关系到接下来我对几个协议栈相关知识的探索。不仅如此，整个CAN驱动是协议栈实现的基础，在学习协议栈之前肯定得有一个深入的掌握。
今天需要看看CAN的接收以及发送等回调函数，其实在S32K144的SDK平台中，这几个回调函数都是融合成了一个。但是，回调函数中存在一个事件儿传递参数，这几个参数能够帮我识别不同的事件类型。
上面是几种不同事件的定义，其实了解这部分事件究竟是什么比较好的一个参考就是每一个事件定义后面的注释。
为了能够捕获到这些事件动作，需要注册一个回调函数。注册用到的接口如下：
而回调函数的原型如下：
接下来，做简单的测试设计。我做了一个测试回调函数如下：
上面函数设计完成之后，通过回调函数的注册接口完成回调函数的注册。
这样，回调函数就可以对各个事件作出相应的逻辑处理。为了能够看到回调函数的动作效果，回调函数中的计数器可以全都通过串口打印出来。
软件中，注释掉了部分之前的测试代码，稍微有点不美观。注释掉目的是为了让测试结果看起来更明显。由于上面的测试代码中带着一个发送接口，首先可以确认的是这个软件测试的时候会观察到发送成功的回调处理动作。
动作确实是触发了，不过似乎有一个数目统一不起来。发送回调似乎多执行了一次，后面一定得做一下推理分析。
通过给CAN总线发送报文，又一次触发了一个事件。这次是报文接收的事件，我们的驱动中使用了FIFO，这里也是FIFO接收。至于其他的几个事件，有的不好在当前的环境中造出来。不过，FIFO的警告或许可以做出来，那就是通过大量给CAN总线发报文实现。
每毫秒一帧报文，接收功能，看上去没有任何问题。
每毫秒2帧报文接收，也没有问题。而且从数值差还能够看出每秒大概有2000报文接收到。不过，事件总数似乎是有偏差的，感觉上似乎是有异常了。这算是一个很好的测试用例，后面我可以通过其他的方式来探究一下究竟是什么问题发生了。
每秒3000帧，依然没有看到其他的事件造出来。或许还是不够多？
CAN分析仪上位机能够看得出，现在的负载率还没有到最高。其实，这里的信息还是很多的，有一些数据的统计。不知道后面是否可以作为我学习的一个参考。接下来，继续增加报文。
看起来还没到4000帧/s，但是负载率已经到了95%。
从现在的调试记录看，只能说这个fifo的接收能力还是很强的。接下来，继续尝试增加负荷。
我现在CAN波特率是500K，FIFO的扫描频率1ms，其实1ms内，CAN的报文最多4帧左右。6级缓冲的FIFO的确是不该有溢出等问题。看起来，想要造成这个事件应该要降低FIFO的扫描频次。
果真这次把几个事件都造出来了，这是一个很好的结果，因为这个也让我清楚了这个CAN的接收应该采用怎么样的接收扫描频次才算是合理。其他几个没有测试的事件暂且不去测试了，但是后面或许在我尝试去看其他功能的时候会逐渐测试到。
在撒丁岛有一句谚语：想要娶老婆，就要先能养活自己。不管是要养活自己，还是养活自己的父母妻儿，我们都需要有自己的手艺。或许有机会能够看到我学习笔记的人，都跟我是或多或少的同行。我祝愿你们能够熟练掌握这门手艺，也希望我这不成熟的学习笔记能够或多或少帮到你！
完整的S32K144的学习汇总如下：