STM32串口485接收第一帧总是错误怎么解决啊？

大金刚

如题，初始化定时器和串口485，然后在串口接收中断里面把接收到的数据存入buffer，然后开启定时器同时定时计数器清零，定时器我是按0.5ms时长判定，如果超过0.5ms没收到数据，就进入定时器中断服务函数，把设的标志为置1，在main里面检测到标志位如果置1了，就认为一帧数据接收完了，开始解析收到的数据。如果在0.5ms内又接收到了新的数据，我就把计数器清零，继续等待接收下一个字节，认为还是同一帧数据。
现在串口助手发送第一帧给MCU，MCU接收后存入BUF，再把BUF的数据发到串口助手，发现第一帧总是不对，但是从第二帧开始就都对了。第一帧我尝试一个字节一个字节发，回传的数据都没问题，然后我再一帧一帧发，也没问题。
现在就是第一帧发一长串数据就出错，也不知道怎么查，请高手指点下

gsq19920418

接收完或者打算接收时，清下寄存器，你这可能有干扰，第一个数据存寄存器了，要不就rx上加电容
再有一种可能接收和发送切换慢了

myiccdream

传言 RS485 在发送完，不要立即从发送切换成接收，因为这个时候，总线上还是一个有数据状态。
稍微等一下

chen849928055

我碰到过是485芯片的问题,后来我们换了美信的485芯片,就没有第一帧数据错误了

初音之恋

0.5ms肯定不可靠，大多是换向的问题，换向后延时一下再发，发完延时一下再换向

dukelec

按照这个帖子 18 楼先排查一下：
https://www.amobbs.com/forum.php ... 36&pid=12090137

另外串口接收一般都建议使用 DMA 环形接收，配置好就不用动，来数据会自动一直往 环形 buffer 写入，主程序周期性去取数据即可，譬如参考这个代码：
https://github.com/dukelec/cdbus ... ge/usr/app_bridge.c
使用 cduart_rx_handle 来接收环形缓冲区的数据包。

dukelec

myiccdream 发表于 2024-3-21 17:05
传言 RS485 在发送完，不要立即从发送切换成接收，因为这个时候，总线上还是一个有数据状态。
稍微等一下 ...
(引用自3楼)

正常是不需要等的，只要确保停止位已经发送完毕就可以切方向了

顾虑的点是：线很长，停止位前的跳变可能会反射回来，反射传输需要时间，在反射回来之前切成输入，可能会收到反射回来的干扰
还有是担心：错等发送寄存器是否空闲，没有等真正的总线空闲，这时候数据还正在发送，所以加点延迟

对于第一点顾虑：
线长的话，速率一般也不高，停止位发送的时间基本已经大于反射所需时间，不需要额外等待
反射真存在的话，应该加终端匹配电阻消除反射

发送前倒是要等待，特别是速率高的时候，因为接口芯片从休眠到唤醒需要一定时间，如果没有等待就立即喂数据，前面的数据位会畸变
不过一般用 io 口切换不用担心，因为操作 io 口切换也是需要时间的，这个时间够接口芯片唤醒了（使用硬件 DE 控制的话，开头配置一两个 bit 的提前时间即可）
速率越高的接口芯片，唤醒的时间也相应越短

发送完毕加延时弊端倒是很多，譬如对方快速回包，通讯会出问题，见了太多抱怨这种问题的人，最近一次是昨天下午

陆小凤之北京

0.5mS这个时间是没道理的，帧与帧之间空闲IDL通常需要3个半字节，根据你的通讯波特率可以实际算出这个时间。
整帧发送如果没用DMA，单字节发送完需要等待发送完成标志。接收是单字节的吧？不需要在中断里初始化定时器清零什么的，只需要收到第一个字节计时就行。
485的话需要确保你的485收发器的发送使能DE是先打开的，否则你第一帧的前几个字节是有可能没发出去的。

大金刚

查出来为什么第一帧数据一定出错了，发现在中断加了启动定时器的语句以后，接收数据就不对了，尝试在接收中断设标志位，在主程序里面再去开定时器发现也是不行。但是很奇怪，第二帧开始就一直对了

大金刚

陆小凤之北京 发表于 2024-3-22 11:30
0.5mS这个时间是没道理的，帧与帧之间空闲IDL通常需要3个半字节，根据你的通讯波特率可以实际算出这个时间 ...
(引用自8楼)

波特率设的115200,一个字节起始位加停止位一共10位，3.5个字节时间算出来大概是0.303ms，我用0.5ms超时认为一帧结束
程序里面有接收完成标志判断if ((__HAL_UART_GET_FLAG(&g_rs458_handler, UART_FLAG_RXNE) != RESET))，我试过进入这里再开启定时器，也是会第一帧错误
我在初始化的时候是把RE设为0接收，另外写了一个发送函数，第一句就是把RE设置为1

大金刚

问题解决了，第一次进入接收中断开启定时器，计时时长超3.5字节长度认为一帧结束，总是第一帧出错的原因，在图上这个函数HAL_TIM_Base_Start_IT（）里面要加入一条，先清除更新中断__HAL_TIM_CLEAR_IT(htim, TIM_IT_UPDATE);就没有问题了。但是为什么要加这一句的原因还没搞清楚，感觉HAL库操作STM32挺难用的，如果还要修改ST官方库函数，会增加学习和使用的难度，但是寄存器操作也很费劲，标准库函数ST又不更新了，现在主推的是HAL库操作

初音之恋

dukelec 发表于 2024-3-22 10:12
正常是不需要等的，只要确保停止位已经发送完毕就可以切方向了

顾虑的点是：线很长，停止位前的跳变可能 ...
(引用自7楼)

遇到过发送数据完立刻换向导致对方收到的数据出错，你说的立即回复这种也遇到过，需要双方的约定，有的CPU速度快换向就是快，反之就是慢

kitten

大金刚 发表于 2024-3-22 13:12
问题解决了，第一次进入接收中断开启定时器，计时时长超3.5字节长度认为一帧结束，总是第一帧出错的原因， ...
(引用自11楼)

HAL库使能中断的时候都要先清一次对应的中断位的，有了这个经验，下次用别的外设照做就行了，不要尝试去修改官方库，习惯以后还是挺好用的。

Doding

大金刚 发表于 2024-3-22 11:49
查出来为什么第一帧数据一定出错了，发现在中断加了启动定时器的语句以后，接收数据就不对了，尝试在接收中 ...
(引用自9楼)

不能在回调里使用阻塞接收，等这段时间定时器很可能已经超时了。

Doding

大金刚 发表于 2024-3-22 13:12
问题解决了，第一次进入接收中断开启定时器，计时时长超3.5字节长度认为一帧结束，总是第一帧出错的原因， ...
(引用自11楼)

不要改库函数，你把回调里的阻塞接收去掉，放在回调外面，回调里只设置标识位，串口接收不要一次收1个字节，这样收到1个字节就关一次串口中断，缓冲区设置长一点。