社区导航

 
快捷导航
  • 首页
  • 论坛
  • 查看新帖
  • 最新回复
  • 社区活动
  • 联系管理员
  • 消灭零回复
  • E金币兑换
  • 干货
搜索
查看: 694|回复: 8

[原创] 关于485自收发电路新的思考

[复制链接]

589

TA的帖子

0

TA的资源

版主

Rank: 6Rank: 6

发表于 2018-2-9 23:42:06 | 显示全部楼层 |阅读模式
之前有说要发几篇关于HelperA64核心板电路设计的心路历程,但是因为我这单线程大脑,一直提不起心情发贴,这次借过年回家工作的事全部放下之际,补几篇上来,今天先分享一个2017年度原创而且实用的485自收发电路,此电路应该算是在传统自收发485电路上的微创新。

关于485的收发切换电路,在以前的单片机时代,由于没有多少执行延迟,大家对自收发电路需求不是非常迫切。如今,安卓、linux当道,非自收发响应速度太慢,485自收发就变得非常重要了。传统的自收发电路如下(网上随便找的):

以TX的反向作为485芯片的收发切换,当处于接收状态时,TX为高电平,由于三极管的反向作用,RE被拉低,此时为接收状态,没有任何问题,当处于发送状态时,TX分高电平时间和低电平时间,其中,起始位为低电平,此时,485芯片立即切换为发送状态,这也没有问题,当发送的数据里有高电平位,TX为高时,485芯片会切换为接收状态,此时,485总线不会再被芯片驱动拉高,变成自R4,R6电阻拉高拉低,以有效实现驱动总线的目的。
该电路的主要缺点:响应速度太慢,波特率一般达到19200就到头了,原因是电阻不能太小(太小了功耗会很大,通常以500R-1K为宜),驱动能力不会太强,同时,由于电路上的寄生电容,导致电路响应时间比较慢,方波可能会出现尖峰。
另外还有一个缺点也是由于上下拉电路不能太小,驱动能力相对较弱,不能带标准485协议规定的那么多设备。


下面我介绍一种基于以上电路的改进:
485自收发.png
      此电路再传统电路的基础上,增加了TX从低电平变成高电平时,485芯片RE端的延时,而TX从高电平变低电平时,几乎没有延时。
原理:当TXD为低电平时,9012马上导通,由于是直接3.3V供电,3485的RE会直接被拉到高电平,转成发送当TXD为高电平时,9012关断,RE从原来的高电平,缓慢放电,变成低电平,转成接收,理论上,只要有一点点延时,保证TXD先驱动总线,再转成接收就可以了,同时延时也不能过大,超过1bit可能会导致从端发数据时主端还处于发送状态,以115200的波特率计算,1bit为8.7us,15P的电容(实际电路中,要考虑485接收芯片的输入阻抗,电容会大很多,可以在1000P-10000P之间调节,建议用示波器实测大约9us的延时,取最佳电容值)与2.1K的电阻,放电周期13us,考虑误差,周期应该在6-20us之间,达到最大波特率的1个bit,就能满足要求了,低速的时候,更是没关系。
      此电路有效的解决了响应速度的问题,跑到115200波特率毫无压力,但还是没有解决驱动能力的问题,同样不能带太多的设备,实测,30个从设备通讯正常,如果有网友解决了驱动能力的问题,请不吝指教。
      注:此电路在我的项目中小批量使用,未大批量验证,暂时没有发现问题,但不保证一定没有问题,欢迎坛友指证,另外,在我自己使用之前,没有看到别人用过,暂时定义为原创,如果有发现之前已经有人这样做过了,请联系我。

此内容由EEWORLD论坛网友spacexplorer原创,如需转载或用于商业用途需征得作者同意并注明出处



My dreams will go on...
http://www.jyxtec.com


回复

使用道具 举报

587

TA的帖子

0

TA的资源

一粒金砂(中级)

Rank: 2

发表于 2018-2-25 16:50:07 | 显示全部楼层
没太看懂 发送数据不是高低电平都有吗

点评

是的,高低电平都有,当为高电平的时候,485芯片切换为接收状态,这时候通过外部上拉电阻实现保持总线的高电平特性,而不是485芯片驱动成的高电平,当为低电平状态的时候,485芯片会切换为发送状态,此时总线被485芯  详情 回复 发表于 2018-2-25 16:55


回复

使用道具 举报

589

TA的帖子

0

TA的资源

版主

Rank: 6Rank: 6

 楼主| 发表于 2018-2-25 16:55:54 | 显示全部楼层
gurou1 发表于 2018-2-25 16:50
没太看懂 发送数据不是高低电平都有吗

