Proteus仿真RS485多机通信的温湿度检测系统设计详解

简介：基于单片机Proteus仿真的温湿度检测RS485多机通信设计方案，是一份面向单片机初学者与嵌入式开发者的完整实例，适合学习51单片机、RS485总线协议及多机通信原理。方案实现1个主机与2个从机的典型架构：每个从机通过DHT11采集环境温湿度，经RS485总线将数据发送至主机，主机接收后在LCD1602液晶屏上实时显示。压缩包共67个文件，大小6.91MB，以C语言源程序、Proteus仿真工程、Keil工程文件、hex烧录文件和文本说明为主，目录按主机、从1、从2及仿真图分模块组织，便于对照学习。随包附带操作演示视频，可辅助理解仿真运行与联调过程。资源已有204人学习下载，适合作为课程设计、毕业设计或自学RS485多机通信的参考资料。

1. 基于单片机Proteus仿真的温湿度检测RS485多机通信系统要解决什么问题

很多初级工程师第一次接触RS485多机通信，往往卡在“仿真图能画、单机收发正常，但一接多台从机就乱”。这背后的原因是RS485是半双工差分总线，硬件上要管住发送/接收方向，协议上要解决“谁先说、说给谁听、错了怎么重来”。温湿度检测则额外要求单片机能稳定读取DHT11这类单总线传感器，并把数据填到约定的帧里。把这三件事放到Proteus里一起做，最大价值不是省一块开发板，而是能反复模拟多节点总线冲突、地址错配、帧校验失败等现场问题，在看波形和虚拟终端的条件下快速定位。

这篇文章以最常见的STC89C52 + DHT11 + MAX485组合为例，从器件选型、仿真图连线、源码框架、一主多从组网到调试技巧，讲清一条能直接落到毕业设计或产品原型上的路径。无论你是刚做单片机课程设计，还是要给现有设备加远程采集，下面这套“先仿真证明逻辑，再移植硬件”的做法都适用。

2. 温湿度检测与RS485一主多从的方案选型

2.1 温湿度传感器用DHT11还是其他单总线器件

做Proteus仿真和51单片机应用，DHT11几乎是绕不开的选择。它的通信时序只有一根数据线，单片机用普通IO模拟即可，精度虽然只有±2℃和±5%RH，但对环境监测、库房记录这类场景足够。Proteus元件库里直接可以放置DHT11，双击模型能修改当前温度和湿度值，适合模拟“温度从25℃跳到35℃”时从机是否真的把新数据传回主机。

需要区分的是，DHT11每次读到的40bit数据依次是“湿度整数、湿度小数、温度整数、温度小数、校验和”。校验和的算法是前四个字节相加，取低8位，若与第五个字节相等，说明本次读取有效。很多仿真中乱码，不是因为Proteus的DHT11模型有问题，而是单片机读时序太慢或过快，导致位序错位。后面代码部分会给出一个能直接用的读取函数。

如果项目对精度有更高要求，可以换成SHT30或AM2302。SHT30走I2C，一个总线上还能挂多个传感器，但Proteus里模型不如DHT11常见，所以本文以DHT11为主。在实际产品中，建议用SHT30一类数字传感器，DHT11适合教学和原型验证。

2.2 RS485半双工总线为什么适合多机温湿度采集

RS485是差分传输，A、B两根线电压差表示逻辑0和1，抗共模干扰能力强，无中继时传输距离可达1200米，一条总线上最多能挂128个标准收发器。和单端串口TTL相比，RS485多出的不是速度，而是可靠的“多点共享信道”。温湿度检测场景中，几十个采集点分布在车间或仓库不同角落，用RS485组网，主机轮流点名，每个从机收到自己的地址再应答，结构非常清晰。

RS485是半双工总线，同一时刻只能有一台设备向总线发送数据。收发器MAX485的DI是发送数据输入，RO是接收数据输出，而DE和RE分别控制发送使能和接收使能。常见做法是将DE和RE接在一起，用单片机一个IO口控制：该引脚为高电平时允许发送，低电平时允许接收。这样能避免总线冲突，但也要注意切换时机，发送完最后一个字节之后不能立即拉低方向引脚，否则会截断停止位。

2.3 自定义帧协议还是Modbus RTU

