在上一篇笔记《如何写一个健壮且高效的串口接收程序？》中鱼鹰分析了串口接收的一些坑，这些经验对于写一个好的串口接收程序是很有帮助的，而且笔记中最后得出一个串口接收的总结“空闲中断 DMA 队列 内存管理 定时控制”。因为空闲中断的误触发，导致我们不得不使用定时器来达到接收完整一帧的效果，这样一来，就会导致一些问题：1、数据吞吐率低，发送方需要延时一段时间后才能发送下一帧；2、响应不及时，因为有延时，必然导致接收方回复慢。3、空间利用率不高，如果一个短帧到来，会导致整帧缓存空间（这个空间大小一般是最大帧长）无法使用。今天鱼鹰自己对自己进行一次升级，改用“空闲中断 循环DMA 无锁队列”的方式进行最为高效的接收方式（无锁队列以后有时间再写，这次的重点不在这）。这种接收方式鱼鹰在接触了循环队列后就开始思考了，那个时候工作没多久，然后一位前辈使用的就是空闲中断 DMA 的方式接收，也算是惊到鱼鹰了。后来鱼鹰在想，循环队列的优势显而易见，而DMA在设置为循环模式时，天然就是一个循环队列，我是否能将循环队列和DMA相结合，实现一个循环缓存空间呢？具体当时是如何思考的鱼鹰已不记得了，只知道当时利用KEIL的模拟功能貌似是实现了想要的效果，但是在实际测试过程中应该是出现了问题，所以导致这个想法搁置了。这个实现代码鱼鹰会一并上传到公众号，让各位道友参考一二，自认为自己符合条件的自行获取就是了。直到最近看到头条一位读者的评论，鱼鹰的心思才又活泛起来了，通过评论交流，终于理解了其中是如何实现的，也想到了如何将其和无锁队列相结合，也就有了这一次笔记的分享。实习时初次接触空闲中断时，用的接收方式是 空闲中断 串口接收中断，这个算是 V1.0版。后来正式工作后接触到的是 “空闲中断 DMA”这个是V2.0，后来鱼鹰在此基础上进行改进，加入了队列，加入了定时器，算V2.5好了。这次效率更高，而且空间利用率也高，中断处理简单到到极致，定为V3.0。可能很多人在之前的笔记中根本无法真正理解鱼鹰的本意，因为这份笔记太长，如果没有一定的经验根本无法体会，尽管有一份参考代码放在后台供各位道友进行参考，但是因为那份代码只解决了一个定时器控制问题，注释也不详尽，还是鱼鹰的初次思考，所以相信很多人看到这份代码都是云里雾里的，还是无法实现其中的细节。2、串口中断处理时，每接收一个字节存入缓存空间（注意控制越界问题）3、一旦空闲中断来了，停止接收，设置标志位，通知上层已完成一帧数据的接收，上层负责数据的处理工作。当然为了防止误触发，也可以使用定时器进行进一步控制，也可以在此基础上加入缓存队列。1、初始化时开启串口的空闲中断，并且初始化为正常DMA。2、触发空闲中断时，通知上层接收完成并且将其拷贝到一个缓存中供上层使用，然后重新启动DMA进行下一次的接收，因为帧与帧之间有空闲时间，只要保证这段时间大于中断处理时间，那么接收一般不会出现问题。这里有一个关键点就是，如何获取这次接收的数据长度：Rev_Size = DMA_Set_Size - CNDTR
Rev_Size 是实际接收的长度，DMA_Set_Size是初始化DMA时设置的缓存大小，这个大小一般大于等于一帧数据的最大长度，并且最好是它的2倍以上，这样极端情况下不容易被下一帧数据所覆盖（怕中断处理不及时导致覆盖了之前已接收的数据）。而 CNDTR就是 DMA 寄存器中记录目前剩余需要接收的大小，当它为 0 时表示接收完成，DMA自动关闭。1、初始化时开启串口的空闲中断，并且初始化为循环DMA。2、触发空闲中断时，更新索引，这个索引表示当前写入索引值，用于上层判断缓存空间已写入的数据（鱼鹰前面写了关于循环FIFO的笔记，可自行查看，如果不懂这个，下面的你理解不了，数据结构系列文章之队列 FIFO）。
缓存大小可以根据需要设置，这个需要看你数据处理的延迟时间。比如说发送者10 ms发送一帧数据，你的数据处理正常时候10 ms处理一次，但有时候CPU 负担重，你的数据处理优先级较低，那么可能20 ms才会处理，那么缓存空间必然需要大于两帧数据才行，这个空间需要测试后才能确定，而且需要留有一定的富余才行。那么如何获取数据？通过学习循环FIFO的知识我们知道，循环FIFO由两个变量in和out进行数据管理，如果我们的in可以根据DMA剩余量进行更新，那么就可以根据in和out之间的关系知道目前缓存空间里面到底有多少未处理的数据了。那么如何更新呢？鱼鹰就不藏私了，直接在此说明，不过加入无锁FIFO的就自己从参考代码中获取了，这个其实都差不多。In = DMA_Set_Size - CNDTR（CNDTR永远不会是0）
是不是很惊讶，是不是不可思议，你和终极接收方式只差一层窗户纸？而现在再看这个代码，已经忘记当初是咋想的了，但是这个式子确实可以更新in的值，即上面的offset，只是当初想的有点复杂了。简单来说，就是先通过CNTR和之前的 offset 获取目前的接收的长度（这个应该是受V2.0版本影响），然后根据长度更新目前的offset。只要有了in的值，然后又有out，那么获取队列中的数据也就不难了。其实如果说采用循环DMA只是减少了中断的代码，让中断处理时间更短，那么鱼鹰还是会选择以前的V2.0的接收方式，毕竟这种方式实现了帧隔离，但是读者的一个评论提醒了我，那就是这种方式不需要重新启动DMA。意味着高效，意味着DMA持续工作，意味着不存在因为DMA的短暂关闭而导致数据丢失。1、中断代码及其简单，像上面那种只是更新in的话只需要三条代码即可完成。3、因为不需要重启DMA，也就减少了这段时间串口数据的丢失4、数据吞吐量可以达到最大化，每帧数据只需间隔一个空闲时间即可继续发送。最大程度的利用了串口的接收能力，而且不用担心数据丢失，这对于快速数据的接收是非常有好处的。5、就算你不想数据帧之间出现空闲间隔时间，你也可以通过一个定时器定时更新in的值。6、即使在串口中断更新in的值时DMA又在接收数据，也不会出现问题，这个原理和无锁FIFO一样。8、即使因为中断体系短暂关闭，而导致空闲中断不能及时处理，也不会影响DMA在后台自动接收数据。1、因为所有数据都在一个缓存中，无法实现帧与帧之间的硬性隔离，所以必须通过数据本身确定一帧数据，对于数据的处理难道较高，这一点目前鱼鹰采用状态机处理，但是总感觉效率较低，后期看看能不能升个级啥的。2、因为无法实现帧隔离，所以一旦因为硬件干扰啥的导致多或少接收一个字节数据，又或者数据接收错误，那么再从缓存中得到一帧完整数据就比较耗时了，所以状态机一定要有自恢复机制，能够继续处理后续的数据帧。3、一旦数据处理比较慢，而剩余缓存空间不够大，那么未处理的数据将自动被DMA接收的新数据所覆盖，所以缓存大小一定要有富余。4、一次发送的数据大于或等于缓存空间，那么in的值就有问题，所以发送者发送的一帧数据一定不能大于或等于缓存空间，切记这一点。上面的第3点可以通过处理来提醒用户缓存不够（有些无法情况无法发觉），这个鱼鹰在代码中做了处理，各位可参考。而第四点一般不会出现，这是在设计DMA缓存时就会考虑的。但是1、2两点因为所有数据帧都在一个缓存空间中，对状态机的要求很高，而目前鱼鹰实现的状态机感觉不怎么样，就不拿出来献丑了。
