第一章：数字世界的握手——理解串行通信的本质
1.1 串行通信究竟是什么？
我们常常听到一个简化的定义：“一次只传输一个比特的数据”。这个定义是正确的，但缺乏深度。为了真正理解它，让我们构建一个更生动的模型。
想象一条高速公路。一条**并行总线（Parallel Bus）**就像一条有16条车道的高速公路。在一个时钟周期（绿灯亮起），16辆车（代表16个比特）可以同时从A点出发并到达B点。这非常快，但也极其昂贵和复杂——你需要修建和维护16条车道，并确保所有车辆（信号）能完美同步地到达，否则就会造成混乱。在早期，计算机内部的打印机接口就采用了这种方式。
而串行通信（Serial Communication）则像一条只有单车道的乡间小路。车辆（比特）必须排成一列，一辆接一辆地通过。这显然比16车道的高速公路要慢，但它的优势是压倒性的：
- 成本极低：只需要铺设最少的线路（通常是发送、接收和地线三根）。这使得它非常适合长距离传输和连接资源有限的设备。
- 实现简单：无需处理复杂的多路信号同步问题，抗干扰能力也更强。
pyserial所处理的，正是这种“单车道”上的交通规则。它是一种异步串行通信（Asynchronous Serial Communication）。这里的“异步”是关键。与需要一根额外时钟线来同步收发双方的“同步”通信（如SPI, I2C）不同，异步通信没有共享的时钟线。那么，接收方是如何知道一个数据字节从哪里开始，到哪里结束的呢？答案就在于双方事先约定好的一套“交通规则”，这套规则就是我们稍后会深入探讨的波特率、数据位、停止位等参数。
1.2 物理层：连接的基石（RS-232, TTL）
当我们在代码中操作串口时，我们实际上是在控制物理电线上的电压变化。了解这些电压标准至关重要，因为错误的连接可能会永久性地损坏设备。
-
TTL (Transistor-Transistor Logic) Level:
- 这是绝大多数微控制器（如Arduino, ESP32, Raspberry Pi的GPIO）内部使用的逻辑电平。
- 它通常与芯片的供电电压直接相关。常见的有5V TTL和3.3V TTL。
- 逻辑’1’（高电平）: 电压接近供电电压（例如，5V或3.3V）。
- 逻辑’0’（低电平）: 电压接近地（0V）。
- 致命警告：绝对不能将一个5V TTL的发送端（TX）直接连接到一个3.3V设备的接收端（RX）。这相当于将5V的电压强加给一个只能承受3.3V的引脚，很可能会烧毁这个3.3V的芯片。你必须使用一个**电平转换模块（Level Shifter）**来进行适配。
-
RS-232 (Recommended Standard 232):
- 这是计算机上古老的DB9针串口（COM口）所遵循的工业标准。
- 它使用负逻辑和更高的电压来增强长距离传输的抗干扰能力。
- 逻辑’1’（Mark）: 负电压，通常在 -3V 到 -15V 之间。
- 逻辑’0’（Space）: 正电压，通常在 +3V 到 +15V 之间。
- 连接：如果你想让你的电脑（通过USB转RS-232转换器）与一个微控制器（TTL电平）通信，你必须使用一个RS-232到TTL的转换芯片（如MAX232）。直接连接同样会损坏设备。
-
USB转串口（USB-to-Serial Converters）:
在现代计算机上，我们几乎看不到物理的DB9串口。我们使用的是USB转串口模块。这些模块的核心是一个桥接芯片（如FTDI的FT232RL，WCH的CH340/CH341，Silicon Labs的CP2102）。- 作用：这些芯片在USB的一端与电脑对话，模拟出一个传统的COM口；在另一端，它们提供TTL电平的TX和RX引脚，可以直接与微控制器连接。
- 驱动程序：当你第一次插入这些模块时，操作系统需要安装相应的驱动程序。这个驱动程序的作用，就是在操作系统层面创建一个虚拟COM口（Virtual COM Port, VCP）。
pyserial实际上就是通过这个虚拟COM口与设备进行通信的。
1.3 协议层：比特的语言规则
现在我们深入探讨“异步通信”的规则。想象一下，为了在单车道上准确无误地传递一队汽车（一个字节的数据），我们需要约定好几个关键规则：
-
波特率（Baud Rate）:
- 定义：每秒传输的码元（Symbol）数量。在大多数二进制串行通信中，一个码元就代表一个比特，所以波特率可以通俗地理解为每秒传输的比特数。常用值有9600, 19200, 38400, 57600, 115200等。
- 为何必须匹配：这是双方时钟的唯一约定。接收方通过波特率来确定对信号进行采样的频率。例如，在9600波特率下，每个比特的持续时间是
1/9600秒（约104微秒）。接收方会在每个比特周期的中间点进行采样，以判断其是’0’还是’1’。如果发送方以9600波特率发送，而接收方以19200波特率接收，接收方采样速度会快一倍，它会错误地将一个比特采样两次，或者在一个比特的起始和结束边缘采样，导致数据完全错乱，这就是我们常说的**“乱码”**的根本原因。
-
数据结构（The Frame）:
为了让接收方知道一个字节从哪里开始、到哪里结束，每一个字节的数据在传输时，都会被包裹在一个“帧”（Frame）里。一个典型的异步通信帧（以8N1为例）：
Idle (High) | Start Bit (Low) | D0 | D1 | D2 | D3 | D4 | D5 | D6 | D7 | Stop Bit (High) | Idle (High) <-----------|-----------------|----|----|----|----|----|----|----|----|-----------------|------------> Time- 空闲状态（Idle）: 在没有数据传输时，信号线保持在高电平。
- 起始位（Start Bit）: 当发送方准备发送一个字节时，它首先会将信号线从高电平拉到低电平，并保持一个比特的时间。这个从高到低的下降沿是一个明确的信号，告诉接收方：“注意，数据要来了！”。接收方检测到这个下降沿后，就启动自己的时钟，准备接收数据位。
- 数据位（Data Bits）: 紧跟在起始位之后的是数据本身，通常是5、6、7或8个比特。最常见的是8个比特（一个完整的字节）。数据位的发送顺序通常是最低位（LSB）在前。
- 奇偶校验位（Parity Bit） (可选):
- 这是一个简单的错误校验机制。它可以是：
- 无校验（None）: 不发送校验位。这是最常见的情况。
- 偶校验（Even）: 发送方计算所有数据位中’1’的个数。如果’1’的个数是奇数，则校验位置为’1’，以使总的’1’的个数变为偶数。反之，校验位置为’0’。
- 奇校验（Odd）: 与偶校验相反，确保总的’1.0’的个数为奇数。
- 接收方会进行同样的计算，并比较其计算出的校验位与接收到的校验位是否一致。如果不一致，就意味着传输过程中可能发生了错误（例如，某个比特被噪声翻转了），接收方可以丢弃这个字节。
- 这是一个简单的错误校验机制。它可以是：
- 停止位（Stop Bits）: 在数据位和可选的校验位都发送完毕后，发送方会将信号线拉回到高电平，并至少保持一个、一个半或两个比特的时间。这个高电平确保了信号线返回到空闲状态，并为下一个字节的起始位（下降沿）提供了一个清晰的边界。如果接收方在期望接收到停止位的地方没有检测到高电平，就会报告一个**“帧错误”（Framing Error）**。
-
常用配置：“8N1”
你在文档和设备手册中会经常看到“8N1”这个术语。它是一个简写，代表了最常见的串口配置：- 8: 8个数据位。
- N: No parity（无校验）。
- 1: 1个停止位。
1.4 操作系统与pyserial的角色
pyserial本身不是驱动程序。它是一个应用层的Python库，一个优雅的封装器（Wrapper）。它的作用是为我们屏蔽掉不同操作系统（Windows, macOS, Linux）下复杂的底层API差异，提供一套统一、简洁、Pythonic的接口。
-
在Linux上:
- 串口设备通常被表示为文件系统中的一个设备文件，位于
/dev/目录下。 - 物理串口（很少见）通常是
/dev/ttyS0,/dev/ttyS1等。 - USB转串口设备通常是
/dev/ttyUSB0,/dev/ttyUSB1…（对于FTDI, CP210x等芯片）或/dev/ttyACM0,/dev/ttyACM1…（对于实现了CDC-ACM协议的设备，如许多Arduino板）。 pyserial在后台实际上是在对这些设备文件执行open(),read(),write()等文件操作，并通过ioctl()系统调用来配置波特率、校验位等参数。
- 串口设备通常被表示为文件系统中的一个设备文件，位于
-
在Windows上:
- 串口设备被命名为
COM1,COM2,COM3… pyserial在后台是通过调用Windows API（例如，CreateFile(),ReadFile(),WriteFile(),SetCommState()等函数）来与COM端口驱动进行交互。
- 串口设备被命名为
理解这一点至关重要：当你调用ser.write(data)时，pyserial并不是直接将数据发送到物理线上。它首先是将数据交给了操作系统的串行驱动程序，放入驱动程序的发送缓冲区（Transmit Buffer）中。驱动程序会在后台负责将缓冲区中的数据，按照你设定的波特率等参数，一个比特一个比特地通过物理线发送出去。同理，当数据从物理线到达时，驱动程序会将其放入接收缓冲区（Receive Buffer），等待你的ser.read()调用来取走。这个缓冲区的存在，是后续我们讨论高效读写和线程架构的基础。
第二章：你的第一行代码——pyserial核心API深度解析
有了坚实的理论基础，我们现在可以开始探索pyserial的API了。我们将逐一剖析其核心组件，并解释每个参数和方法背后的“为什么”。
2.1 安装与设备发现
安装pyserial非常简单，它是纯Python库，没有任何复杂的依赖。
# 使用pip进行安装
pip install pyserial
在你开始通信之前，第一个问题是：我的设备连接到了哪个端口？pyserial提供了一个极其有用的工具来解决这个问题。
serial.tools.list_ports: 这个模块可以扫描系统，列出所有可用的串口设备。
# list_ports_detailed.py
import serial.tools.list_ports
def find_serial_devices():
"""
一个更详细的设备发现脚本，它会列出所有可用串口的详细信息。
"""
print("正在扫描可用的串口设备...")
# serial.tools.list_ports.comports() 会返回一个ListPortInfo对象的列表
ports = serial.tools.list_ports.comports()
if not ports: # 如果列表为空
print("未找到任何串口设备。请检查设备是否已连接，或驱动是否已正确安装。")
return
print(f"找到 {
len(ports)} 个设备:")
# 遍历列表，打印每个端口的详细信息
for port in sorted(ports): # sorted()可以确保每次输出的顺序一致
# port对象有很多有用的属性
print("-" * 40)
print(f"设备 (Device): {
port.device}") # 这是我们在代码中需要使用的端口名，例如 'COM3' 或 '/dev/ttyUSB0'
print(f" 名称 (Name): {
port.name}") # 端口的简短名称
print(f" 描述 (Description): {
port.description}") # 对端口的描述，通常包含设备名称
print(f" 硬件ID (HWID): {
port.hwid}") # 硬件ID，包含了VID和PID，非常重要
# VID (Vendor ID) 和 PID (Product ID) 是USB设备的身份证
# 它们可以用来唯一地识别一个特定型号的设备
print(f" 厂商ID (VID): {
port.vid}")
print(f" 产品ID (PID): {
port.pid}")
print(f" 序列号 (Serial Number): {
port.serial_number}") # 设备的唯一序列号（如果设备支持）
print(f" 位置 (Location): {
port.location}") # 物理位置信息（例如USB总线和端口号）
print(f" 制造商 (Manufacturer): {
port.manufacturer}") # 制造商名称
print(f" 产品名称 (Product): {
port.product}") # 产品名称
def find_specific_device(vendor_id, product_id):
"""
根据VID和PID精确查找特定设备。
"""
ports = serial.tools.list_ports.comports()
for port in ports:
if port.vid == vendor_id and port.pid == product_id:
print(f"找到了目标设备: {
port.device}")
return port.device
print(f"未找到VID={
vendor_id}, PID={
product_id}的设备。")
return None
if __name__ == '__main__':
find_serial_devices()
print("\n" + "="*50 + "\n")
# 示例：查找一个常见的Arduino Uno (CH340芯片)
# 你需要用你自己的设备的VID和PID替换这里的值
# 你可以通过运行上面的find_serial_devices()来找到它们
# 例如，一个FTDI芯片的VID通常是 0x0403
# 一个CH340芯片的VID通常是 0x1A86
arduino_vid = 0x1A86
arduino_pid = 0x7523
find_specific_device(arduino_vid, arduino_pid)
- 代码深度解析：
port.device是最重要的属性，它是我们之后在serial.Serial()中需要使用的端口字符串。- VID/PID 的重要性：COM口号（如
COM3）或设备文件名（如/dev/ttyUSB0）在你的电脑上是不固定的。你这次插入设备是COM3，下次重启或者换个USB口可能就变成COM4了。这对于需要稳定运行的程序是致命的。而VID和PID是写入设备硬件的，永远不会变。上面的find_specific_device函数展示了专业的做法：在程序启动时，不应硬编码端口号，而应通过VID和PID去动态地查找正确的端口。这是编写可移植、鲁棒的串口应用的第一步。
2.2 serial.Serial对象：通信的心脏
serial.Serial类是pyserial的绝对核心。它的实例化过程就是打开一个串口并完成所有参数配置的过程。掌握它的构造函数参数是精通pyserial的基础。
-
推荐的实例化方式：
with语句import serial try: # with语句确保了无论代码块内部发生什么（即使是异常）， # 在退出时都会自动调用ser.close()方法，释放串口资源。 # 这是一个非常好的编程习惯。 with serial.Serial('COM3', 9600, timeout=1) as ser: # 在这个代码块内，串口是打开的 print(f"成功打开串口: { ser.name}") # ... 在这里进行读写操作 ... # 在with语句块结束后，串口会自动关闭 print("串口已自动关闭。") except serial.SerialException as e: # 如果端口不存在或被占用，会抛出SerialException异常 print(f"打开串口时发生错误: { e}") -
构造函数参数详解:
serial.Serial(port=None, baudrate=9600, bytesize=EIGHTBITS, parity=PARITY_NONE, stopbits=STOPBITS_ONE, timeout=None, xonxoff=False, rtscts=False, write_timeout=None, dsrdtr=False, inter_byte_timeout=None)-
port: 字符串，指定要打开的端口名。例如'COM3'或'/dev/ttyUSB0'。如果设为None，则只创建一个对象，但并不立即打开端口，之后可以调用ser.open()。 -
baudrate: 整数，波特率。必须与设备端设置完全一致。 -
bytesize: 数据位的大小。可以是FIVEBITS,SIXBITS,SEVENBITS,EIGHTBITS。最常用的是EIGHTBITS。# 示例：配置为7个数据位 ser = serial.Serial(bytesize=serial.SEVENBITS) -
parity: 校验位。可以是PARITY_NONE,PARITY_EVEN,PARITY_ODD,PARITY_MARK,PARITY_SPACE。# 示例：配置为偶校验 ser = serial.Serial(parity=serial.PARITY_EVEN) -
stopbits: 停止位的数量。可以是STOPBITS_ONE,STOPBITS_ONE_POINT_FIVE,STOPBITS_TWO。# 示例：配置为2个停止位 ser = serial.Serial(stopbits=serial.STOPBITS_TWO) -
timeout: 极其重要的参数，控制read()操作的阻塞行为。timeout = None(默认): 阻塞模式。read()操作会一直等待，直到读取到所请求的字节数。如果设备没有发送数据，程序会永远卡在这里。timeout = 0: 非阻塞模式。read()操作会立即返回。它会返回当前接收缓冲区中所有可用的字节。如果没有可用的字节，它会立即返回一个空字节串b''。timeout = x(x为正数): 超时模式。read()操作会等待最多x秒。如果在x秒内读取到了所请求的字节数，它会立即返回。如果在x秒后仍未满足，它会返回当前已读取到的所有字节（可能比请求的少，也可能是空字节串）。这是最常用、最推荐的模式。
-
xonxoff: 布尔值。设为True以启用软件流控（XON/XOFF）。 -
rtscts: 布尔值。设为True以启用硬件流控（RTS/CTS）。 -
write_timeout: 浮点数，秒。write()操作的超时。通常只在启用了流控时才有意义。 -
dsrdtr: 布尔值。DSR/DTR硬件流控。 -
inter_byte_timeout: 浮点数，秒。字节间超时。这是一个高级参数，我们将在后续章节深入探讨。
-
2.3 发送数据：write()方法的内部机制
write()方法用于向串口发送数据。一个最关键、最容易被误解的点是：它接收的参数必须是**字节串（bytes）**类型，而不是普通的字符串（str）。
import serial
import time
def send_data_demo(port_name):
try:
with serial.Serial(port_name, 9600) as ser:
print(f"串口 {
ser.name} 已打开。准备发送数据。")
# --- 场景1: 发送ASCII文本 ---
text_to_send = "Hello, device!\n"
# 必须使用.encode()将字符串编码为字节串
# 'ascii' 或 'utf-8' 是常用的编码格式
bytes_to_send = text_to_send.encode('ascii')
ser.write(bytes_to_send)
print(f"已发送文本: {
bytes_to_send}")
time.sleep(0.1) # 稍微等待，让设备有时间处理
# --- 场景2: 发送控制指令 (通常是文本) ---
ser.write(b'MOTOR_SPEED:100\r\n') # 直接定义字节串，\r\n是常见的回车换行结束符
print("已发送电机速度指令。")
time.sleep(0.1)
# --- 场景3: 发送二进制数据/裸字节 ---
# 假设协议要求发送一个十六进制的启动序列 0xFA 0x05 0xFF
hex_sequence = bytes([0xFA, 0x05, 0xFF]) # 使用bytes()构造函数
ser.write(hex_sequence)
print(f"已发送十六进制序列: {
hex_sequence.hex(' ')}") # .hex()可以方便地显示
time.sleep(0.1)
# 使用bytearray，它是可变的字节数组
data_packet = bytearray()
data_packet.append(0x02) # Start of Text
data_packet.extend(b'some_payload') # 添加载荷
data_packet.append(0x03) # End of Text
ser.write(data_packet)
print(f"已发送数据包: {
data_packet}")
# --- 理解写缓冲和flush() ---
# 当你调用ser.write()时，数据被快速地复制到操作系统的发送缓冲区。
# 函数会立即返回，此时数据可能还没有被物理地发送出去。
# 如果你需要在发送完所有数据后再执行下一步操作（例如，切换RS485的收发方向），
# 你需要调用flush()。
ser.write(b'A_long_string_of_data_to_demonstrate_buffering......')
ser.flush() # flush()会阻塞程序，直到OS发送缓冲区中的所有数据都被清空（发送完毕）。
print("调用flush()后，可以确保所有挂起的数据都已被发送。")
except serial.SerialException as e:
print(f"错误: {
e}")
if __name__ == '__main__':
# 请将'COM3'替换为你自己的端口
# 在Linux上可能是 '/dev/ttyUSB0'
target_port = 'COM3'
send_data_demo(target_port)
2.4 接收数据：read()家族的精妙之处
接收数据是串口编程中最具挑战性的部分，因为你永远不知道数据会在什么时候、以多快的速度到达。pyserial为此提供了一套灵活的读取方法。
import serial
def receive_data_demo(port_name):
# 使用超时模式，这是最稳健的选择
with serial.Serial(port_name, 9600, timeout=1) as ser:
print(f"串口 {
ser.name} 已打开。等待接收数据...")
# --- 场景1: 读取固定数量的字节 ---
# 假设协议规定每个数据包都是10个字节长
print("\n尝试读取一个10字节的数据包...")
packet = ser.read(10) # 尝试读取10个字节，最多等待1秒
if packet:
print(f"成功接收到数据包: {
packet.hex(' ')}")
else:
print("在1秒内未接收到10字节的数据包。")
# --- 场景2: 读取直到行尾 (最常见) ---
# 适用于以换行符('\n')结束的文本数据，如GPS模块的NMEA语句、许多仪器的输出
print("\n尝试读取一行数据 (以'\\n'结尾)...")
line = ser.readline() # 读取直到遇到'\n'，或者超时
if line:
# readline()返回的字节串会包含行尾的'\n'
# 使用.decode().strip()可以将其转换为干净的字符串
cleaned_line = line.decode('ascii', errors='ignore').strip()
print(f"成功接收到一行: {
line}")
print(f"清理后的字符串: '{
cleaned_line}'")
else:
print("在1秒内未接收到一行数据。")
# --- 场景3: 读取直到特定序列 ---
# read_until()是readline()的通用版本
# 假设设备在发送完数据后会发送一个 "OK" 字符串
print("\n尝试读取直到遇到 'OK' ...")
# 读取直到遇到 b'OK'，或者超时
response = ser.read_until(expected=b'OK')
if response:
print(f"成功接收到响应: {
response}")
if response.endswith(b'OK'):
print("响应以'OK'结尾。")
else:
print("在1秒内未接收到包含'OK'的响应。")
# --- 场景4: 读取缓冲区中所有可用的数据 (非阻塞轮询) ---
# 这是编写GUI或高性能应用时的核心模式
print("\n检查输入缓冲区中所有可用的数据...")
# ser.in_waiting返回接收缓冲区中当前等待被读取的字节数
bytes_to_read = ser.in_waiting
if bytes_to_read > 0:
# 读取所有可用字节，这个read()因为知道确切字节数，所以会立即返回
all_available_data = ser.read(bytes_to_read)
print(f"发现并读取了 {
len(all_available_data)} 字节的数据: {
all_available_data.hex(' ')}")
else:
print("输入缓冲区为空。")
if __name__ == '__main__':
target_port = 'COM3'
receive_data_demo(target_port)
- 代码深度解析：
read(size): 适用于固定长度协议。它的行为完全受信于timeout的设置。readline(): 非常适合处理基于文本行的协议。但要小心，如果设备由于某种原因没有发送\n，在阻塞模式下它会永久挂起。这也是为何总是推荐使用超时模式的原因。read_until(expected): 功能更强大，可以定义任意的结束标记，非常适合处理那些有明确帧尾的二进制或文本协议。in_waiting: 这是编写非阻塞代码的关键。通过在读取前先检查in_waiting，你可以避免不必要的等待。在一个循环中不断地检查in_waiting，一旦有数据就立即读取，这是实现响应式程序（如需要同时处理用户输入和串口数据的应用）的基础。
第三章：驾驭数据洪流——流控制与缓冲区管理
想象一个场景：你的PC机性能强大，能以极高的速度通过ser.write()向一个资源有限的微控制器（MCU）发送大量数据。但这个MCU处理数据的速度跟不上，它的接收缓冲区很快就被填满了。如果不加任何控制，新到达的数据就会覆盖掉缓冲区里还未被处理的旧数据，造成数据丢失。**流控制（Flow Control）**机制正是为了解决这个问题而生的，它的目标是让发送方在接收方“忙不过来”的时候暂停发送。
pyserial支持两种主要的流控制方式：软件流控和硬件流控。
3.1 软件流控（XON/XOFF）：协议层面的“请稍等”
-
工作原理：
软件流控完全通过在数据通道中传输特殊的控制字符来实现，不需要额外的物理线路。- XOFF (Transmit Off): 当接收方（例如，MCU）的接收缓冲区即将满时（达到一个“高水位线”，High Water Mark），它会通过自己的TX线向发送方（PC）发送一个特殊的控制字符——
XOFF（ASCII码为19，或Ctrl+S）。 - 暂停发送: 发送方的串口驱动程序或
pyserial库在接收到XOFF字符后，会理解这个信号的含义，并立即暂停通过其TX线发送任何新的数据。 - XON (Transmit On): 当接收方处理掉一部分缓冲区中的数据，使其降到一个“低水位线”（Low Water Mark）以下后，它会再次发送一个
XON控制字符（ASCII码为17，或Ctrl+Q）。 - 恢复发送: 发送方接收到
XON字符后，就会恢复数据的发送。
- XOFF (Transmit Off): 当接收方（例如，MCU）的接收缓冲区即将满时（达到一个“高水位线”，High Water Mark），它会通过自己的TX线向发送方（PC）发送一个特殊的控制字符——
-
在
pyserial中启用软件流控：
只需在构造函数中设置xonxoff=True。# software_flow_control_demo.py import serial import time def xonxoff_sender_demo(port_name): """ 演示作为发送方，如何启用和观察软件流控。 """ try: # 启用软件流控 with serial.Serial(port_name, 9600, xonxoff=True) as ser: print(f"串口 { ser.name} 已打开，软件流控(XON/XOFF)已启用。") print("现在将尝试发送大量数据。请在接收端设备上配置相应的流控。") # 构造一个大数据块 # 20KB的数据足以填满大多数设备的缓冲区 large_data = b'X' * 20480 print("开始发送数据...") start_time = time.monotonic() # 当启用了流控后，如果接收方发送了XOFF，这个write调用可能会被阻塞， # 直到接收方发送XON，或者直到超时（如果设置了write_timeout）。 bytes_written = ser.write(large_data) # 在流控下，flush()会等待所有数据（包括被XOFF暂停后的数据）都发送完毕 ser.flush() end_time = time.monotonic() print(f"成功写入 { bytes_written} 字节。") print(f"数据发送耗时: { end_time - start_time:.2f} 秒。") print("如果耗时远超理论值 (20480 * 10 / 9600)，说明流控起作用了。") except serial.SerialException as e: print(f"错误: { e}") # 注意：这个示例需要一个对端设备来配合。 # 你可以在一个Arduino上编写程序，在接收缓冲区快满时发送XOFF， # 处理完数据后再发送XON，才能完整地观察到此效果。 # 如果没有对端配合，这个程序和普通的write行为没有区别。 if __name__ == '__main__': target_port = 'COM3' # 替换为你的端口 xonxoff_sender_demo(target_port) -
软件流控的优缺点：
- 优点：实现简单，不需要额外的硬件线路，只需标准的TX、RX、GND三根线即可。
- 缺点：
- 带内信令（In-band Signaling）: 控制字符
XON和XOFF本身是通过数据通道传输的。如果你的原始二进制数据中恰好包含了值为17或19的字节，这可能会被错误地解释为流控信号，造成混乱。因此，软件流控不适合传输纯粹的、未经处理的二进制数据。 - 响应延迟: 从接收方缓冲区满，到它发送
XOFF，再到发送方接收到XOFF并停止发送，这个过程存在一定的延迟。在这段延迟时间内，发送方可能已经又发送了几个字节的数据，这可能导致接收方缓冲区的溢出（Overflow）。因此，接收方的高水位线不能设置得太高。
- 带内信令（In-band Signaling）: 控制字符
3.2 硬件流控（RTS/CTS）：物理层面的“红绿灯”
硬件流控通过两根额外的物理信号线——RTS（Request to Send，请求发送）和CTS（Clear to Send，清除发送）——来实现，提供了一种更可靠、更高效的流控机制。
-
工作原理:
这是一个非常直接的“握手”过程。我们以PC作为发送方，MCU作为接收方为例：- PC请求发送: 当PC（发送方）有数据要发送时，它会首先**拉高（Assert）**自己的
RTS信号线。这相当于在问MCU：“我准备好发送数据了，你那边方便接收吗？” - MCU准备就绪: MCU（接收方）会检查自己的状态。如果它的接收缓冲区有足够的空间，它就会拉高自己的
CTS信号线作为回应。这相当于在说：“我已经准备好了，请发送吧。” - 开始发送: PC检测到自己的
CTS输入端变为高电平后，才开始通过TX线发送数据。 - MCU请求暂停: 如果在接收过程中，MCU的接收缓冲区即将满了，它会立即**拉低（De-assert）**自己的
CTS信号线。 - 暂停发送: PC检测到
CTS信号变为低电平后，会立刻暂停发送数据（通常是在当前字节发送完成后）。 - MCU恢复: 当MCU处理完数据，缓冲区空闲后，它会再次拉高
CTS信号，PC则恢复发送。
- PC请求发送: 当PC（发送方）有数据要发送时，它会首先**拉高（Assert）**自己的
-
在
pyserial中启用硬件流控：
设置rtscts=True。# hardware_flow_control_demo.py import serial import time def rtscts_sender_demo(port_name): """ 演示作为发送方，如何启用硬件流控。 这需要在物理上连接RTS和CTS线。 通常的连接方式是： PC的RTS -> MCU的CTS PC的CTS -> MCU的RTS """ try: # 启用硬件流控(RTS/CTS) with serial.Serial(port_name, 115200, rtscts=True) as ser: print(f"串口 { ser.name} 已打开，硬件流控(RTS/CTS)已启用。") print("这是一个演示，它会持续发送数据。") print("你可以通过在对端设备上拉低CTS线来观察发送是否会暂停。") counter = 0 while True: try: message = f"Message packet number { counter}\n".encode('ascii') # 在硬件流控下，如果对端的CTS线为低电平， # 操作系统驱动会暂停发送，这个write调用可能会阻塞。 ser.write(message) print(f"已发送: { message.strip()}") counter += 1 time.sleep(0.1) # 减慢发送速度以便观察 except KeyboardInterrupt: print("\n程序被用户中断。") break except serial.SerialException as write_error: print(f"写入时发生错误: { write_error}") break except serial.SerialException as e: print(f"错误: { e}") # 警告: 运行此示例需要正确的硬件连接和对端设备的支持。 # 如果你的USB转串口模块不支持或未连接RTS/CTS，启用此选项可能导致无法发送任何数据。 if __name__ == '__main__': target_port = 'COM4' # 替换为你的端口 rtscts_sender_demo(target_port) -
DSR/DTR流控 (
dsrdtr)
DSR (Data Set Ready)和DTR (Data Terminal Ready)是另一对硬件流控信号线，其工作方式与RTS/CTS类似，但语义上略有不同。DTR/DSR通常用于表示整个设备是否已“准备就绪”，而RTS/CTS更侧重于每个数据块的收发流控。在pyserial中，通过设置dsrdtr=True来启用它。在实践中，RTS/CTS更为常用。 -
硬件流控的优缺点：
- 优点：
- 带外信令（Out-of-band Signaling）: 流控是通过专门的硬件线路完成的，完全不占用数据通道。因此，它可以安全地用于传输任何类型的二进制数据。
- 即时响应: 信号是电平触发的，响应非常迅速，几乎没有延迟，可以非常有效地防止缓冲区溢出。
- 缺点：
- 需要额外的物理线路（至少5根线：TX, RX, RTS, CTS, GND），增加了布线的复杂性。
- 需要通信双方的硬件都支持并正确实现了RTS/CTS协议。
- 优点：
3.3 深入理解缓冲区：in_waiting与out_waiting
我们之前已经接触过in_waiting，现在让我们更深入地理解它和它的“兄弟”out_waiting。这两个属性让你能够窥探操作系统驱动程序内部的缓冲区状态，是编写高性能、非阻塞应用的关键。
-
ser.in_waiting(或ser.inWaiting()):- 作用：返回接收缓冲区中当前等待被Python程序通过
read()读取的字节数。 - 核心用途：避免阻塞。与其盲目地调用
ser.read(10)然后等待，不如在一个循环中快速地检查if ser.in_waiting > 0。这允许你的主循环在没有数据到达时，可以去执行其他任务（例如，更新GUI，响应用户点击），而不是被卡在read()上。
- 作用：返回接收缓冲区中当前等待被Python程序通过
-
ser.out_waiting(或ser.outWaiting()):- 作用：返回发送缓冲区中等待被物理发送出去的字节数。
- 核心用途：监控发送状态。当你调用
ser.write(data)时，函数会立即返回，但此时数据只是被复制到了发送缓冲区。ser.out_waiting会告诉你还有多少数据“在路上”。当ser.out_waiting变为0时，就意味着所有你之前写入的数据都已经从你的电脑物理地发送出去了（但这不代表对方已经收到了）。这与ser.flush()的作用类似，但flush()是阻塞的，而检查out_waiting是非阻塞的。
# buffer_management_demo.py
import serial
import time
def buffer_status_monitor(port_name):
"""
演示如何监控输入和输出缓冲区。
"""
try:
with serial.Serial(port_name, 115200, timeout=0.01) as ser:
print(f"串口 {
ser.name} 已打开。")
# 先清空一下可能存在的旧数据
ser.reset_input_buffer()
ser.reset_output_buffer()
# 写入一些数据到发送缓冲区
data_to_send = b'start_sequence_' + b'A' * 512 + b'_end_sequence'
bytes_written = ser.write(data_to_send)
print(f"已调用write()写入 {
bytes_written} 字节。")
# 监控发送缓冲区的变化
print("\n--- 监控发送缓冲区 (out_waiting) ---")
while ser.out_waiting > 0:
# 在高速串口上，这个循环可能很快就结束了
print(f"发送缓冲区中还有 {
ser.out_waiting} 字节等待发送...")
time.sleep(0.005) # 稍微暂停以便观察
print("发送缓冲区已清空 (out_waiting is 0)。")
print("\n--- 监控接收缓冲区 (in_waiting) ---")
print("等待设备回显数据... (程序将监控5秒)")
start_time = time.monotonic()
received_data = bytearray()
while time.monotonic() - start_time < 5:
# 非阻塞地检查接收缓冲区
if ser.in_waiting > 0:
# 一旦有数据，就全部读出
data = ser.read(ser.in_waiting)
received_data.extend(data)
print(f"检测到并读取了 {
len(data)} 字节。当前总共接收: {
len(received_data)} 字节。")
# 即使没有数据，主循环也不会被阻塞，可以做其他事
# print(" (主循环可以做其他事...)")
time.sleep(0.01)
print("\n监控结束。")
if received_data:
print(f"在5秒内总共接收到数据: {
received_data.decode('ascii', errors='ignore')}")
else:
print("在5秒内未接收到任何数据。")
except serial.SerialException as e:
print(f"错误: {
e}")
if __name__ == '__main__':
# 这个示例需要一个能回显数据的对端设备才能完整工作
# 例如，一个Arduino程序，它会把它收到的所有数据再发送回来
target_port = 'COM3'
buffer_status_monitor(target_port)
3.4 手动控制：清空缓冲区与RTS/DTR线
除了自动的流控，pyserial还提供了手动控制缓冲区和信号线的方法，这在需要精确同步和错误恢复时非常有用。
-
ser.reset_input_buffer():- 作用: 立即丢弃并清空接收缓冲区中的所有数据。
- 应用场景:
- 启动同步: 在开始一个新的通信会话前，调用此方法可以确保你不会读取到上一次通信残留的、无意义的“垃圾”数据。
- 错误恢复: 当你检测到一个协议错误（例如，校验和不匹配），并决定放弃当前正在接收的数据帧时，可以调用它来快速丢弃所有后续的、可能也已损坏的数据，然后准备接收一个新的、完整的帧。
-
ser.reset_output_buffer():- 作用: 立即丢弃并清空发送缓冲区中所有还未被物理发送的数据。
- 应用场景: 当用户点击“取消发送”按钮时，这个方法可以用来中止一个正在进行的、耗时较长的数据发送任务。
-
手动控制RTS/DTR线：
即使没有启用硬件流控，你也可以将rts和dtr属性当作通用的数字输出引脚来使用。这在某些特定场景下有奇特的妙用。import serial import time # ser = serial.Serial('COM3') # 手动设置RTS线的电平 # ser.rts = True # 将RTS线拉高 # ser.rts = False # 将RTS线拉低 # 手动设置DTR线的电平 # ser.dtr = True # 将DTR线拉高 # ser.dtr = False # 将DTR线拉低 # 应用场景： # 1. 重启Arduino：许多Arduino板的设计是，当DTR线从高电平变为低电平时，会触发板子的重启。 # Arduino IDE在上传代码前就是利用了这个机制。你可以在Python程序中模拟这个行为。 # ser.dtr = False # time.sleep(0.1) # ser.dtr = True # # 2. RS485方向控制：在半双工的RS485通信中，你需要一个引脚来控制收发器（如MAX485）的方向（接收或发送）。 # 你可以巧妙地利用RTS或DTR线来作为这个方向控制信号。在调用ser.write()之前， # 将ser.rts设为True（切换到发送模式），然后在调用ser.flush()确保发送完毕后， # 再将ser.rts设为False（切换回接收模式）。我们将在RS485章节详细探讨这个高级技巧。 -
读取CTS/DSR/RI/CD状态线：
你也可以读取对端设备的状态。ser.cts: 返回CTS线的状态 (True/False)。ser.dsr: 返回DSR线的状态。ser.ri: 返回RI (Ring Indicator，振铃指示) 线的状态，常用于调制解调器。ser.cd: 返回CD (Carrier Detect，载波检测) 线的状态。
掌握了流控制和缓冲区管理，你就拥有了构建稳定、高效数据传输通道的能力。你不再惧怕数据丢失，并且能够编写出响应流畅、不会因等待IO而“假死”的应用程序。这是从入门到专业的关键一步，为你接下来设计复杂的通信协议和多线程应用架构铺平了道路。
4.1 协议设计的核心要素
无论一个协议多么复杂，它通常都由以下几个核心组件构成：
-
帧结构（Frame Structure）: 定义了一个完整数据包（帧）的边界和内部结构。
- 帧头（Header / Start of Frame, SOF）: 一个或多个固定的、在数据中很少出现的字节，用于明确地标识一个新数据帧的开始。这使得接收方可以在连续的字节流中实现“再同步”——即使错过了前一个帧，只要检测到帧头，就能从下一个帧开始正确解析。
- 地址/ID（Address / ID） (可选): 在多点通信总线（如RS485）上，用于指定该帧是发给哪个从设备的，或者来自哪个从设备。
- 功能码/命令（Function Code / Command）: 定义了这个数据帧的“意图”，例如，是读取一个传感器的值，还是设置一个电机的速度。
- 数据长度（Data Length）: 明确地告诉接收方，紧随其后的数据载荷（Payload）有多少个字节。这对于处理可变长度的数据包至关重要。
- 数据载荷（Payload / Data）: 真正要传输的有效数据，如传感器读数、配置参数等。
- 校验码（Checksum / CRC）: 用于验证数据在传输过程中是否出错。
- 帧尾（Footer / End of Frame, EOF） (可选): 一个或多个固定的字节，用于标识数据帧的结束。
-
数据编码（Data Encoding）: 定义了如何将程序中的各种数据类型（整数、浮点数、字符串）转换为字节流进行传输。
- ASCII编码: 将所有数据都转换为人类可读的ASCII字符串。简单直观，便于调试，但效率较低。
- 二进制编码: 直接传输数据的二进制表示。效率高，数据紧凑，但调试时需要工具来解析。
-
时序与状态机（Timing & State Machine）: 定义了通信的流程，例如，发送一个命令后应该等待多久的响应，收到一个特定的响应后应该进入什么状态等。
4.2 实践出真知：协议的迭代设计
我们将通过一个具体的例子——从PC控制一个带温湿度传感器的MCU，并读取其数据——来逐步设计和实现一个通信协议。
4.2.1 版本1.0：简单文本协议（Simple ASCII Protocol）
这是最容易上手的方式，非常适合初学者和简单的应用。
-
协议定义:
- PC -> MCU (命令):
"GET_TEMP\n": 请求温度数据。"GET_HUMI\n": 请求湿度数据。"SET_LED:1\n": 打开LED（1=ON, 0=OFF）。
- MCU -> PC (响应):
"TEMP:25.4\n": 温度响应。"HUMI:60.2\n": 湿度响应。"OK\n": 对设置命令的成功确认。
- 所有命令和响应都以换行符
\n作为帧的结束标记。
- PC -> MCU (命令):
-
Python实现 (PC端)
# simple_ascii_protocol_pc.py import serial import time class SimpleAsciiDevice: def __init__(self, port): """初始化并打开串口。""" try: # 使用较长的超时以确保能接收到完整的响应 self.ser = serial.Serial(port, 9600, timeout=2) print(f"设备已在端口 { port} 上连接。") except serial.SerialException as e: print(f"无法打开端口 { port}: { e}") self.ser = None def close(self): """关闭串口。""" if self.ser and self.ser.is_open: self.ser.close() print("设备连接已关闭。") def send_command(self, command): """发送命令并等待一个文本行响应。""" if not self.ser: return "错误: 设备未连接" # 确保命令以换行符结尾 if not command.endswith('\n'): command += '\n' # 发送编码后的命令 self.ser.write(command.encode('ascii')) print(f"-> 已发送: { command.strip()}") # 等待并读取响应 response = self.ser.readline() if response: decoded_response = response.decode('ascii').strip() print(f"<- 已接收: { decoded_response}") return decoded_response else: print("<- 接收超时！") return "错误: 接收超时" def get_temperature(self): """获取温度值。""" response = self.send_command("GET_TEMP") if response.startswith("TEMP:"): try: # 分割字符串并提取温度值 temp_str = response.split(':')[1] return float(temp_str) except (IndexError, ValueError): return "错误: 无效的温度格式" return response # 返回原始错误信息 def get_humidity(self): """获取湿度值。""" response = self.send_command("GET_HUMI") if response.startswith("HUMI:"): try: # 分割字符串并提取湿度值 humi_str = response.split(':')[1] return float(humi_str) except (IndexError, ValueError): return "错误: 无效的湿度格式" return response def set_led(self, state): """设置LED状态。""" command = f"SET_LED:{ 1 if state else 0}" response = self.send_command(command) return response == "OK" if __name__ == '__main__': # 请替换为你的MCU所连接的端口 device_port = 'COM3' device = SimpleAsciiDevice(device_port) if device.ser: # 确保设备已成功连接 try: # 循环执行操作 for i in range(3): print("\n--- 操作轮次 {} ---".format(i + 1)) # 设置LED print("\n正在设置LED...") led_on_success = device.set_led(True) print(f"打开LED是否成功: { led_on_success}") time.sleep(1) led_off_success = device.set_led(False) print(f"关闭LED是否成功: { led_off_success}") # 获取传感器数据 print("\n正在读取传感器数据...") temperature = device.get_temperature() print(f"获取到的温度: { temperature} °C") humidity = device.get_humidity() print(f"获取到的湿度: { humidity} %") time.sleep(2) finally: # 确保程序结束时关闭串口 device.close() -
优点：非常直观，人类可读，极易于调试。你可以直接用任何串口监视器工具（如Arduino IDE的串口监视器、PuTTY）看到清晰的通信内容。
-
缺点：
- 效率低：传输一个浮点数
25.4需要4个字节（'2','5','.','4'），而如果用二进制浮点数传输，也只需要4个字节。对于更长的数字或字符串，效率差距会更大。 - 解析开销大：接收方需要进行字符串分割、类型转换等操作，这在资源有限的MCU上会消耗宝贵的CPU周期。
- 无校验：如果传输过程中有一个比特发生错误（例如
"TEMP:25.4\n"变成了"TFMP:25.4\n"），接收方无从得知，可能会解析出一个完全错误的值。
- 效率低：传输一个浮点数
4.2.2 版本2.0：带校验和的二进制协议
为了解决1.0版本的问题，我们设计一个更高效、更可靠的二进制协议。
-
协议定义:
- 通用帧结构:
[帧头(1B)] [命令(1B)] [数据长度(1B)] [数据载荷(N B)] [校验和(1B)] - 帧头: 固定为
0xA5。 - 命令:
0x01: 请求温度0x02: 请求湿度0x10: 设置LED
- 数据长度: 后面跟随的数据载荷的字节数。
- 数据载荷:
- 对于设置命令，1个字节：
0x01=ON,0x00=OFF。 - 对于响应，4个字节：一个32位浮点数。
- 对于设置命令，1个字节：
- 校验和（Checksum）: 从
命令到数据载荷的所有字节的**异或（XOR）**校验。这是一种简单但有效的校验方式。接收方会用同样的方法计算接收到的数据的校验和，并与帧中附带的校验和进行比较。
- 通用帧结构:
-
Python实现 (PC端)
我们需要使用struct模块来在Python的数据类型（如浮点数）和字节串之间进行转换。# binary_protocol_pc.py import serial import struct import time class BinaryDevice: FRAME_HEADER = 0xA5 # 定义帧头常量 CMD_GET_TEMP = 0x01 # 定义命令常量 CMD_GET_HUMI = 0x02 CMD_SET_LED = 0x10 # 响应命令 (MCU -> PC) RSP_TEMP = 0x81 RSP_HUMI = 0x82 RSP_OK = 0x90 RSP_ERROR = 0xFF def __init__(self, port): try: self.ser = serial.Serial(port, 9600, timeout=2) print(f"设备已在端口 { port} 上连接。") except serial.SerialException as e: print(f"无法打开端口 { port}: { e}") self.ser = None def close(self): if self.ser and self.ser.is_open: self.ser.close() print("设备连接已关闭。") def _calculate_checksum(self, data_bytes): """计算给定字节串的XOR校验和。""" checksum = 0 for byte in data_bytes: checksum ^= byte # 逐字节进行异或运算 return checksum def _send_frame(self, command, payload=b''): """构建并发送一个完整的二进制帧。""" if not self.ser: return data_len = len(payload) # 获取数据载荷长度 # 校验和的计算范围：命令 + 长度 + 载荷 checksum_data = bytes([command, data_len]) + payload checksum = self._calculate_checksum(checksum_data) # 构建完整的数据帧 frame_to_send = bytes([self.FRAME_HEADER]) + checksum_data + bytes([checksum]) print(f"-> 正在发送帧: { frame_to_send.hex(' ')}") self.ser.write(frame_to_send) self.ser.flush() # 确保立即发送 def _receive_frame(self): """接收并验证一个完整的二进制帧。""" if not self.ser: return None, None # 1. 等待并读取帧头 header = self.ser.read(1) if not header or header[0] != self.FRAME_HEADER: print("<- 接收错误: 无效的帧头或超时。") return None, None # 2. 读取命令和长度 cmd_len_bytes = self.ser.read(2) if len(cmd_len_bytes) < 2: print("<- 接收错误: 无法读取命令和长度。") return None, None command, data_len = cmd_len_bytes[0], cmd_len_bytes[1] # 3. 读取数据载荷和校验和 payload_and_checksum = self.ser.read(data_len + 1) if len(payload_and_checksum) < data_len + 1: print("<- 接收错误: 无法读取完整的载荷和校验和。") return None, None payload = payload_and_checksum[:data_len] received_checksum = payload_and_checksum[-1] # 4. 验证校验和 checksum_data = bytes([command, data_len]) + payload calculated_checksum = self._calculate_checksum(checksum_data) if received_checksum != calculated_checksum: print(f"<- 校验和错误! 收到: { received_checksum}, 计算出: { calculated_checksum}") return None, None print(f"<- 成功接收帧: Command=0x{ command:02X}, Payload={ payload.hex(' ')}") return command, payload def get_temperature(self): """获取温度值。""" self._send_frame(self.CMD_GET_TEMP) rsp_cmd, payload = self._receive_frame() if rsp_cmd == self.RSP_TEMP and len(payload) == 4: # 使用struct.unpack来将4字节的字节串转换为浮点数 # '<f' 表示 小端(little-endian), 32位浮点数 temperature = struct.unpack('<f', payload)[0] return temperature return "错误: 无效的温度响应" def get_humidity(self): """获取湿度值。""" self._send_frame(self.CMD_GET_HUMI) rsp_cmd, payload = self._receive_frame() if rsp_cmd == self.RSP_HUMI and len(payload) == 4: humidity = struct.unpack('<f', payload)[0] return humidity return "错误: 无效的湿度响应" def set_led(self, state): """设置LED状态。""" payload = b'\x01' if state else b'\x00' # 构造1字节的载荷 self._send_frame(self.CMD_SET_LED, payload) rsp_cmd, _ = self._receive_frame() return rsp_cmd == self.RSP_OK if __name__ == '__main__': device_port = 'COM3' device = BinaryDevice(device_port) if device.ser: try: # ... (测试逻辑与ASCII版本类似) ... print("\n--- 二进制协议操作 ---") success = device.set_led(True) print(f"打开LED是否成功: { success}") time.sleep(1) temp = device.get_temperature() print(f"获取到的温度: { temp:.2f} °C") time.sleep(1) humi = device.get_humidity() print(f"获取到的湿度: { humi:.2f} %") finally: device.close() -
代码深度解析：
struct模块: 这是处理二进制数据的核心。struct.pack()可以将Python的数据类型（int, float等）打包成字节串，而struct.unpack()则可以反向解包。格式化字符串如'<f'是关键，'<'代表小端字节序（大多数MCU使用），'f'代表32位浮点数。- 校验和:
_calculate_checksum函数展示了如何实现一个简单的XOR校验。这种校验虽然不能像CRC那样检测出所有类型的错误，但实现极其简单，对于大多数场景已经足够。 - 健壮的接收逻辑:
_receive_frame函数是一个健壮的接收状态机。它严格地按照协议的结构一步步读取：先找帧头，再读固定长度的命令和长度字段，然后根据长度字段去读取可变长度的载荷，最后进行校验。任何一步出错，都会立即中止并报告错误，而不是继续错误地解析下去。这大大提高了通信的可靠性。
-
优点：
- 高效紧凑：数据传输效率高。
- 可靠性：校验和机制能检测出绝大多数传输错误。
- 解析开销小：MCU端无需进行复杂的字符串处理。
-
缺点：
- 不易调试：二进制数据流对人类不友好，调试时需要借助工具或编写解析脚本。
- 扩展性：如果需要增加新的命令或数据类型，需要同时修改PC和MCU两端的代码。
4.3 工业标准：Modbus RTU协议简介与pyserial实现
在工业自动化领域，你无法回避Modbus协议。它是一种应用层的串行通信协议，发布于1979年，至今仍是工业设备间通信的事实标准。学习它，能让你直接与数以百万计的PLC、变频器、温控器等工业设备对话。
pyserial本身不直接实现Modbus，但我们可以使用专门的库，如pymodbus，它在底层会调用pyserial来进行实际的串口操作。
pip install pymodbus
-
Modbus RTU核心概念:
- 主从（Master-Slave）架构: 网络上有一个主站（通常是PC或HMI），和多个（最多247个）从站（PLC、传感器等）。只有主站能发起通信。
- 功能码（Function Codes）: 定义了操作的类型，如：
0x03: 读保持寄存器（Read Holding Registers）0x04: 读输入寄存器（Read Input Registers）0x06: 写单个寄存器（Write Single Register）0x01: 读线圈（Read Coils）
- 数据地址（Data Address）: 每个从站内部都有一个数据区，分为不同的区域（线圈、离散量输入、输入寄存器、保持寄存器），每个数据都有一个唯一的地址。
- 帧结构:
[从站地址(1B)] [功能码(1B)] [数据(N B)] [CRC16校验(2B)] - CRC16: Modbus使用一种更强大的16位循环冗余校验，能提供比简单校验和高得多的错误检测能力。
-
使用
pymodbus与pyserial进行Modbus通信# modbus_rtu_demo.py from pymodbus.client.serial import ModbusSerialClient from pymodbus.exceptions import ModbusIOException def modbus_rtu_master_demo(port): """ 演示作为Modbus RTU主站，读取一个从站的数据。 """ print("正在初始化Modbus RTU客户端...") # 1. 创建一个Modbus RTU客户端实例 # pymodbus在内部会使用pyserial来处理这个端口 # 你可以传入所有pyserial支持的参数，如baudrate, parity等 client = ModbusSerialClient( port=port, baudrate=9600, stopbits=1, bytesize=8, parity='N', timeout=1 ) try: # 2. 连接到串口 connection = client.connect() if not connection: print("错误: 无法连接到串口。") return print("Modbus客户端已连接。") # --- 示例操作: 读取从站数据 --- # 假设我们要读取的从站地址是1 SLAVE_ID = 1 # 假设我们要读取的数据是位于地址0的保持寄存器(Holding Register)，读取1个 # 功能码 0x03: Read Holding Registers # address=0: 寄存器的起始地址 # count=2: 要读取的寄存器数量（例如，一个32位浮点数占2个16位寄存器） # slave=SLAVE_ID: 从站的单元ID print(f"\n尝试读取从站 { SLAVE_ID} 的地址为 0 的 2 个保持寄存器...") # 3. 发起Modbus读请求 response = client.read_holding_registers(address=0, count=2, slave=SLAVE_ID) # 4. 检查和解析响应 if response.isError(): print(f"Modbus错误响应: { response}") elif isinstance(response, ModbusIOException): print(f"Modbus IO错误: 无法与从站通信。") else: # response.registers 是一个包含了读取到的值的列表 print(f"成功接收到响应。寄存器值: { response.registers}") # --- 将寄存器值解码为浮点数 --- # 假设设备将一个32位浮点数存储在两个连续的16位寄存器中 # 我们需要将这两个16位整数重新组合成一个32位整数，然后解码 from pymodbus.payload import BinaryPayloadDecoder from pymodbus.constants import Endian # decoder需要知道字节序和字序 # Word-Endian: 寄存器的高低位顺序 # Byte-Endian: 每个寄存器内部字节的高低位顺序 decoder = BinaryPayloadDecoder.fromRegisters( response.registers, byteorder=Endian.BIG, # 例如，大端字节序 wordorder=Endian.LITTLE # 例如，小端字序 ) float_value = decoder.decode_32bit_float() print(f"解码后的浮点数值: { float_value:.4f}") except Exception as e: print(f"发生未知错误: { e}") finally: # 5. 关闭连接 client.close() print("\nModbus连接已关闭。") if __name__ == '__main__': # 替换为连接到你的Modbus从站的端口 modbus_port = 'COM4' modbus_rtu_master_demo(modbus_port) -
代码深度解析：
- 抽象层次:
pymodbus将我们从繁琐的帧构建和CRC计算中解放了出来。我们只需要调用高级的、语义化的方法，如read_holding_registers()。pymodbus会在后台为我们构建正确的Modbus RTU帧，计算CRC16，然后通过pyserial发送出去。 - 响应处理:
pymodbus的响应对象response提供了方便的错误检查方法isError()，并能直接访问解析好的寄存器值列表response.registers。 - 载荷解码:
BinaryPayloadDecoder是pymodbus中一个极其有用的工具，它专门用于处理将多个16位寄存器组合成更大数据类型（如32/64位整数、浮点数）的复杂情况，并能优雅地处理各种字节序和字序的问题。这是在实际工业应用中必须掌握的技能。
- 抽象层次:
第五章：驾驭并发——构建响应式的串口通信系统
在传统的顺序执行程序中，当一个操作需要等待外部事件（例如，从串口读取数据直到超时）时，整个程序就会暂停，直到这个操作完成。这种“阻塞式”的I/O在许多场景下是不可接受的：
- 图形用户界面（GUI）应用：如果串口读取操作阻塞了主线程，那么GUI界面就会“假死”，用户无法点击按钮、拖动窗口，直到串口操作完成。
- 实时数据采集：如果你需要以高频率从传感器读取数据，同时又希望执行数据处理、存储、网络传输等任务，单线程模型将无法满足实时性要求。
- 多任务处理：程序可能需要同时与多个串口设备通信，或者在等待串口数据的同时处理网络请求、文件操作等其他任务。
并发编程（Concurrency）正是解决这些问题的关键。它允许你的程序同时（或看起来同时）执行多个独立的任务，从而提高程序的响应性、吞吐量和资源利用率。在Python中，实现并发的主要方式是多线程（Multithreading）和多进程（Multiprocessing），以及现代的异步I/O（Asynchronous I/O）。
5.1 为什么串口通信需要并发？阻塞I/O的诅咒
让我们用一个简单的例子来直观感受阻塞I/O的痛点。
# blocking_io_demo.py
import serial
import time
def blocking_serial_read_problem(port_name):
"""
演示阻塞式串口读取如何冻结主程序。
"""
try:
# 创建一个串口对象，设置为阻塞模式 (timeout=None)
# 注意：在实际应用中，很少会使用timeout=None，因为它风险太高。
# 这里仅为演示阻塞效果。
with serial.Serial(port_name, 9600, timeout=None) as ser:
print(f"串口 {
ser.name} 已打开，设置为阻塞模式。")
print("等待接收数据... (程序将在此处卡住，直到有数据或被中断)")
# 尝试读取10个字节
# 如果串口没有发送数据，或者发送的数据不足10字节，程序将永远停留在这里。
received_data = ser.read(10)
print(f"成功接收到数据: {
received_data}")
except serial.SerialException as e:
print(f"打开串口或读取时发生错误: {
e}")
except KeyboardInterrupt:
print("\n用户中断了程序。")
def demonstrate_blocking_effect():
"""
一个模拟的GUI主循环，在执行阻塞串口读写时会“冻结”。
"""
# 模拟一个长时间运行的、非串口相关的任务
def long_running_task():
print("开始执行一个模拟的长任务...")
time.sleep(5) # 模拟耗时操作
print("长任务完成。")
print("--- 演示阻塞效果 ---")
print("程序将先执行一个长时间任务，然后尝试读取串口。")
print("在此期间，如果你有GUI，它会看起来没有响应。")
# 假设这里是GUI的主循环，或者一个需要持续响应的后台服务
start_time = time.time()
while time.time() - start_time < 10: # 运行10秒
print(f"主程序正在运行... ({
(time.time() - start_time):.1f}s)")
# 假设在某个时刻，我们尝试进行串口I/O
if time.time() - start_time > 3 and not hasattr(demonstrate_blocking_effect, 'serial_read_attempted'):
print("\n!!! 尝试进行串口读取，这将阻塞主程序 !!!")
# 标记，防止重复尝试
setattr(demonstrate_blocking_effect, 'serial_read_attempted', True)
# 警告：此行会导致程序阻塞，除非实际连接了设备并发送了数据
# blocking_serial_read_problem('COM3') # 替换为你的串口
print(" (为了不实际卡住你的电脑，这里注释掉了实际的阻塞调用)")
print(" (请自行想象，如果上面这行被执行，主程序会在此处卡住，不会打印后续的'主程序正在运行...')")
time.sleep(1) # 模拟每秒更新一次GUI或状态
print("主程序演示结束。")
if __name__ == '__main__':
# 运行第一个函数来直接体验串口阻塞
# blocking_serial_read_problem('COM3') # 取消注释并替换端口号以运行实际演示
# 运行第二个函数来演示主循环冻结的效果
demonstrate_blocking_effect()
- 代码深度解析：
blocking_serial_read_problem函数中的ser.read(10)在timeout=None（默认阻塞模式）下是致命的。如果设备没有发送10个字节，程序就会永远卡在这里。demonstrate_blocking_effect函数模拟了一个应用程序的主循环。如果在循环内部直接调用阻塞的串口操作，那么在串口操作完成之前，time.sleep(1)以及其他任何更新UI或处理用户输入的代码都将无法执行，导致程序“冻结”。
5.2 Python线程基础与pyserial的结合
为了解决阻塞I/O的问题，我们可以将串口的读写操作放到一个独立的**线程（Thread）**中执行。线程是操作系统能够调度的最小执行单元。它们共享同一个进程的内存空间，这意味着线程之间可以方便地访问相同的数据（但也带来了共享数据引发的复杂性）。
Python的threading模块提供了创建和管理线程的功能。
-
threading.Thread类：- 目标函数：最常用的方式是创建一个
Thread对象，并将你希望在新线程中执行的函数作为target参数传入。 - 启动：调用线程对象的
start()方法来启动线程。 - 等待结束：调用线程对象的
join()方法来等待线程执行完毕。
- 目标函数：最常用的方式是创建一个
-
示例：一个简单的串口读取线程
# basic_serial_thread.py import serial import threading import time # 一个全局标志，用于控制线程的运行和终止 stop_read_thread_flag = threading.Event() def serial_read_worker(port_name, baudrate=9600, timeout=1): """ 一个在新线程中运行的函数，负责从串口读取数据。 """ print(f"读线程: 尝试打开串口 { port_name}...") try: # 串口连接应该在线程内部建立，以确保资源正确管理 with serial.Serial(port_name, baudrate, timeout=timeout) as ser: print(f"读线程: 串口 { ser.name} 已打开。") # 循环读取数据，直到收到停止信号 while not stop_read_thread_flag.is_set(): # 检查停止标志 # 使用非阻塞或带超时的读取方式 # timeout=1 表示最多等待1秒，如果没数据就返回空字节串 data = ser.read(ser.in_waiting if ser.in_waiting > 0 else 1) if data: print(f"读线程: 接收到数据: { data.hex(' ')}") # 避免空转消耗CPU，在没有数据时稍微暂停 time.sleep(0.01) print("读线程: 串口已关闭。") except serial.SerialException as e: print(f"读线程错误: 无法打开或操作串口 { port_name}: { e}") finally: print("读线程: 已退出。") def main_program(port_name): """ 主程序，启动读取线程并进行其他操作。 """ print("主程序: 启动...") # 创建并启动读取线程 # target 参数指定了线程要执行的函数 # args 参数以元组形式传递给目标函数 read_thread = threading.Thread( target=serial_read_worker, args=(port_name, 9600, 1), daemon=True # 设置为守护线程，主程序退出时它也会退出 ) read_thread.start() # 启动线程 print("主程序: 读线程已启动。") print("主程序: 正在执行其他任务... (持续5秒)") start_time = time.time() while time.time() - start_time < 5: # 主程序在这里可以做其他事情，不会被串口读取阻塞 print(f"主程序: 运行中... ({ (time.time() - start_time):.1f}s)") time.sleep(1) print("\n主程序: 发送停止信号给读线程...") stop_read_thread_flag.set() # 设置停止标志，通知读线程退出循环 # 等待读线程优雅地结束 read_thread.join(timeout=2) # 最多等待2秒 if read_thread.is_alive(): print("主程序: 读线程未能在规定时间内停止。") else: print("主程序: 读线程已优雅停止。") print("主程序: 结束。") if __name__ == '__main__': # 请替换为你的串口 target_port = 'COM3' main_program(target_port) -
代码深度解析：
threading.Thread: 这是Python创建线程的核心类。target指定了线程要执行的函数，args用于向该函数传递参数。daemon=True: 守护线程。当所有非守护线程（包括主线程）都终止时，守护线程会自动终止。这对于那些后台服务性线程（如串口读线程）非常有用，可以避免在主程序退出后它们仍然在后台运行。threading.Event: 这是线程间通信和同步的一种基本机制。stop_read_thread_flag = threading.Event(): 创建一个事件对象。stop_read_thread_flag.is_set(): 检查事件是否被设置为“已设置”（True）。stop_read_thread_flag.set(): 将事件设置为“已设置”，这将立即解除所有等待该事件的线程的阻塞（如果它们在wait()上）。- 这种方式比简单地使用一个布尔标志位更好，因为
Event提供了wait()方法，可以用于线程间的阻塞等待。
ser.read(ser.in_waiting if ser.in_waiting > 0 else 1): 这是读取逻辑的一个小技巧。ser.in_waiting返回缓冲区中可用的字节数。如果大于0，我们一次性读取所有可用数据；如果为0，我们只尝试读取1个字节，但由于timeout=1的存在，它最多只会等待1秒，确保不会无限期阻塞。time.sleep(0.01)是必要的，以避免在没有数据时线程空转，过度消耗CPU。read_thread.join(timeout=2):join()方法用于等待一个线程完成执行。设置timeout是一个好的实践，它防止主线程无限期地等待一个可能永远不会结束的线程。
5.3 线程间的安全通信：数据队列（queue模块）
在上面的例子中，读线程只是打印数据。但在实际应用中，读线程需要将数据传递给主线程进行处理，而主线程也可能需要向串口发送数据。当多个线程访问或修改同一个数据（如一个列表）时，就会发生竞态条件（Race Condition），导致数据损坏或不可预测的行为。
Python的queue模块提供了线程安全的队列，这是解决线程间通信和共享数据问题的标准和推荐方法。
-
queue.Queue类：- 这是一个先进先出（FIFO）的队列。
- 它的所有操作（
put(),get(),qsize()等）都是线程安全的，这意味着你无需自己加锁。 put(item): 将数据放入队列。如果队列已满，会阻塞直到有空间（除非设置了block=False或timeout）。get(): 从队列中取出数据。如果队列为空，会阻塞直到有数据（除非设置了block=False或timeout）。empty(): 检查队列是否为空。qsize(): 返回队列中元素的数量。
-
架构模式：生产者-消费者
- 串口读线程：扮演生产者的角色，它从串口读取数据，然后将数据放入一个接收队列（Receive Queue）。
- 主线程：扮演消费者的角色，它从接收队列中取出数据进行处理。
- 主线程：扮演生产者的角色，它将要发送的数据放入一个发送队列（Send Queue）。
- 串口写线程：扮演消费者的角色，它从发送队列中取出数据，然后发送到串口。
-
示例：带有队列的串口工作线程
# serial_worker_with_queues.py import serial import threading import queue # 导入队列模块 import time class SerialWorker
最低0.47元/天 解锁文章
扫一扫
1465
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
