- 任何靠中断断帧的思路都是不可靠的。
- 在中断响应以及其回调函数内执行 print 的行为都是应该避免的。
- 既然知道帧长度是固定的，那么在应用层处理可行不可行？先把所有收到的数据缓存到应用层，无论这次收到 1 个字节还是 8 个字节，每次接收到数据都判断一次已经接收的数据量够不够 9 个字节。够：处理前 9 个字节，然后把缓存里的前 9 个字节扔掉；不够，等着继续接收。这样做啥也不用修改。唯一需要考虑的是驱动框架层能不能完整有效的把所有自己接收到并交给你应用层
- hal dma 里的那几个中断，在 drv_usart.c 里可能全当 TC 处理了。
- hal 层实现只是芯片厂家提供的一种实现可能。并不代表全部，如果真的介意他的处理方式，还是得用寄存器从最底层自己写
7 个回答
DMA空闲中断的空闲时间很短且不可调，所以依赖DMA空闲中断来分帧，可靠性差。
1、DMA默认开启了传输完成、半传输、传输错误、直接模式错误中断，全部关掉
2、修改回调函数
3、测试结果,暂时正常
@winfeng
看了上述讨论受益匪浅
学习到了。受益匪浅
撰写答案
关注者
1
被浏览
1.2k
关于作者
相关问题
推荐文章
最新文章
对的！帧处理是应用层的事！不要试图依赖驱动特性来做应用层的活。程序设计中应尽量避免这样的做法。
1、并不是依靠中断来分帧，而是DMA中断有时会把完整的一帧给分开。
2、串口DMA接收模式下，开启了DMA的中断，又开启了串口空闲中断。这样DMA中断调回调函数，串口空闲中断又调回调函数，显然没必要。那直接关掉DMA中断，只用串口空闲中断，这样读取时更接近完整的一帧。
3、当只使用串口空闲中断时，应用层处理的报文更接近一帧（不会被DMA中断截断），这样丢弃的字节数更少
4、drv_uart.c中可以关闭DMA的中断，不用修改hal库
@出出啊
@红枫
说这句话的时候，你就已经认为不应该出现不该有的中断打断你的数据接收。
第三条，你又使用空闲中断来分帧
你这种需求，不适合使用串口驱动，用裸机方式实现更好。
@yc961213911
@出出啊
靠中断分帧确实不可取！
昨天调了个设备，PC端串口监控看似完整的一帧，被空闲中断分成了好几帧。所以，应用层需要拼报文并校验。
对于不定长数据，采用什么方法更合适分开一帧呢@yc961213911
可以使用rs485软件包，它可以通过配置合适的字节超时，实现可靠分帧，适合问答试协议和多协议并行处理
@yc961213911 这里取决于PC端对串口数据包的封包发送了。过长的数据是会被他截取成多段发送出去，所以在设备的接收端会变现为触发了多次的IDLE中断。如果不是PC端发送数据，而是由另外一块主板通过DMA TX就只会产生一次IDLE中断了。@yc961213911
modbus rtu中是通过3.5T的一个定时器来判断完整整帧的，即连续3.5个字符的时间没有收到字符则认为是一个完整的帧响应。@Assert