从老式Modem到现代工控：一文读懂串口DTR/DSR、RTS/CTS的前世今生与避坑指南

从老式Modem到现代工控：串口握手信号的演进与实战指南

上世纪70年代，当第一台电传打字机通过串口连接到大型主机时，工程师们不会想到，他们设计的DTR/DSR、RTS/CTS握手协议会延续半个世纪。今天，在数控机床的车间、医疗监护仪的病房、甚至自动售货机的内部，这些信号仍在默默协调着设备间的对话。本文将带您穿越这段技术史，揭示9针接口背后那些容易被忽视的信号线如何影响现代工业通信。

1. 串口通信的起源与信号演变

1.1 从电传打字机到RS-232标准

1960年代诞生的RS-232标准最初是为连接电传打字机（Teletype）与调制解调器（Modem）设计的。在300波特率的时代，DTR（Data Terminal Ready）和DSR（Data Set Ready）这对信号承担着简单的设备状态通知功能：

• DTR：终端设备（如电传打字机）向Modem宣告"我已通电"
• DSR：Modem回应"我也已就绪"

当时的硬件工程师EIA-232规范中明确要求：

DTR有效（高电平）表示DTE（数据终端设备）已准备好建立连接 DSR有效表示DCE（数据通信设备）已准备好通信

1.2 Modem时代的流量控制进化

随着1200bps及以上速率的Modem普及，RTS（Request To Send）和CTS（Clear To Send）这对信号开始承担更复杂的流量控制任务。典型的工作流程如下：

1. 终端设备检测到需要发送数据时，拉高RTS
2. Modem检测线路状态，若可用则回复CTS
3. 终端在CTS有效期间发送数据
4. 当Modem缓冲区将满时，提前拉低CTS暂停传输

注意：早期实现中，RTS/CTS是半双工通信的切换信号，后来才演变为全双工的流量控制

2. 现代工业场景中的信号应用差异

2.1 医疗设备中的严格握手

在ECG监护仪等医疗设备中，信号完整性至关重要。某品牌监护仪的通信协议明确要求：

2.2 工业PLC的简化处理

现代PLC（如西门子S7-200系列）往往采用更简单的处理方式：

# 典型PLC通信初始化代码 ser = serial.Serial( port='/dev/ttyS0', baudrate=9600, timeout=1, dsrdtr=True, # 自动处理DTR/DSR rtscts=False # 通常禁用硬件流控 )

3. 跨平台开发中的信号处理陷阱

3.1 Windows系统的特殊行为

Windows的串口API存在一些历史遗留行为：

• DTR控制陷阱：调用SetCommState()后必须显式设置DTR状态

// C# 正确配置示例 SerialPort port = new SerialPort("COM1"); port.DtrEnable = true; // 必须单独设置 port.RtsEnable = true; port.Open();

3.2 Linux下的信号默认值差异

在Linux系统中，tty设备的默认信号状态常导致问题：

# 查看当前串口信号状态 stty -F /dev/ttyUSB0 -a | grep -E 'dsr|cts' # 典型输出可能显示： # dsr -dtr dsr 0 # -rtscts

4. 实战避坑指南

4.1 老旧设备对接四步法

1. 物理层确认：用万用表测量信号线电压

   • DTR/RTS应有+3V至+15V（RS-232标准）
   • DSR/CTS应在设备就绪后变为正电压

2. 信号强制方案：

# Python强制信号处理 import serial ser = serial.Serial('/dev/ttyUSB0') ser.dtr = True # 强制DTR高 ser.rts = True # 强制RTS高

3. 逻辑分析仪捕获：使用Saleae逻辑分析仪捕获信号时序

4. 超时重试机制：

// C语言示例 int retry = 0; while (!(inb(port+LSR) & DSR) && retry++ < 10) { delay(100); outb(port+MCR, DTR|RTS); // 重发握手信号 }

4.2 常见设备信号要求速查表