为何会出现需要用GPIO来控制485收发这种变态的设计?
难道别人写个串口程序, 还要去控制一下GPIO, 这样设计通用性不强啊.
这种设计有什么用途?
悲剧的是, 我们公司以前设计的就是这样的.
485是多机并接在一起的差分通讯线，每台设备的485只有两种状态，发送或接收（即输出或输入）；
485线上，每次只允许有一台机器处于发送状态，否则就会冲突；
为了使485分别处于两种状态上，必须使用一条I/O线来控制切换。
这点与232不同，232有输入、输出两条线；485只有一对差分线。
1）作为对比，因特网不需要，但它有两对差分线。485减少了一半通讯线，代价就是要收、发切换；
2）还有一点是，芯片本身支持的是UART，我们用UART转485，而UART不需要I/O控制。所以，485就需要专门伺候一条I/O线了。 稍微改一下电路，485就可以自动切换收发状态了。
楼主公司以前的用一个GPIO来控制485收发状态
这种方式会给应用层程序员编写程序带来麻烦
首先不说这个485收发状态需要一个函数接口来控制GPIO切换不说。
这种做法是有延时的。
有的时候有这样一种需求，比如你们公司的WinCE设备需要外接一个485设备。
比如某某仪表。而两边的应用程序需要一个协议的握手信号。
也就是说WinCE应用程序发送一个指令给485仪表，而仪表马上返回一个回复数据。
这个时候WinCE要立即接收到仪表返回来的数据，以确定连接是否畅通。
但问题就出在WinCE应用程序在发送数据之后，需要调用一个接口函数，通过底层的GPIO切换收发状态。
这个时间就完蛋了。等状态切换之后，仪表返回来的数据已经接收不全了。