485做收发切换不要再用延迟实现了，请使用TC的传输完成标志做切换标识

eric2013

http://www.armbbs.cn/forum.php?mod=viewthread&tid=86980

木兰花

还得加入一点收发的切换时间，即芯片从rx切换到tx也是需要时间的，不然后丢数的

eric2013

木兰花 发表于 2020-7-18 15:55
还得加入一点收发的切换时间，即芯片从rx切换到tx也是需要时间的，不然后丢数的

这个是你们的程序架构设计有问题导致的。
中断里面接收到最后一个数据后，下次发送才开启的TX的。

使用Modbus RTU那种，更是不用考虑rx切tx的问题，接收完毕后有个3.5个字符的间隔判断。

yklstudent

用TC完成中断切换485使能引脚，一直这么干，放心不会有问题的

xieyang__

我提一个疑问，网上有那种自动控制re/de的485接线方式。相比自动控制，手动控制有啥优势呢？

eric2013

xieyang__ 发表于 2020-7-19 09:45
我提一个疑问，网上有那种自动控制re/de的485接线方式。相比自动控制，手动控制有啥优势呢？

自己搭建的硬控制，如果稳定的话，也可以的。好处就是比专用的，带硬件流控制的便宜。

ghslfgkkl88

xieyang__ 发表于 2020-7-19 09:45
我提一个疑问，网上有那种自动控制re/de的485接线方式。相比自动控制，手动控制有啥优势呢？

是外面用三极管的那种吧？那种会导致速率不高，高了不稳定，好一点的需要用逻辑门搭建，但没见有人这么多，用软件还能省成本和面积。

xieyang__

ghslfgkkl88 发表于 2020-7-19 10:39
是外面用三极管的那种吧？那种会导致速率不高，高了不稳定，好一点的需要用逻辑门搭建，但没见有人这么多 ...

是用三极管的那种。朋友说115200稳定运行，没有问题

木兰花

eric2013 发表于 2020-7-18 16:20
这个是你们的程序架构设计有问题导致的。
中断里面接收到最后一个数据后，下次发送才开启的TX的。

硬汉哥我的意思是：默认一直是接收，但是你发数前是要切换到发送，这个rx到tx间切换是要加入延时的，我试过不加是不行的，以前在lpc1768上不加似乎没事，但是现在stm32上不加会丢数，
程序如下：

1. void USART_SendString(uint8_t *Data)
   
2. {
   
3.   uint8_t *pBuf = Data;
   
4. 
   
5.   Enable_485Tx;//使能485发送
   
6.   
   
7.   delay_us(10);//---------------这个延时无法去掉，去掉后会有丢数
   
8. 
   
9.   while (*pBuf)
   
10.   {
    
11.     USART1->DR = ((*pBuf) & (uint16_t)0x01FF);
    
12.     pBuf++;
    
13.     while (!(USART1->SR & 0x0080));
    
14.   }
    
15.   while (!(USART1->SR & 0x0040));  //等待TC置位
    
16.   Enable_485Rx;//默认接收
    
17. }

复制代码

eric2013

木兰花 发表于 2020-7-20 11:37
硬汉哥我的意思是：默认一直是接收，但是你发数前是要切换到发送，这个rx到tx间切换是要加入延时的，我试 ...

你的工程或者你设计的板子确实是有问题，方便的话使用我们的bsp_uart_fifo.C测测，无此问题。

木兰花

eric2013 发表于 2020-7-20 11:43
你的工程或者你设计的板子确实是有问题，方便的话使用我们的bsp_uart_fifo.C测测，无此问题。

嗯，下次试试。
以前用lpc1768+光耦+max485芯片是没有这个问题的，现在用的stm32+ADM2483一直有这个延时问题。

he2002512

DMA发送不是更方便吗？HAL库发送完回调里面切为接收。

eric2013

he2002512 发表于 2020-7-30 13:49
DMA发送不是更方便吗？HAL库发送完回调里面切为接收。

可以，注意，务必是要等TC完成才可以