是的,高低电平都有,当为高电平的时候,485芯片切换为接收状态,这时候通过外部上拉电阻实现保持总线的高电平特性,而不是485芯片驱动成的高电平,当为低电平状态的时候,485芯片会切换为发送状态,此时总线被485芯片驱动。只要是异步串口,都有起始位和停止位,这里算是巧妙的利用了这两个位。

要看懂这个原理,需要深入了解异步串口和485总线的通讯原理,是不那么好理解。

点评

发送的时候,为0即低电平,DE为高,好理解;为1的时候,DE为低,发送不是禁止了吗,RE/为高,接收使能了啊,那还能继续发数据?  详情 回复 发表于 2018-2-25 17:05
My dreams will go on...
http://www.jyxtec.com


回复

使用道具 举报

587

TA的帖子

0

TA的资源

一粒金砂(中级)

Rank: 2

发表于 2018-2-25 17:05:46 | 显示全部楼层
spacexplorer 发表于 2018-2-25 16:55
是的,高低电平都有,当为高电平的时候,485芯片切换为接收状态,这时候通过外部上拉电阻实现保持总线的 ...

发送的时候,为0即低电平,DE为高,好理解;为1的时候,DE为低,发送不是禁止了吗,RE/为高,接收使能了啊,那还能继续发数据?

点评

当为1的时候,的确发送禁止了,但是由于上拉电阻的作用,485总线上还会被拉为高电平,对于接收端,由于之前已经收到了低电平的起始位的作用,还会继续接收完整的1个字节,直到收到可靠的停止位为止。这样,即使485芯  详情 回复 发表于 2018-2-25 17:09


回复

使用道具 举报

589

TA的帖子

0

TA的资源

版主

Rank: 6Rank: 6

 楼主| 发表于 2018-2-25 17:09:56 | 显示全部楼层
gurou1 发表于 2018-2-25 17:05
发送的时候,为0即低电平,DE为高,好理解;为1的时候,DE为低,发送不是禁止了吗,RE/为高,接收使能了 ...

当为1的时候,的确发送禁止了,但是由于上拉电阻的作用,485总线上还会被拉为高电平,对于接收端,由于之前已经收到了低电平的起始位的作用,还会继续接收完整的1个字节,直到收到可靠的停止位为止。这样,即使485芯片的发送禁止了,实际上是485芯片不驱动总线了,但是接收端收到的数据还是正确的。
My dreams will go on...
http://www.jyxtec.com


回复

使用道具 举报

13

TA的帖子

0

TA的资源

一粒金砂(中级)

Rank: 2

发表于 2018-3-5 09:18:51 | 显示全部楼层
如果能找到更好的方法解决驱动的问题就好了

点评

办法是有,但是就复杂了,需要检测波特率,检测起始位,再保持发送状态10个位  详情 回复 发表于 2018-3-6 15:40


回复

使用道具 举报

589

TA的帖子

0

TA的资源

版主

Rank: 6Rank: 6

 楼主| 发表于 2018-3-6 15:40:41 | 显示全部楼层
scxuchenglong 发表于 2018-3-5 09:18
如果能找到更好的方法解决驱动的问题就好了

办法是有,但是就复杂了,需要检测波特率,检测起始位,再保持发送状态10个位
My dreams will go on...
http://www.jyxtec.com


回复

使用道具 举报

68

TA的帖子

0

TA的资源

一粒金砂(中级)

Rank: 2

发表于 2018-3-8 22:59:12 | 显示全部楼层
前年也做了自收发485,跟你前端处理的差不多,一样没问题

点评

是一般没问题,不是一样没问题,从原理上讲,低速是,用老的自收发是可以的,速度快了一般就不行了。  详情 回复 发表于 2018-3-12 08:59
学习永无止境


回复

使用道具 举报

589

TA的帖子

0

TA的资源

版主

Rank: 6Rank: 6

 楼主| 发表于 2018-3-12 08:59:30 | 显示全部楼层
dl265361 发表于 2018-3-8 22:59
前年也做了自收发485,跟你前端处理的差不多,一样没问题

是一般没问题,不是一样没问题,从原理上讲,低速是,用老的自收发是可以的,速度快了一般就不行了。
My dreams will go on...
http://www.jyxtec.com


回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

  • 论坛活动 E手掌握

    扫码关注
    EEWORLD 官方微信

  • EE福利  唾手可得

    扫码关注
    EE福利 唾手可得

小黑屋|手机版|Archiver|电子工程世界 ( 京ICP证 060456

GMT+8, 2018-5-22 04:17 , Processed in 0.248866 second(s), 18 queries , Gzip On, Redis On.

快速回复 返回顶部 返回列表