19,502
社区成员
发帖
与我相关
我的任务
分享为何会出现这种变态的485设计? (需要用GPIO来控制收发)
大家好!
为何会出现需要用GPIO来控制485收发这种变态的设计?
难道别人写个串口程序, 还要去控制一下GPIO, 这样设计通用性不强啊.
这种设计有什么用途?
悲剧的是, 我们公司以前设计的就是这样的.
为何会出现需要用GPIO来控制485收发这种变态的设计?
难道别人写个串口程序, 还要去控制一下GPIO, 这样设计通用性不强啊.
这种设计有什么用途?
悲剧的是, 我们公司以前设计的就是这样的.
...全文
请发表友善的回复…
发表回复
fanrusen 2014-05-11
- 打赏
- 举报
好贴，赞一个，good！
harktrip 2011-09-09
- 打赏
- 举报
[Quote=引用 23 楼 wvw 的回复:]
引用 22 楼 harktrip 的回复:
怎麼這個會是問題???
485本來就是需要個控制發送和接收!!!
做個啥自動判斷--->這是最不入流的,大學生為了展現自己的技術而做的設計!
各位還是學生嗎?產品要不要量產?要不要賣人的?
-_-
怎么能这么说? 下面这种工业设计挺多的:
使用工控机, 安装XPE, 然后接 有源232/485转换器, 下面接485设备.
……
[/Quote]
這就是一般學生一知半解的地方了
那些轉換器,一樣有切換的功能.
是靠原本全232中的CTS線作為切換
引用 22 楼 harktrip 的回复:
怎麼這個會是問題???
485本來就是需要個控制發送和接收!!!
做個啥自動判斷--->這是最不入流的,大學生為了展現自己的技術而做的設計!
各位還是學生嗎?產品要不要量產?要不要賣人的?
-_-
怎么能这么说? 下面这种工业设计挺多的:
使用工控机, 安装XPE, 然后接 有源232/485转换器, 下面接485设备.
……
[/Quote]
這就是一般學生一知半解的地方了
那些轉換器,一樣有切換的功能.
是靠原本全232中的CTS線作為切換
WvW 2011-09-08
- 打赏
- 举报
dddddddddddddddddddddddddd
bjtea 2011-09-08
- 打赏
- 举报
1）以前的485芯片，例如75176，RS485，MAX485，都是需要用I/O口来切换；
2）也有人自己搞个充放电的延时电路，当CPU的TXD持续为高之后，自动切换。为了怕误动作（还要照顾低波特率情况），设置的延时较长，所以，影响了对立即返回信号的接收。正如大家抱怨的那样，很不靠谱；
3）看了一下MAX13487器件手册（出版日期是2007年，所以应是新产品），发现该芯片对485的电路做了改造，A线上接上拉电阻，B线上接下拉电阻；
4）在此基础上，当485芯片输出高电平时，只要Uab>0.2伏，芯片就自动切换到开路状态，释放了AB线，并通过上拉和下拉电阻来维持线路上的高电平；低电平时情况不变，与原来的485芯片一致；
5）有了3）和4），MAX13487实际上，在每一字节发送后，都会自动切换到输入状态。因此，就不在需要I/O来切换了。
总的感觉，该芯片厂家适应了工程和市场的需求，而且最近10来年在中国发展太迅速了。
2）也有人自己搞个充放电的延时电路，当CPU的TXD持续为高之后，自动切换。为了怕误动作（还要照顾低波特率情况），设置的延时较长，所以，影响了对立即返回信号的接收。正如大家抱怨的那样，很不靠谱；
3）看了一下MAX13487器件手册（出版日期是2007年，所以应是新产品），发现该芯片对485的电路做了改造，A线上接上拉电阻，B线上接下拉电阻；
4）在此基础上，当485芯片输出高电平时，只要Uab>0.2伏，芯片就自动切换到开路状态，释放了AB线，并通过上拉和下拉电阻来维持线路上的高电平；低电平时情况不变，与原来的485芯片一致；
5）有了3）和4），MAX13487实际上，在每一字节发送后，都会自动切换到输入状态。因此，就不在需要I/O来切换了。
总的感觉，该芯片厂家适应了工程和市场的需求，而且最近10来年在中国发展太迅速了。
WvW 2011-09-07
- 打赏
- 举报
[Quote=引用 16 楼 gooogleman 的回复:]
用硬件实现自动的了，看以前别人板卡都是，这样租不合理的。做实验还可以。
我用周立功带隔离的那个。嘿嘿。
[/Quote]
为什么最不合理? 能说说理由吗?
用硬件实现自动的了，看以前别人板卡都是，这样租不合理的。做实验还可以。
我用周立功带隔离的那个。嘿嘿。
[/Quote]
为什么最不合理? 能说说理由吗?
WvW 2011-09-07
- 打赏
- 举报
[Quote=引用 22 楼 harktrip 的回复:]
怎麼這個會是問題???
485本來就是需要個控制發送和接收!!!
做個啥自動判斷--->這是最不入流的,大學生為了展現自己的技術而做的設計!
各位還是學生嗎?產品要不要量產?要不要賣人的?
[/Quote]
-_-
怎么能这么说? 下面这种工业设计挺多的:
使用工控机, 安装XPE, 然后接 有源232/485转换器, 下面接485设备.
-这种系统里面, 哪里会有手动控制串口的收发? 不都是转换器在那里转换 收发, 放到系统缓冲队列里面去. 这些系统也很稳定 实时啊?
嵌入式系统也一样吧
怎麼這個會是問題???
485本來就是需要個控制發送和接收!!!
做個啥自動判斷--->這是最不入流的,大學生為了展現自己的技術而做的設計!
各位還是學生嗎?產品要不要量產?要不要賣人的?
[/Quote]
-_-
怎么能这么说? 下面这种工业设计挺多的:
使用工控机, 安装XPE, 然后接 有源232/485转换器, 下面接485设备.
-这种系统里面, 哪里会有手动控制串口的收发? 不都是转换器在那里转换 收发, 放到系统缓冲队列里面去. 这些系统也很稳定 实时啊?
嵌入式系统也一样吧
harktrip 2011-09-07
- 打赏
- 举报
怎麼這個會是問題???
485本來就是需要個控制發送和接收!!!
做個啥自動判斷--->這是最不入流的,大學生為了展現自己的技術而做的設計!
各位還是學生嗎?產品要不要量產?要不要賣人的?
woshi_ziyu 2011-09-06
- 打赏
- 举报
[Quote=引用 18 楼 ttapi 的回复:]
显然寄希望于自动换向的没有吃过工业现场的亏，呵呵
[/Quote]
不懂
显然寄希望于自动换向的没有吃过工业现场的亏，呵呵
[/Quote]
不懂
WvW 2011-09-06
- 打赏
- 举报
[Quote=引用 18 楼 ttapi 的回复:]
显然寄希望于自动换向的没有吃过工业现场的亏，呵呵
[/Quote]
此话怎讲？ 我用在工业里面， 每隔10毫秒， 发送一次查询， 好像也挺正常。
照你的意思，别人的工控机，232-》232、485转换器=》线缆=》现场设备
这种方式就会很吃亏？
显然寄希望于自动换向的没有吃过工业现场的亏，呵呵
[/Quote]
此话怎讲？ 我用在工业里面， 每隔10毫秒， 发送一次查询， 好像也挺正常。
照你的意思，别人的工控机，232-》232、485转换器=》线缆=》现场设备
这种方式就会很吃亏？
ttapi 2011-09-05
- 打赏
- 举报
显然寄希望于自动换向的没有吃过工业现场的亏，呵呵
arm7000 2011-09-02
- 打赏
- 举报
这是本身485协议决定的，你看485芯片，有收发的引脚，自然要有GPIO口来控制,你也可以选择象MAX13487这样的芯片，自动切换收发方向。至于通用性的问题，485用在单片机上，可以直接用IO口来控制。如果用在wince上，收发的切换就要由底层驱动来作，默认在接收状态，要发送时才进入发送状态，发送完改为接收状态。上层的应用软件不会有什么区别，还是象串口一样去使用。由于是单工操作，必须靠协议保证不会出现多个同时发的冲突现象。
很多wince板，在使用485时，如果使用普通485芯片就要改串口驱动，如果使用max13487芯片，串口的驱动就不用改。
很多wince板，在使用485时，如果使用普通485芯片就要改串口驱动，如果使用max13487芯片，串口的驱动就不用改。
bjtea 2011-09-02
- 打赏
- 举报
为了进行切换，需要两个条件：1）知道是最后字节；2）最后字节已经移位出去。
用I/O实现切换（可以底层来实现），当然是最快的；
因为，只有用户才知道是最后字节，并且在最后一字发送出去之后，让底层根据TX中断，进行切换；
用I/O实现切换（可以底层来实现），当然是最快的；
因为，只有用户才知道是最后字节，并且在最后一字发送出去之后，让底层根据TX中断，进行切换；
gooogleman 2011-09-02
- 打赏
- 举报
用硬件实现自动的了，看以前别人板卡都是，这样租不合理的。做实验还可以。
我用周立功带隔离的那个。嘿嘿。
我用周立功带隔离的那个。嘿嘿。
ttapi 2011-09-02
- 打赏
- 举报
显然手动控制的更可靠。
RS485上常用的MODBUS协议，在数据帧间都会有个T3.5的时间间隔，足够你换向的。
RS485上常用的MODBUS协议，在数据帧间都会有个T3.5的时间间隔，足够你换向的。
ffeige1984 2011-09-01
- 打赏
- 举报
COM1 COM2 应该带有硬件流控功能 所以可以自己识别数据发送和接收，COM3 没用硬件流控功能 所以只能用IO来控制数据发送和接收。
WvW 2011-09-01
- 打赏
- 举报
[Quote=引用 10 楼 northcan 的回复:]
检测电路是需要代价吧，只做1,2，留下3，为了节省成本？
这不需要增加什么成本吧，据说用个 NOR 就可以识别了。。。
原因不是节省成本，自动切换485状态的这种方式，不知道楼主经过长时间的测试没有。
这个也是存在问题的。
除了我在9楼说的那种情况（“发送之后必须立即转为接收，时间稍有延迟，就有数据丢失”）
之外。其实用GPIO控制485收发更加可靠。
自动切换485的那……
[/Quote]
自动检测电路我倒没发现有什么问题。检测电路 应该会比 用GPIO控制要快速， 问题要少的多吧。
检测电路是需要代价吧，只做1,2，留下3，为了节省成本？
这不需要增加什么成本吧，据说用个 NOR 就可以识别了。。。
原因不是节省成本，自动切换485状态的这种方式，不知道楼主经过长时间的测试没有。
这个也是存在问题的。
除了我在9楼说的那种情况（“发送之后必须立即转为接收，时间稍有延迟，就有数据丢失”）
之外。其实用GPIO控制485收发更加可靠。
自动切换485的那……
[/Quote]
自动检测电路我倒没发现有什么问题。检测电路 应该会比 用GPIO控制要快速， 问题要少的多吧。
WvW 2011-09-01
- 打赏
- 举报
[Quote=引用 9 楼 northcan 的回复:]
稍微改一下电路，485就可以自动切换收发状态了。
楼主公司以前的用一个GPIO来控制485收发状态
这种方式会给应用层程序员编写程序带来麻烦
首先不说这个485收发状态需要一个函数接口来控制GPIO切换不说。
这种做法是有延时的。
有的时候有这样一种需求，比如你们公司的WinCE设备需要外接一个485设备。
比如某某仪表。而两边的应用程序需要一个协议的握手信号。
也就是说WinCE……
[/Quote]
为何这么ARM 厂商， 都有这种设计呢？ 是不是大家一开始抄袭， 抄袭一个 错误的东西， 然后变成流行了？
稍微改一下电路，485就可以自动切换收发状态了。
楼主公司以前的用一个GPIO来控制485收发状态
这种方式会给应用层程序员编写程序带来麻烦
首先不说这个485收发状态需要一个函数接口来控制GPIO切换不说。
这种做法是有延时的。
有的时候有这样一种需求，比如你们公司的WinCE设备需要外接一个485设备。
比如某某仪表。而两边的应用程序需要一个协议的握手信号。
也就是说WinCE……
[/Quote]
为何这么ARM 厂商， 都有这种设计呢？ 是不是大家一开始抄袭， 抄袭一个 错误的东西， 然后变成流行了？
northcan 2011-09-01
- 打赏
- 举报
检测电路是需要代价吧，只做1,2，留下3，为了节省成本？
这不需要增加什么成本吧，据说用个 NOR 就可以识别了。。。
原因不是节省成本，自动切换485状态的这种方式，不知道楼主经过长时间的测试没有。
这个也是存在问题的。
除了我在9楼说的那种情况（“发送之后必须立即转为接收，时间稍有延迟，就有数据丢失”）
之外。其实用GPIO控制485收发更加可靠。
自动切换485的那种电路方式不是很稳定。以前我们很多客户反应过这个问题。
相关电路原理也很简单，网上很多。
所以在很多情况下，GPIO控制收发的这种方式如果可以满足要求的话，还是可以用的。
“我用的板子就是这样的, COM1 COM2的485都是这样, 可为何COM3的485要设计成手动切换的”
这个估计是公司最后采用的中庸之策。
这不需要增加什么成本吧，据说用个 NOR 就可以识别了。。。
原因不是节省成本，自动切换485状态的这种方式，不知道楼主经过长时间的测试没有。
这个也是存在问题的。
除了我在9楼说的那种情况（“发送之后必须立即转为接收，时间稍有延迟，就有数据丢失”）
之外。其实用GPIO控制485收发更加可靠。
自动切换485的那种电路方式不是很稳定。以前我们很多客户反应过这个问题。
相关电路原理也很简单，网上很多。
所以在很多情况下，GPIO控制收发的这种方式如果可以满足要求的话，还是可以用的。
“我用的板子就是这样的, COM1 COM2的485都是这样, 可为何COM3的485要设计成手动切换的”
这个估计是公司最后采用的中庸之策。
northcan 2011-09-01
- 打赏
- 举报
稍微改一下电路，485就可以自动切换收发状态了。
楼主公司以前的用一个GPIO来控制485收发状态
这种方式会给应用层程序员编写程序带来麻烦
首先不说这个485收发状态需要一个函数接口来控制GPIO切换不说。
这种做法是有延时的。
有的时候有这样一种需求，比如你们公司的WinCE设备需要外接一个485设备。
比如某某仪表。而两边的应用程序需要一个协议的握手信号。
也就是说WinCE应用程序发送一个指令给485仪表，而仪表马上返回一个回复数据。
这个时候WinCE要立即接收到仪表返回来的数据，以确定连接是否畅通。
但问题就出在WinCE应用程序在发送数据之后，需要调用一个接口函数，通过底层的GPIO切换收发状态。
这个时间就完蛋了。等状态切换之后，仪表返回来的数据已经接收不全了。
楼主公司以前的用一个GPIO来控制485收发状态
这种方式会给应用层程序员编写程序带来麻烦
首先不说这个485收发状态需要一个函数接口来控制GPIO切换不说。
这种做法是有延时的。
有的时候有这样一种需求，比如你们公司的WinCE设备需要外接一个485设备。
比如某某仪表。而两边的应用程序需要一个协议的握手信号。
也就是说WinCE应用程序发送一个指令给485仪表，而仪表马上返回一个回复数据。
这个时候WinCE要立即接收到仪表返回来的数据，以确定连接是否畅通。
但问题就出在WinCE应用程序在发送数据之后，需要调用一个接口函数，通过底层的GPIO切换收发状态。
这个时间就完蛋了。等状态切换之后，仪表返回来的数据已经接收不全了。
WvW 2011-09-01
- 打赏
- 举报
upup
加载更多回复（7）
