|
一、串口引脚
1 DCD 载波检测
2 RXD Receive Data 接收数据
3 TXD Transmit Data 发送数据
4 DTR Data Terminal Ready 数据终端准备
5 GND System Ground 接地
6 DSR Data Set Ready 数据准备完成
7 RTS Request to Send 请求发送
8 CTS Clear to Send 清除发送
9 RI Ring Indicator 振铃提示
RS232标准
DB9只有9根线，遵循RS232标准。定义如下：
DTR,DSR------DTE设备准备好/DCE设备准备好。主流控信号。
RTS,CTS------请求发送/清除发送。用于半双工时，收发切换。属于辅助流控信号。半双工的意思是说，发的时候不收，收的时候不发。那么怎么区分收发呢？缺省时是DCE向DTE发送数据，当DTE决定向DCE发数据时，先有效RTS，表示DTE希望向DCE发送，一般DCE不能马上转换收发状态，DTE就通过监测CTS是否有效来判断可否发送，这样避免了DTE在DCE未准备好时发送所导致的数据丢失。
全双工时，这两个信号一直有效即可。
当前默认标准
自从贺氏(Hayes)公司推出了聪明猫(SmartModem)，他们制定的MODEM接口就成了业界标准，自此以后，所有公司制造的兼容猫都符合贺氏标准(连AT指令也兼容，大家一起抄他呗)。
细观贺氏制定的MODEM串口，与RS232标准大不相同。DTR在整个通信过程中一直保持有效，DSR在MODEM上电后/可以拨号前有效(取决于软件对DSR的理解)，在通信过程的任意时刻，只要DTR/DSR无效，通信过程立即终止。在某种意义上，这也可以算是流控，但肯定不是RS232所指的那种主流控。如果拘泥于RS232，你是不会理解DTR和DSR的用途的。
贺氏不但改了DTR和DSR，竟然连RTS和CTS的涵义也重新定义了。因此，RTS和CTS已经不具有最开始的意义了。从字面理解RTS和CTS，是用于半双工通信的，当DTE想从收模式改为发模式时，就有效RTS请求发送，DCE收到RTS请求后不能立即完成转换，需要一段时间，然后有效CTS通知DTE：DCE已经转到发模式，DTE可以开始发送了。在全双工时，RTS和CTS都缺省置为有效即可。然而，在贺氏的MODEM串口定义中，RTS和CTS用于硬件流控，和什么劳什子的全双工/半双工一点关系也没有。
注意，硬件流控是靠软件实现的，之所以强调“硬件”二字，仅仅是因为硬件流控提供了用于流量情况指示的硬件连线，并不是说，你只要把线连上，硬件就能自己流控。如果软件不支持，光连上RTS和CTS是没有用的。
RTS和CTS硬件流控的软件算法如下：(RTS有效表示PC机可以收，CTS有效表示MODEM可以收，这两个信号互相独立，分别指示一个方向的流量情况。)
PC端处理：
发. 当 发现（不一定及时发现） CTS (-3v to -15v)无效时，停止发送,当 发现（不一定及时发现） CTS (3v to 15v)有效时，恢复发送；
当接收buffers中的bytes<M 时，给 RTS 有效信号（+3v to +15v),
当接收buffers中的bytes>N 时，给 RTS 无效信号（-3v to -15v);
MODEM端处理：
同上，但RTS与CTS交换
二、流控说明
.流控制在串行通讯中的作用
解决丢失数据的问题
.硬件流控制
硬件流控制常用的有RTS/CTS（请求发送/清除发送）流控制和DTR/DSR（数据终端就绪/数据设置就绪）流控制
.软件流控制
一般通过XON/XOFF来实现软件流控制
三、有关有关硬件流控与软件流控
硬件流控与软件流控都是采用流量控制的原理进行工作，只是采用的信号不同而乙。硬件流控时，计算机通过置RST信号为低来停止MODEM传输，置为高时恢复传输；MODEM通过RST为低来暂停计算机的发送，置为高时恢复发送。软件流控不使用RST和CTS信号，而是靠发送特殊的字符XOFF来停止对方的发送，发送XON来恢复对方的发送，计算机接收时，流控信号XON/XOFF字符从TD线发至MODEM；当MODEM接收时，XON/XOFF字符从RD线发至计算机。软件流控不适合于用来传输二进制文件，因为它会把文件中的数据误认为是流控信号。一般情况下，应采用硬件流控。
|
转自： http://renyan.spaces.eepw.com.cn/articles/trackback/item/84498