一个485串口的读写操作可不可以同时进行？
即：
任务甲使用2脚：发送数据；
与此同时：
任务乙使用3脚：接收数据；
可以吗？
21 个解决方案
#1
没人愿意回答吗？
#2
个人认为：不可以。
首先，windows是不会让两个进程同时占用同一个com口的。
其次，可能是这样，发送数据，在底层上不单单是发送，可能还需要握手、同步等双向通讯。
首先，windows是不会让两个进程同时占用同一个com口的。
其次，可能是这样，发送数据，在底层上不单单是发送，可能还需要握手、同步等双向通讯。
#3
哦，有理
#4
半双工的吧，485？？
我也是菜鸟，请指教
我也是菜鸟，请指教
#5
是半双工
#6
在window下com是当作一个文件打开的，只能有一个进程控制，但如果你自己写一个类似代理的进程来管理com，那么你其他的任务可以通过这个代理实现com的共享。
#7
谢谢！
#8
485是半工的，不行，422可以。进程不行，线程就不可以吗？当然可以，俺做过，422可以，全工。
#9
我的意思就是同一个进程的不同线程可不可以同时对485串口进行读写？
线程甲占用2脚，线程乙占用3脚。
线程甲占用2脚，线程乙占用3脚。
#10
采用同一进程的不同线成同时对485读写，其实也并不是完整意义上的全双工，因为毕竟是线程是分时工作的，当然，如果你是用的双CPU系统，那又另当别论。
你指的同时工作，是指一个线程读，一个线程写么？这是完全可以做到的。
如果你是指两个线程都要既要读又要写，这可能会存在不同步的问题，应该适当的加入一些同步控制。
你指的同时工作，是指一个线程读，一个线程写么？这是完全可以做到的。
如果你是指两个线程都要既要读又要写，这可能会存在不同步的问题，应该适当的加入一些同步控制。
#11
<<你指的同时工作，是指一个线程读，一个线程写么？这是完全可以做到的。
正是这样的，而且非阻塞通信不怎么占CPU呀。
正是这样的，而且非阻塞通信不怎么占CPU呀。
#12
485完成不了“同时”的读写，但是422就可以了。
关于线程的问题，其实CPU分时的周期很快，而IO设备毕竟是慢得多，而且慢的不是一点半点，也就是说，多个线程对一个IO设备操作完全是真正的物理上的并行。
另外，对422写时，一般要先给个电平，然后再写，读的时候也是，先识别到一个电平，再读，它们持续的时间很长，线程就是循环若干次，都可以啊。
也就是说：在422下，能实现物理上真正的全双工。
关于线程的问题，其实CPU分时的周期很快，而IO设备毕竟是慢得多，而且慢的不是一点半点，也就是说，多个线程对一个IO设备操作完全是真正的物理上的并行。
另外，对422写时，一般要先给个电平，然后再写，读的时候也是，先识别到一个电平，再读，它们持续的时间很长，线程就是循环若干次，都可以啊。
也就是说：在422下，能实现物理上真正的全双工。
#13
在485下就不行了，因为协议规程不允许，即使看起来象，也是“象”，不是物理上的并发操作。
#14
是不是232就可以？
#15
232全双工，485半双工
#16
232、422可以，485不可以。
#17
我认为youwill() 说得有道理，能不能再仔细的把想法说一说呢。
#18
232全双工，485半双工 ,收发数据要设置DTR握手
#19
很有收获！
看样子，最好是加个232-485 转换了
看样子，最好是加个232-485 转换了
#20
我觉得上次我对问题理解有误，如果问题是从硬件层面谈，那么如果物理协议上485是半双工，收发是不能同时的。从软件层面，如果如我上次提到的作一个软件串口代理，那么软件上是可以不用考虑同时收发会冲突的问题了，代理程序来考虑收发的调度。
#21
嗯，很有收获。
#1
没人愿意回答吗？
#2
个人认为：不可以。
首先，windows是不会让两个进程同时占用同一个com口的。
其次，可能是这样，发送数据，在底层上不单单是发送，可能还需要握手、同步等双向通讯。
首先，windows是不会让两个进程同时占用同一个com口的。
其次，可能是这样，发送数据，在底层上不单单是发送，可能还需要握手、同步等双向通讯。
#3
哦，有理
#4
半双工的吧，485？？
我也是菜鸟，请指教
我也是菜鸟，请指教
#5
是半双工
#6
在window下com是当作一个文件打开的，只能有一个进程控制，但如果你自己写一个类似代理的进程来管理com，那么你其他的任务可以通过这个代理实现com的共享。
#7
谢谢！
#8
485是半工的，不行，422可以。进程不行，线程就不可以吗？当然可以，俺做过，422可以，全工。
#9
我的意思就是同一个进程的不同线程可不可以同时对485串口进行读写？
线程甲占用2脚，线程乙占用3脚。
线程甲占用2脚，线程乙占用3脚。
#10
采用同一进程的不同线成同时对485读写，其实也并不是完整意义上的全双工，因为毕竟是线程是分时工作的，当然，如果你是用的双CPU系统，那又另当别论。
你指的同时工作，是指一个线程读，一个线程写么？这是完全可以做到的。
如果你是指两个线程都要既要读又要写，这可能会存在不同步的问题，应该适当的加入一些同步控制。
你指的同时工作，是指一个线程读，一个线程写么？这是完全可以做到的。
如果你是指两个线程都要既要读又要写，这可能会存在不同步的问题，应该适当的加入一些同步控制。
#11
<<你指的同时工作，是指一个线程读，一个线程写么？这是完全可以做到的。
正是这样的，而且非阻塞通信不怎么占CPU呀。
正是这样的，而且非阻塞通信不怎么占CPU呀。
#12
485完成不了“同时”的读写，但是422就可以了。
关于线程的问题，其实CPU分时的周期很快，而IO设备毕竟是慢得多，而且慢的不是一点半点，也就是说，多个线程对一个IO设备操作完全是真正的物理上的并行。
另外，对422写时，一般要先给个电平，然后再写，读的时候也是，先识别到一个电平，再读，它们持续的时间很长，线程就是循环若干次，都可以啊。
也就是说：在422下，能实现物理上真正的全双工。
关于线程的问题，其实CPU分时的周期很快，而IO设备毕竟是慢得多，而且慢的不是一点半点，也就是说，多个线程对一个IO设备操作完全是真正的物理上的并行。
另外，对422写时，一般要先给个电平，然后再写，读的时候也是，先识别到一个电平，再读，它们持续的时间很长，线程就是循环若干次，都可以啊。
也就是说：在422下，能实现物理上真正的全双工。
#13
在485下就不行了，因为协议规程不允许，即使看起来象，也是“象”，不是物理上的并发操作。
#14
是不是232就可以？
#15
232全双工，485半双工
#16
232、422可以，485不可以。
#17
我认为youwill() 说得有道理，能不能再仔细的把想法说一说呢。
#18
232全双工，485半双工 ,收发数据要设置DTR握手
#19
很有收获！
看样子，最好是加个232-485 转换了
看样子，最好是加个232-485 转换了
#20
我觉得上次我对问题理解有误，如果问题是从硬件层面谈，那么如果物理协议上485是半双工，收发是不能同时的。从软件层面，如果如我上次提到的作一个软件串口代理，那么软件上是可以不用考虑同时收发会冲突的问题了，代理程序来考虑收发的调度。
#21
嗯，很有收获。