大家好!
为何会出现需要用GPIO来控制485收发这种变态的设计?
难道别人写个串口程序, 还要去控制一下GPIO, 这样设计通用性不强啊.
这种设计有什么用途?
悲剧的是, 我们公司以前设计的就是这样的.
------解决方案--------------------
稍微改一下电路，485就可以自动切换收发状态了。
楼主公司以前的用一个GPIO来控制485收发状态
这种方式会给应用层程序员编写程序带来麻烦
首先不说这个485收发状态需要一个函数接口来控制GPIO切换不说。
这种做法是有延时的。
有的时候有这样一种需求，比如你们公司的WinCE设备需要外接一个485设备。
比如某某仪表。而两边的应用程序需要一个协议的握手信号。
也就是说WinCE应用程序发送一个指令给485仪表，而仪表马上返回一个回复数据。
这个时候WinCE要立即接收到仪表返回来的数据，以确定连接是否畅通。
但问题就出在WinCE应用程序在发送数据之后，需要调用一个接口函数，通过底层的GPIO切换收发状态。
这个时间就完蛋了。等状态切换之后，仪表返回来的数据已经接收不全了。
------解决方案--------------------
这是本身485协议决定的，你看485芯片，有收发的引脚，自然要有GPIO口来控制,你也可以选择象MAX13487这样的芯片，自动切换收发方向。至于通用性的问题，485用在单片机上，可以直接用IO口来控制。如果用在wince上，收发的切换就要由底层驱动来作，默认在接收状态，要发送时才进入发送状态，发送完改为接收状态。上层的应用软件不会有什么区别，还是象串口一样去使用。由于是单工操作，必须靠协议保证不会出现多个同时发的冲突现象。
很多wince板，在使用485时，如果使用普通485芯片就要改串口驱动，如果使用max13487芯片，串口的驱动就不用改。
------解决方案--------------------
为了进行切换，需要两个条件：1）知道是最后字节；2）最后字节已经移位出去。
用I/O实现切换（可以底层来实现），当然是最快的；
因为，只有用户才知道是最后字节，并且在最后一字发送出去之后，让底层根据TX中断，进行切换；