多机通信必须解决“数据属于哪台设备”的问题。最简单的做法是自定义帧：从机地址、功能码、数据长度、数据体、校验字节。这种格式在51单片机代码里好维护，适合帧长固定、节点少的系统。另一种做法是直接使用Modbus RTU协议，一主多从的寻址方式已经定义好，主机读温湿度可以用功能码0x03读保持寄存器，或用0x04读输入寄存器。Modbus RTU的帧没有“长度”字段，靠字节间隔判断一帧的结束，空闲时间大于3.5个字符周期，就认为帧结束。

我一般建议：课程设计或快速原型用自定义帧，写起来直观；商用项目直接上Modbus RTU，后面接组态软件、触摸屏或上位机都方便。两者并不冲突，完全可以在从机内部先把DHT11数据存成寄存器，再把Modbus RTU的请求解析出来。

为了兼顾可读性和扩展性，本文的代码示例采用“Modbus RTU的地址和功能码结构、简化CRC校验”的方式。后续若要改成标准Modbus，只需要改帧解析部分，传感器采集和RS485收发函数不用动。

3. Proteus仿真图中的温湿度检测与RS485接口电路细节

3.1 在Proteus中放置单片机最小系统和DHT11模型

适用场景是直接通过STC89C52或AT89C51进行仿真。单片机的晶振电路用12MHz，串口波特率常用9600bps，定时器1工作在模式2，这样波特率误差较小。DHT11模型在Proteus中的引脚定义一般是VCC、DATA、GND，其中DATA引脚需要接一个4.7kΩ到10kΩ的上拉电阻，因为传感器数据引脚是开漏输出。

在具体接线时，推荐先把网络标签标好，再连线。DHT11的DATA引脚接单片机的P2.0；串口TXD接MAX485的DI，RXD接RO；方向控制引脚P1.0接DE和RE。Proteus仿真的优势是可以直接把虚拟终端并接到单片机的RXD和TXD上，方便在总线之外观察原始串口输出。需要注意，虚拟终端只能看TTL电平，看不到RS485总线的差分信号；要看A、B两线波形，可以用示波器直接点A和B网络。

3.1.1 MAX485自动收发电路接法

常见的手动方向控制电路只有四根连线：MAX485的RO接单片机RXD，DI接TXD，DE和RE合并后接一个普通IO。发送时，程序先把IO拉高，再写串口；发送完成后，在串口中断或主循环里把IO拉低。Proteus仿真中这样接完全可行，但需注意方向切换时间：MAX485的使能动作时间约为几百纳秒，在仿真中可忽略；真实硬件上，如果拉高方向引脚后立刻写SBUF，可能由于电容和阻抗导致第一字节丢位，建议先延时20到50微秒再写数据。

另一种是RS485自动收发电路，用三极管和电阻从TXD信号中衍生出方向控制。它省掉一个IO口，但仿真时需要注意模型是否支持三极管开关速度。自动收发电路的原理是：TXD空闲为高电平，经反向电路把DE/RE拉低，处于接收状态；发送数据时，起始位是低电平，反向后高电平使能发送。这类电路在和外部设备通信时很方便，但在某些单片机上会出现起始位畸变，建议实际打板前先做回环测试。

3.2 多机通信仿真工程的搭建方式

在Proteus里做多机仿真，不需要真实接入RS485转换器。常见做法是：复制两份“主机电路”和“从机电路”，放在同一个工程的不同区域，把各节点的MAX485的A和B用导线或标签连起来。标签能避免复杂连线，例如把主机的A标为NET_A，从机1的A也标为NET_A，从机2的A也标为NET_A，这样它们就在同一网络。必须注意所有节点必须共地，因此在Proteus中把各个电路模块的GND都接到同一个地。

Proteus仿真RS485时，逻辑分析上存在一个坑：如果两个从机的MAX485都处于接收模式，它们会把总线数据读回各自串口，这是正确的；但如果在同一帧内，两台从机同时把DE拉高并开始发送，仿真不会烧坏器件，但逻辑上会导致总线数据混乱，和真实硬件行为不完全一致。因此仿真时更要强调协议的状态机，最大限度避免同时发送。

下表是最常见的一个从机节点的引脚连接关系：

在仿真中，末端匹配电阻一般只在一台设备的A、B间加120Ω，而不是每台设备都加。真实485总线要求两端各加一个120Ω，但Proteus对反射模拟较弱，仿真中加一个即可。

