完整的S32K144的学习汇总如下：
https://github.com/GreyZhang/g_s32k144
继续S32K144的学习，昨天稍微深入学习测试了一下FIFO的接收模式，使用的是中断接收的方式，最终感觉让我打开了一扇新的学习大门。原来这个CAN的收发不仅实现容易，而且功能十分强大。
昨天调试FIFO接收功能的时候，使用的是中断模式。今天尝试一下DMA模式下的CAN消息收发。从SDK的信息来看，似乎收发中只有接收是能够开启DMA模式的。
从配置的数据结构信息也能够看得出来。而这一次，我尝试进行FIFO DMA模式使用的是DMA的通道2。
测试还是使用的之前的那一份测试代码，核心部分如下：
从上面的结果看，发送的事件类型是没有任何变化的，自然也不是走的DMA的模式。接下来，给CAN总线发送一帧报文。
这一次的事件看得出是DMA完成的一个事件，也说明我们的DMA模式配置成功了。
继续测试，报文每秒100帧。
从这个结果看，应该是没有丢帧。
每秒1000帧的报文发送。
依然是没有出现警告或者是FIFO溢出的情况，看起来，两种模式下的FIFO接收似乎也没有太大的使用体验上的差异。
继续增加报文，增加到每秒2000帧的时候，发现软件直接卡死了。DMA本身的这个功能我还是不是很熟悉，但是从行为思考上来看，应该是短时间内DMA连续触发，原来的存储不能够进行二次存储？这是我一直以来的一个思维模型，不一定正确。DMA的详细知识，我还是需要学习的。按照这个模型，解决问题的方式就是增加扫描频次。我采用了更快的扫描频次之后，在总线负载率达到了99%的情况下依然没有出现软件故障。不过，如此对比下来，或许中断的表现更加令我满意。后续的CAN相关的知识学习，或许我还得基于中断好一些了。不过，DMA的使用我还是得继续探究下去。
今天是清明节，而今年的清明节尤为不同，到处都在进行默哀纪念。就连天安门广场，也进行了降半旗的悼念。悼念的是疫情期间牺牲的烈士以及逝世的同胞。在此，我也对那些经历过磨难的人表示感谢！正是因为这些人的奉献，保住了我们社会的安全与稳定。也让我们能够有着更加健康、和平的生活。我不是医务工作者，在这场灾难中无法提供更多的帮助。但是我希望，后续我对于科技的追求以及执着能够对我们这个社会哪怕贡献出一丝一毫的力量，让部分人的生活因为我们的科技而有着质的提升，那我将会十分欣慰！再次悼念逝去的医务人员以及病逝的同胞，再次感谢医务人员的奉献！
完整的S32K144的学习汇总如下：
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