4. 单片机源实现：DHT11读取、RS485收发与从机地址匹配

4.1 DHT11读取函数与位判断

单总线通信的特点是主机先发出起始信号，DHT11应答后连续送出40位数据。程序的关键在于延时函数是否能精确定位到微秒级。12MHz晶振下，_nop_()约等于1微秒，但使用while循环写延时更直观。

下面的读取函数采用“先拉低拉高然后读电平宽度”的方式，最后返回一个8位温度值和8位湿度值。对于仿真来说，关键点是读完每个字节后把数据写入临时数组，不要直接拼浮点数，以便后面组装帧。

#define DHT11_PIN P2_0 typedef struct { unsigned char humi; unsigned char temp; } DHT11_DATA; void DHT11_Delay_US(unsigned int us) { while (us--) { _nop_(); _nop_(); _nop_(); } } unsigned char DHT11_ReadByte(void) { unsigned char i, data_byte = 0; for (i = 0; i < 8; i++) { while (DHT11_PIN == 0); // 等待电平变高 DHT11_Delay_US(40); // 高电平持续40us以外为数据1 if (DHT11_PIN == 1) { data_byte = (data_byte << 1) | 0x01; } else { data_byte = (data_byte << 1) | 0x00; } while (DHT11_PIN == 1); // 等待电平变低 } return data_byte; } bit DHT11_ReadData(DHT11_DATA *dht) { unsigned char temp, humi; unsigned char check; unsigned char buf[5]; unsigned char i; DHT11_PIN = 0; DHT11_Delay_US(20000); // 主机拉低至少18ms DHT11_PIN = 1; DHT11_Delay_US(30); // 拉高20-40us if (DHT11_PIN == 0) { // 检测从机应答 while (DHT11_PIN == 0); // 等待应答低电平结束 while (DHT11_PIN == 1); // 等待高电平结束 for (i = 0; i < 5; i++) { buf[i] = DHT11_ReadByte(); // 连续读取40位 } check = buf[0] + buf[1] + buf[2] + buf[3]; if ((check & 0xff) == buf[4]) { dht->humi = buf[0]; dht->temp = buf[2]; return 1; } } return 0; }

代码逻辑不复杂：先发送低电平起始脉冲，再等待传感器的应答信号，应答结束后进入逐字节读取。每个字节读取时用高电平时长判断0或1。需要注意，上面的while (DHT11_PIN == 0)在仿真中必须配合上拉电阻，否则状态不对。DHT11的响应时间在20到40微秒左右，仿真模型通常不严格模拟高低电平宽度，但主循环加至少500毫秒的采样间隔，否则传感器来不及更新内部数据。

4.2 串口初始化与RS485方向切换

串口使用模式1，即8位数据、可变波特率。定时器1作为波特率发生器，在9600bps下，12MHz晶振初值为0xFD，误差约0.16%，不影响通信。接收端建议允许串口中断，帧接收采用“接收一批字节”的方式，而不是逐字节丢给主循环。

RS485发送方向切换的专门函数可以封装成下面这样：

void RS485_Send_Data(unsigned char *buf, unsigned char len) { unsigned char i; DE_RE = 1; // 拉高方向引脚，进入发送模式 DHT11_Delay_US(20); // 等待收发器切换稳定 for (i = 0; i < len; i++) { SBUF = buf[i]; while (!TI); TI = 0; } while (!TI); // 确保最后一个字节移位完成 TI = 0; DE_RE = 0; // 发送完成，恢复接收模式 }

很多初学者会把DE_RE = 0放在for循环内，结果发送完每个字节后立刻拉低方向引脚，导致后续字节发不出去。正确做法是所有数据写完并等待TI置1后，再拉低方向。在真实硬件上，停止位结束后还要留出1到2个字符宽度的时间，否则对方可能还没采样完最后一个字节。

接收端可以用一个数组缓存串口中断收到的字节。帧长度不固定时，需要同时记录接收计数和一个字节超时判断。最简单的方式是：串口每收到一个字节就重载定时器，超过一定时间认为一帧结束。在51单片机里，这个看门狗计时可以用定时器0实现，也可以用主循环轮询空闲时间。

4.3 从机地址识别与CRC校验

一主多从系统中，从机只有在帧地址与自身地址相同时才回复，否则忽略整帧数据。这样可以避免无关从机参与总线竞争。地址匹配代码一般放在串口接收完成之后，数据帧头第一个字节就是地址。

自定义帧格式定义为：

CRC校验可以选用CRC16/Modbus多项式0x8005。下面给出一个常见查表法函数，虽然占程序空间更大，但相比按位移位更稳，适合主循环反复调用。

unsigned short CRC16_Modbus(unsigned char *data, unsigned char len) { unsigned short crc = 0xFFFF; unsigned char i, j; for (i = 0; i < len; i++) { crc ^= data[i]; for (j = 0; j < 8; j++) { if (crc & 0x0001) { crc = (crc >> 1) ^ 0xA001; } else { crc >>= 1; } } } return crc; }

发送时把地址、功能码、数据长度和数据区依次填入数组，算出CRC后追加。接收时先判断地址，再校验CRC，校验通过后才解析数据。注意CRC16是小端输出，先发低字节，再发高字节，这和很多串口助手的显示顺序相反，排查帧错位时一定要看清楚。

4.3.1 主机轮询多个从机的代码骨架

主机侧不需要收数据时，只负责按照地址顺序发送请求帧，并等待从机回复。超时后重发或跳过。下面代码演示轮询两个从机的过程：

unsigned char req_frame[8] = {0x01, 0x03, 0x00, 0x02, 0x00, 0x02, 0x00, 0x00}; void Master_Poll_All(void) { unsigned char addr; unsigned int crc; for (addr = 1; addr <= 2; addr++) { req_frame[0] = addr; crc = CRC16_Modbus(req_frame, 6); req_frame[6] = crc & 0xff; req_frame[7] = (crc >> 8) & 0xff; RS485_Send_Data(req_frame, 8); Delay_MS(50); } }

主机的超时时间要多从几个维度考虑：如果总线波特率9600，8个字节的请求帧传输时间约为8×1.04ms=8.3ms；从机处理DHT11读取需要约20ms到50ms；因此轮询间隔不能小于100ms，否则从机还没回完，主机就发出下一帧，必然冲突。从机在收到请求后回复响应帧时，同样要先拉高DE再写串口，回复长度最好固定。

5. RS485一主多从组网、仿真联调与现场排错

5.1 在Proteus中搭建一主两从并设置不同的从机地址

仿真多机通信最稳妥的方法不是把逻辑画在一张原理图上，而是复制三份单片机子系统，分别命名为Master、Slave1、Slave2。每个子系统都要有独立的MAX485和DHT11，只是Sla1和Sla2的从机地址在代码中定义不同。主机的MAX485 A/B接总线标签，两个从机的A/B也接相同的总线标签。注意GND也要用同一个接地符号，否则差分共模电压在仿真中虽然不明显，但到真实布线上会成为通信不稳定的主要原因。

在从机代码中，地址常量定义最简单的方式是#define SLAVE_ADDR 0x01，每个子工程只改这一处。用同一个工程文件复制改代码，比在Proteus里动态修改地址更直观。当然也可以在单片机外部用拨码开关读取地址，比如P1口低3位拨码，这样仿真和实物一致，但代码里要增加按键消抖和地址读取，对新手并不友好。

表：一主两从中各模块的地址与功能

5.2 常见故障现象和解决步骤

现象1：从机能收到主机请求，但主机收不到从机回复。先检查从机代码中RS485方向引脚是否在发送完成后拉低。如果方向引脚一直为高，从机持续占用总线，主机自然无法接收。另一种可能是从机发送时，DE_RE拉高后没有延时，导致MAX485还没完全进入发送态。在Proteus中不明显，但真实硬件会丢首字节。

现象2：主机收到一帧乱码。用虚拟终端分别观察主机和从机的TXD，确认两边波特率一致，并检查SCON、TMOD和波特率初值是否配置相同现象3：总线无数据，主机读不到任何从机回复。重点检查所有MAX485的A和B是否接反，A接A，B接B，如果一条线接反，差分信号反相，接收方读到的是完全错误的数据。另一个检查点是匹配电阻：A、B之间不接电阻时，总线空闲态由偏置电阻决定，可能导致空闲时逻辑不定，通信时数据帧被淹没。

现象4：两个从机同时回复。这类问题的根因在主机轮询太急。主机发送完请求帧后，要在等待回复的超时窗口结束后再发下一帧，不能连续发两次同样地址的请求。更隐蔽的问题是，从机收到广播地址0xFF时，若代码不做处理，所有从机都会回复，这在单纯“点对多”轮询设计中属于逻辑错误。应当约定广播帧不回复。

在Proteus中排查这类问题时，我的做法是给每个节点加一个发光二极管，主机发送时LED闪烁，从机回复时LED闪烁。这样能直观看到哪台设备在占用总线，避免一直盯着虚拟终端里滚动速度过快的十六进制数据。

5.3 仿真和真实硬件之间的细节差距

Proteus对RS485收发器的仿真相对理想化，它不会模拟长线缆阻抗、分布电容或共模干扰。因此仿真通过后，直接拿到真实硬件上跑仍然可能遇到问题。常见差距包括：

• 真实RS485总线末端必须接120Ω匹配电阻，仿真只加一个也可能通过，真实系统中总线两端都要加。
• 方向切换时间在仿真中被忽略，真实硬件必须增加延时。
• DHT11时序对晶振频率敏感，Proteus中使用的12MHz模型和真实STC单片机可能因为指令周期不同导致读取偏差。
• 真实环境中需要加TVS管和PTC自恢复保险丝，防止雷击或误接强电损坏MAX485。

从仿真移植到硬件时，不要直接复制代码。先把PCB上的收发器接线核对一遍，再通过USB转485模块连接电脑串口助手做单节点回环测试，然后再组网。

6. 验证RS485多机通信可靠性的三个高级技巧

6.1 用虚拟串口和串口调试助手自动回环测试

Proteus的COMPIM组件可以把单片机串口映射到电脑的虚拟串口。打开两个虚拟串口，用虚拟串口软件把COM1和COM2相连，一个接主机仿真，一个接电脑上的Python脚本仿真主机。这样可以用Python里的serial库读取从机回复并自动计算CRC，快速验证从机帧格式是否正确。具体步骤是：先在设备管理器安装虚拟串口驱动，再在Proteus中配置COMPIM的COM端口，然后运行脚本。

import serial import struct def crc16_modbus(data: bytes) -> int: crc = 0xFFFF for byte in data: crc ^= byte for _ in range(8): if crc & 1: crc = (crc >> 1) ^ 0xA001 else: crc >>= 1 return crc ser = serial.Serial('COM2', 9600, timeout=1) req = bytes([0x01, 0x03, 0x00, 0x02, 0x00, 0x02]) crc = crc16_modbus(req) frame = req + struct.pack('<H', crc) ser.write(frame) resp = ser.read(8) print('response:', resp.hex())

这段脚本模拟主机发送请求，等待从机回复。如果从机应答后，脚本没有抛出异常，说明帧格式和通信逻辑正常。用Python而不是仿真虚拟终端的好处是能批量测试不同地址和大量轮询，还可以故意发送错误CRC看从机是否忽略，这比肉眼观察十六进制数据更高效。

6.2 故意注入错误参数观察从机行为

验证从机地址识别是否可靠，可以在主机代码中临时把发送地址改成0x00或0xFF，正常情况从机不应回复。然后发送一个CRC错误的帧，从机也应保持静默。若从机仍然回复，说明接收逻辑里没有正确判断地址或CRC。这项测试不要只在Proteus里做，换到真实串口助手上同样执行一遍，因为真实串口工具能显示每个字节间隔，更容易判断从机是不是把坏帧拆成了多帧。

6.3 在仿真中观察RS485自动收发电路的波形

如果项目采用自动收发电路，Proteus中可以通过示波器同时观察TXD波形和DE/RE控制信号。将示波器A通道接TXD，B通道接三极管集电极或MAX485的DE引脚。发送一帧数据时，DE应当在起始位拉高，在停止位结束后拉低。若DE上升沿滞后于TXD起始位，说明RC延时过大；若DE提前拉低，则最后一个字节必然被截断。通过调整基极电阻和电容值，让DE高电平时间覆盖整个数据帧，这个调试方法能让自动收发电路在实机上少走弯路。

以上验证技巧都不需要额外增加硬件，在Proteus原有工程上给网络节点加探针即可完成。实际产品组网时，再增加一个隔离电源或磁耦隔离的RS485收发芯片，就能把仿真中验证过的帧状态机稳定运行在工业现场。

本文还有配套的精品资源，点击获取