简介：本资源是一套面向嵌入式初学者与课程设计者的51单片机综合实践项目，聚焦温湿度监测与阈值报警功能实现，适用于电子类专业实训、毕业设计及Proteus仿真入门学习。资源包共44个文件，涵盖Proteus仿真工程、Keil C源代码（含main.c、DHT11.c、lcd1602.c等核心模块）、原理图（SchDoc格式）、流程图（BMP/PDF）、元件清单（XLS）、功能说明文档（TXT/PDF）及编译生成文件（HEX、OBJ、LST等），完整呈现从硬件设计、软件编程到仿真验证的全流程。压缩包仅801KB，结构清晰、即开即用，所有代码均带注释，LCD1602显示逻辑与DHT11通信协议已封装调试，支持按键设置温湿度上下限并实时触发蜂鸣报警。目前已有282人下载学习，是掌握传感器驱动、人机交互界面开发及单片机中断/定时应用的典型参考案例。 做单片机课程设计或者毕业设计的人，十有八九都绕不过“51单片机+DHT11+LCD1602+Proteus仿真”这套经典组合。我在带学生做项目的时候，见过太多人卡在同一个地方：Proteus仿真图画好了，代码也烧进去了，结果LCD1602死活不显示，或者DHT11读出来的温度湿度永远是0。如果你正在被这些事折磨，这篇文章就是给你写的。
这篇文章不会讲那些云里雾里的理论，我直接把我做“1593-基于51单片机的温湿度报警系统”这套东西的全过程拆开给你看，包括硬件原理图怎么画、DHT11到底怎么读数据、LCD1602初始化为什么必须按那个顺序来、报警阈值怎么设置，以及Proteus仿真里那些不试不知道的坑。每个环节我都会说明白背后的道理，而不是只丢给你一份“能跑就行”的代码。你在完成自己的课程设计或者复现这个项目时，直接照着我这个思路做，能少走至少一半弯路。
1. 这套系统架构到底在做什么——模块拆解与选型逻辑
先别急着打开Proteus画图，花五分钟搞清楚一套系统由哪些部分组成、每个部分为什么存在，后面所有工作都会顺很多。做技术项目最忌讳的就是“代码凑出来了、仿真跑通了，但别人一问原理就卡壳”，答辩现场这种场面我见太多了。
1.1 功能需求拆解
这套温湿度报警系统，说白了就解决一个问题：环境里的温度和湿度超过某个范围时，设备要能及时发现并提醒你。拆开来看，需要完成这几件事：
- 实时采集当前环境的温度与湿度数据，测量精度至少到1℃和1%RH，这是DHT11的基本能力；
- 把数据直观地显示出来，不能只给个代码里有、人看不见的死数据，所以需要LCD1602屏幕；
- 当温度或湿度超过用户预设的报警阈值时，自动触发声光报警（蜂鸣器响、LED灯闪烁）；
- 用户能在不修改程序的前提下调整报警阈值，否则每次改阈值都重新烧一次程序，完全不实用，所以需要按键输入模块。
这四个需求对应到硬件上，就是四个被验证过无数次的成熟模块：主控用51单片机（课设/毕设最稳妥的选择）、传感器用DHT11、显示用LCD1602、报警用蜂鸣器加LED。整个系统的信息流是单向的：DHT11把物理世界的温湿度变成数字信号，单片机负责处理判断，LCD1602把结果给人看，超限时报警器件被驱动。
1.2 为什么是“51单片机+DHT11+LCD1602”这个固定组合
很多人选型的时候纠结半天，问我要不要换STM32、要不要用OLED屏、传感器换成SHT30是不是更高级。我的建议很直接：如果你做的是课程设计、毕业设计或者练手项目，这套组合就是最优解，没有之一。
51单片机的核心优势不是性能，而是资料完整度极高。无论是郭天祥的教程、江协科技的网课，还是各种论坛里的例程，随便一搜就是大把可参考的代码。项目出问题时你百度一下，基本都能找到前人踩坑的记录。而且51单片机在Proteus里的仿真模型非常成熟，几乎不会出现“仿真跑不通”这种平台性问题。
DHT11的应用价值在于它用一根线（单总线协议）就能同时传温度、湿度两组数据，硬件接线极其简单。性能参数是粗糙了一点（温度精度±2℃，湿度精度±5%RH），但对于“监测种植大棚、机房、仓库环境是否越界”这类场景，完全够用。真正做高精度科研测量的人不会用DHT11，但那个需求层次和这个项目不是一个赛道。
LCD1602则是字符型液晶里最经典的一款，能显示两行，每行16个字符，ASCII字符和自定义字符都支持。这个项目只需要显示温度和湿度数值，LCD1602简直就是量身定做的。做实物时它也非常皮实耐用，比那些需要SPI/IIC时序的OLED多了一层“怎么炸都能点起来”的容错性。
1.3 报警系统的两种工作模式和阈值设定思路
报警逻辑看起来简单，但这里有一个很多新手没考虑过的设计问题：阈值是写死在程序里的还是用户可调的？如果是写死的，程序里定义两个常量就行；如果是可调的，就需要额外的按键和存储器（通常是EEPROM或者直接存在RAM里，掉电丢失也无所谓）。
我建议在这个项目里做成**“开机默认阈值+按键实时调节”**的混合模式。原因是课设答辩时，老师极大概率会问“阈值的设定依据是什么”或者现场让你调一个阈值看看效果。如果只能改代码再烧录，演示效果会大打折扣。而用按键调节，当场就能演示“把阈值调到当前温度以下，蜂鸣器立刻响”的完整链路，既有说服力又直观。
阈值调节的数据流向是这样的：按键触发外部中断或扫描检测，MCU识别后修改RAM中的阈值变量，同时把新阈值刷新到LCD1602的设定值显示区域，报警比较逻辑每次采样后都用最新阈值做判断。整个过程不需要写Flash，所以断电后阈值恢复默认值，对课设来说完全没问题，靠代码里的初始定义就行。
2. 硬件设计细节：从原理图到实物的关键节点
很多人画原理图就是照着网上的图连一遍，连完也说不清为什么这个电阻要接在那里。这一节我把每个硬件模块的设计逻辑讲透，你画图的时候就知道自己为什么要连那根线了。
2.1 最小系统电路：振荡、复位、供电一个都不能少
51单片机要正常工作，必须具备最小系统三件套：电源、时钟、复位电路。
电源部分，Proteus仿真里你直接给VCC和GND标注就行，不用真的接电源芯片；做实物时通常用5V USB供电或者7805稳压模块。注意AT89C52和STC89C52的引脚完全兼容，但STC系列支持3.3V~5.5V宽压，AT89C52基本只能5V，做实物前先确认你手里的单片机型号。
时钟电路是设计里最容易被忽略的一个环节。51单片机通常用12MHz晶振，这个频率下1个机器周期是1μs（12个时钟周期为一个机器周期），定时器初值计算特别方便。当然你也可以用11.0592MHz，它的好处是串口波特率能做到整数，但你这个项目没有用到串口通信，所以12MHz更顺手。晶振两端各接一个20~30pF的负载电容到地，这个电容的作用是匹配晶振的负载谐振条件，保证起振稳定。
复位电路的设计参数是这样的：RST引脚通过一个10μF电解电容接到VCC，再通过一个10kΩ电阻接地。上电瞬间电容相当于短路，RST引脚被拉到高电平触发复位，然后电容慢慢充电，RST电压下降，单片机开始运行。按键复位就是在RST和VCC之间并一个按键，按下时强制把RST拉高。这套电路是51单片机的标准配置，千万别为了省两个元件把它去掉，否则程序下载后经常出现“跑飞”现象。
2.2 LCD1602的接法与P0口上拉电阻这个老话题
LCD1602是16脚器件，其中数据线D0~D7、控制线RS、RW、EN占了11个关键引脚，再加上电源和背光，基本就要占用整个单片机一半以上的IO口。为了省引脚，我强烈推荐你用4位模式：只接DB4~DB7四根数据线，高4位和低4位分两次发送。这样可以把IO口占用从11个降到7个，剩下的IO口留给按键和报警电路，刚刚好。
接线方案我建议这样分配：
| 功能 | 单片机引脚 | 说明 |
|---|---|---|
| RS | P2.0 | 寄存器选择：0写指令、1写数据 |
| RW | P2.1 | 读写选择：0写、1读 |
| EN | P2.2 | 使能信号，下降沿锁存数据 |
| DB4 | P2.3 | 数据线第4位 |
| DB5 | P2.4 | 数据线第5位 |
| DB6 | P2.5 | 数据线第6位 |
| DB7 | P2.6 | 数据线第7位 |
| V0 | 接电位器 | 液晶对比度调节，通常接1k~10k电位器中间抽头 |
| A/K | 接5V/GND | 背光正负极，串一个10~20Ω电阻限流 |
这里要强调一个经典的硬件坑：51单片机的P0口是开漏输出，内部没有上拉电阻。如果你把LCD1602的数据线接在P0口，必须先外接4.7kΩ或10kΩ的上拉排阻到VCC，否则输出高电平时电平不确定，液晶会显示乱码或者直接黑块。很多人在Proteus里用P0口也遇到同样问题，因为Proteus的仿真模型同样会模拟开漏特性。最省事的办法是把LCD1602数据线全部接到P2口，绕开P0口的上拉问题，我给的方案就是这么做的，接实物时能少焊8个电阻。
2.3 DHT11的硬件连接与抗干扰设计
DHT11最简单的接法就是一根信号线：DATA引脚接单片机某个IO口（我习惯接P3.7），VCC接5V，GND接地。但千万不要直接裸接，DATA和VCC之间必须加一个5kΩ~10kΩ的上拉电阻。DHT11的通信协议是单总线，空闲时总线靠这个上拉电阻维持高电平，DHT11应答时通过把总线拉低来发送起始信号。如果去掉上拉电阻，信号线上的高电平会“浮空”，读数据基本必失败。
实物接线还有一个容易被忽略的细节：DHT11的供电线和信号线如果距离较长（超过20cm），建议在DHT11的VCC和GND之间并一个0.1μF的瓷片电容做去耦，防止电机、继电器等感性负载启停时产生的电源尖峰干扰DHT11内部的测量电路。这个电容在Proteus仿真里可以不加，但实物建议必须有。
2.4 报警电路设计：蜂鸣器PNP型三极管驱动与LED限流电阻计算
报警电路由两部分组成：蜂鸣器（有源型，5V）和LED指示灯。
蜂鸣器不能直接接单片机IO口，因为51单片机IO口最大灌电流也就20mA左右，而一般的蜂鸣器工作电流在30mA以上，直接驱动既带不动又会把IO口烧坏。正确做法是用一个三极管做电流放大，我用的是PNP型8550。驱动逻辑是这样的：当P1.0输出低电平时，PNP三极管的基极-发射极电压差大于0.7V，三极管导通，蜂鸣器通电发声；当P1.0输出高电平时，三极管截止，蜂鸣器不响。注意51单片机上电默认IO口是高电平，所以蜂鸣器电路接在P1.0上，系统上电时不会误响，这也算设计上的一个巧劲。
LED指示灯同样需要限流电阻。LED正向压降按2V算，工作电流取10mA左右，电源电压5V，限流电阻计算如下：
$$R = \frac{V_{CC} - V_{LED}}{I_{LED}} = \frac{5V - 2V}{10mA} = 300\Omega$$
所以选一个330Ω或470Ω的标准电阻都行。把LED接在P1.1上，用灌电流方式驱动——输出低电平时LED亮，这样和蜂鸣器的触发逻辑保持一致：报警时P1.0和P1.1同时置低。
3. Proteus仿真的完整实操：从建图到跑通的四个阶段
Proteus仿真是这套项目里最容易让人心态崩掉的部分，但90%的问题其实都出在元件选错、引脚接错、模型不兼容这三类原因上。我按自己的操作流程带你把仿真图完整跑一遍。
3.1 新建工程与元件选型：把元件库用明白
打开Proteus 8 Professional，新建工程时选择“New Project”，原理图绘制界面出来后，点击左侧工具栏的“Component Mode”（元件模式），再点“P”（Pick from Libraries）进入元件搜索库。这里必须输入正确的元件关键词，搜错了后面全是坑。
需要添加的元件清单如下：
| 元件名称 | 搜索关键词 | 仿真模型说明 |
|---|---|---|
| 单片机 | AT89C52 | 与STC89C52引脚兼容，Proteus自带模型 |
| 温湿度传感器 | DHT11 | Proteus 8 自带，需注意模型行为 |
| 液晶显示 | LM016L | 这就是LCD1602在Proteus里的标准模型名 |
| 蜂鸣器 | BUZZER | 选有源蜂鸣器模型，通常是SOUNDER |
| 按钮 | BUTTON | 用于复位和阈值调节 |
| 电阻 | RES | 按阻值分别搜索 |
| 电容 | CAP | 晶振负载电容选CAP，复位电容选CAP-ELEC |
| 晶振 | CRYSTAL | 搜索CRYSTAL，默认12MHz |
| 发光二极管 | LED-RED等 | 按颜色选 |
| 三极管 | PNP | 用2N3906或BC327之类的PNP管 |
| 上拉排阻 | RESPACK-8 | 如果LCD接P0口才需要，接P2口可省略 |
一个很多人会犯的错误是：搜“LCD1602”搜不到，因为Proteus里的模型名字是LM016L，属于字符型液晶，功能完全等效。搜“蜂鸣器”搜出来的很多是BUZZER模型，它在你给高电平时响、低电平时不响，跟实物的接法恰好相反。我建议用带内置振荡电路的SOUNDER模型，它的响应逻辑是低电平导通启动声音报警，和硬件设计里PNP三极管那套驱动逻辑是对应的。如果你发现仿真里蜂鸣器怎么都不响，大概率是元件的“响应极性”反了，把这个搞清楚比乱试半天强得多。
3.2 DHT11在Proteus中的行为特性：和实物有哪些微妙差异
DHT11在Proteus里的仿真模型和实物存在两个非常容易误导人的差异。
第一个差异是：在Proteus里，DHT11的仿真模型默认输出的温湿度是一个可手动调节的模拟值，通常通过双击DHT11元件、在弹出的属性窗口里可以手动设置温度和湿度初值。有的版本里你甚至需要在仿真运行时用鼠标在元件附近滑动来改变值，或者通过添加信号源/滑动变阻器来模拟环境变化。这就意味着一件事：仿真的目的不是让你验证“传感器测出来的数据对不对”，而是让你验证“单片机拿到数据之后处理得对不对”。如果你在仿真里看DHT11的读数一直是固定的25℃和60%RH，别慌，这是模型特性，不是程序写错了。
第二个差异是：真实DHT11的数据采集周期非常慢，一次完整测量需要几十毫秒，而且官方手册要求两次读取间隔不得小于1秒；Proteus模型对此做了简化，通常不严格模拟这个时间窗。但你的代码里无论如何都要保留至少1秒的采样间隔。为什么？因为我现在做的是仿真，你以后迟早要烧到实物里，实物DHT11就是有这个硬性限制，你要是连续读，它就返回0。把这个限制直接写进代码里，一套代码两端通吃，省得后续移植时踩坑。
3.3 LCD1602仿真的三个经典坑
LCD1602（LM016L）在Proteus里最常见的问题有三个。
第一是不显示任何内容。多数原因是对比度引脚V0没接对。在仿真里，你不需要接电位器，直接把V0引脚接地即可。仿真模型对V0电压很敏感，V0悬空或者电压不对，屏幕就是白板一块。有同学喜欢给V0接个可变电阻好看，但调不好反而出问题，直接接地最省事。
第二是屏幕出现一排黑方块。这个原因通常是RS/RW/EN三条控制线接错，或者数据线高低位接反了。我用4位模式时，DB4~DB7必须依次接到单片机引脚上，不能跳着接。代码里写的是0x30、0x30、0x30、0x20这样一串初始化指令，如果数据线接错，初始化序列传进去就是乱的，液晶就花屏。
第三是仿真运行后液晶什么都没显示，但代码好像也没错。这时候你要检查的往往不是程序，而是单片机有没有真正跑起来。双击单片机模型，把“Clock Frequency”改成12MHz，检查Program File有没有正确加载hex文件。如果hex文件路径是空的，单片机就是空的，什么都不会执行。这个错误低级但极其常见，我见过好几个人卡了半个小时才发现根本没有烧录hex文件。
3.4 仿真运行调试技巧：虚拟终端与逻辑分析仪你会用吗
Proteus有个非常好用的调试工具叫“Virtual Instruments”（虚拟仪器），里面包括虚拟终端（Virtual Terminal）、逻辑分析仪（Logic Analyzer）等。虽然这个项目不需要串口通信，但我强烈建议你临时写一个串口发送函数，把DHT11读到的原始数据通过虚拟终端打印出来，这样你能立刻判断传感器数据协议解析对不对。
具体做法：在单片机P3.1（TXD）引脚接一个“Virtual Terminal”元件，代码里用串口发送一个字节数据的函数，把DHT11读到的湿度整数、湿度小数、温度整数、温度小数和校验和全部发出来。如果虚拟终端上显示的五个字节满足“湿度整数+湿度小数+温度整数+温度小数 = 校验和”的关系，说明你的时序代码是对的。这个调试方法的意义在于，它能帮你把“传感器协议问题”和“LCD显示问题”分离开来：虚拟终端的数据对了，说明软件读取没问题，问题在LCD驱动；虚拟终端数据不对，说明DHT11时序有问题，LCD再花屏你也别管它。一步一步排查，不用坐在那Debug半天猜原因。
4. 软件核心逻辑与关键代码：时序、状态机与阈值控制
硬件是骨架，软件才是灵魂。DHT11的驱动是这个项目里技术含量最高的部分，它的难点不在于程序有多长，而在于单总线协议要求的微秒级时序必须严格满足。这一节我把程序设计思路和核心代码全部放出来，用的开发环境是Keil C51，单片机型号选AT89C52，编译后生成hex文件直接烧进Proteus。
4.1 整体程序流程与状态设计
程序的主循环是一个经典的“后台循环+定时中断”结构，逻辑分三层：
- 初始化层：上电后依次完成LCD1602初始化、DHT11检测、系统默认报警阈值载入、开机画面显示；
- 采样层：约每2秒主动触发一次DHT11温度湿度采集，读取成功后更新全局变量，读取失败则显示错误代码（如湿度显示ERR）；
- 报警判断层：每次采样完成后，立即把当前温度与温度上限阈值比较、当前湿度与湿度上限阈值比较，有任何一个越界就置位报警标志；同时不断扫描按键，检测到阈值调节按键后重新计算新的阈值并刷新显示。
为什么不让DHT11连续采集？除了前面说的物理限制，还有一个好处：主循环在“等待2秒采样周期”期间可以去扫描按键、刷新LCD显示，系统响应更灵活。如果写成阻塞式连续读DHT11，单片机的CPU全耗在延时里，按键扫描就会卡顿，用户体验很差。程序全局状态就用几个全局变量：temp_value、humi_value、temp_alarm_threshold、humi_alarm_threshold、alarm_flag，模块之间靠这些全局变量传递信息即可。
4.2 DHT11单总线驱动代码：微秒级时序是关键
DHT11单总线通信协议的完整时序是这样的：主机先把总线拉低至少18ms，然后释放总线，DHT11检测到起始信号后拉低总线80μs作为响应，再拉高80μs准备发送数据。之后每个bit都以50μs低电平作为前缀，后续高电平持续26~28μs代表数据“0”，持续70μs代表数据“1”。整个40bit数据按“湿度整数、湿度小数、温度整数、温度小数、校验和”的顺序发出。
对应到51单片机的代码，最常用的驱动写法是这样的：
// 延时函数，基于12MHz晶振，1个机器周期=1us void delay_us(unsigned int us) { while(us--) { _nop_(); _nop_(); _nop_(); _nop_(); } } void delay_ms(unsigned int ms) { unsigned int i, j; for(i=ms; i>0; i--) for(j=110; j>0; j--); } // 复位DHT11并检测响应信号 bit DHT11_Start() { bit response = 0; DHT11_PIN = 1; // 总线空闲状态 delay_us(2); DHT11_PIN = 0; // 主机拉低总线 delay_ms(20); // 拉低至少18ms DHT11_PIN = 1; // 释放总线 delay_us(30); // 等待DHT11响应 if(DHT11_PIN == 0) { // 检测响应低电平 response = 1; delay_us(80); // 跳过80us低电平 if(DHT11_PIN == 1) // 再检测80us高电平 response = 1; else response = 0; delay_us(80); } return response; } // 读取一个bit unsigned char DHT11_ReadBit() { unsigned char bitValue = 0; while(DHT11_PIN == 0); // 等待50us低电平结束 delay_us(30); // 延时后采样 if(DHT11_PIN == 1) bitValue = 1; while(DHT11_PIN == 1); // 等待高电平结束 return bitValue; } // 读取一个字节 unsigned char DHT11_ReadByte() { unsigned char i, dataByte = 0; for(i=0; i<8; i++) { dataByte <<= 1; dataByte |= DHT11_ReadBit(); } return dataByte; } // 读取完整温湿度数据，成功返回1，失败返回0 bit DHT11_ReadData(unsigned char *humi_int, unsigned char *humi_dec, unsigned char *temp_int, unsigned char *temp_dec) { unsigned char check = 0; if(!DHT11_Start()) return 0; *humi_int = DHT11_ReadByte(); *humi_dec = DHT11_ReadByte(); *temp_int = DHT11_ReadByte(); *temp_dec = DHT11_ReadByte(); check = DHT11_ReadByte(); if((*humi_int + *humi_dec + *temp_int + *temp_dec) == check) return 1; return 0; }这套代码里的关键点有两个。
第一是delay_us的精度。51单片机在12MHz晶振下，一个机器周期恰好是1μs，_nop_()指令占用一个机器周期，所以用一个while循环嵌套几个_nop_()就是几个微秒的延时。如果你换成11.0592MHz晶振，一个机器周期变成了1.085μs，延时就会偏大，读数据的时序可能飘，所以前面我特意强调选12MHz晶振。
第二是DHT11_Start函数里的响应检测逻辑。DHT11的完整响应信号是“80μs低电平+80μs高电平”，很多精简代码只检测一次低电平就完事，这样容易把噪声误判成设备响应。我的写法是先检测低电平、再跳过80μs、再检测高电平，两边都对才算应答成功，容错性明显更好。实际使用中这个方法可以显著降低读不出数据的概率。
4.3 LCD1602显示驱动代码：4线模式初始化序列详解
LCD1602的初始化是所有51项目里最容易出错的地方之一，因为很多人不理解为什么发送指令之前要反复延时。其背后原因是：LCD1602内部控制器上电后需要时间稳定，而且每条指令执行都有固定耗时（比如清屏需要1.64ms），MCU发指令的速度远快于LCD的处理速度，不加延时就会丢指令。
4线模式初始化序列我直接给你可用的版本：
#define LCD_RS P2_0 #define LCD_RW P2_1 #define LCD_EN P2_2 #define LCD_D4 P2_3 #define LCD_D5 P2_4 #define LCD_D6 P2_5 #define LCD_D7 P2_6 void LCD_WriteNibble(unsigned char nibble) { LCD_D4 = (nibble >> 0) & 0x01; LCD_D5 = (nibble >> 1) & 0x01; LCD_D6 = (nibble >> 2) & 0x01; LCD_D7 = (nibble >> 3) & 0x01; // 产生一个高电平脉冲，下降沿锁存数据 LCD_EN = 1; delay_us(2); LCD_EN = 0; delay_us(50); } void LCD_WriteCmd(unsigned char cmd) { LCD_RS = 0; // 指令模式 LCD_RW = 0; // 写模式 LCD_WriteNibble(cmd >> 4); // 先发高4位 LCD_WriteNibble(cmd & 0x0F); // 再发低4位 } void LCD_WriteData(unsigned char dat) { LCD_RS = 1; // 数据模式 LCD_RW = 0; LCD_WriteNibble(dat >> 4); LCD_WriteNibble(dat & 0x0F); } void LCD_Init() { delay_ms(20); // 上电等待 LCD_WriteNibble(0x03); // 第一次设置8位模式 delay_ms(5); LCD_WriteNibble(0x03); // 第二次设置8位模式 delay_us(150); LCD_WriteNibble(0x03); // 第三次设置8位模式 delay_us(150); LCD_WriteNibble(0x02); // 切换到4位模式 delay_us(150); LCD_WriteCmd(0x28); // 4位模式、2行、5x7点阵 LCD_WriteCmd(0x0C); // 开显示、关光标 LCD_WriteCmd(0x06); // 地址自动加1 LCD_WriteCmd(0x01); // 清屏 delay_ms(2); } void LCD_SetCursor(unsigned char row, unsigned char col) { unsigned char addr; if(row == 0) addr = 0x80 + col; else addr = 0xC0 + col; LCD_WriteCmd(addr); } void LCD_ShowString(unsigned char row, unsigned char col, unsigned char *str) { LCD_SetCursor(row, col); while(*str) { LCD_WriteData(*str++); } }这段代码的初始化序列有讲究：前面发三次0x03、再发一次0x02，是在跟LCD1602“对齐接口模式”——因为上电后控制器默认是8位模式，你先用8位模式给它发0x03，连续三次确保它稳定接收到，然后发0x02通知它“我要切换成4位模式了”。很多精简代码省略了这个过程，直接发0x28，在4位模式下会翻车。
显示内容的写法也很直观，比如开机界面显示两行字，一行是“Temp: 25 C”,另一行是“Humi: 60%RH”。温度值转成字符串时，因为DHT11返回的是整数和小数两字节，直接拼进字符串即可。
// 显示温湿度 void LCD_ShowTempHumi(unsigned char temp_int, unsigned char temp_dec, unsigned char humi_int, unsigned char humi_dec) { unsigned char displayStr[17]; sprintf(displayStr, "Temp: %d.%d C", temp_int, temp_dec); LCD_ShowString(0, 0, displayStr); sprintf(displayStr, "Humi: %d.%d %%RH", humi_int, humi_dec); LCD_ShowString(1, 0, displayStr); }注意%在sprintf里是转义字符，要显示百分号得写%%，这是C语言的老规矩，刚接触的人经常在这里翻车。
4.4 报警判断逻辑与按键阈值调节
报警逻辑的代码非常简单清晰，核心思路就是一个标志位加一次比较：
#define TEMP_ALARM_HIGH_DEFAULT 30 // 默认温度报警上限：30℃ #define HUMI_ALARM_HIGH_DEFAULT 70 // 默认湿度报警上限：70%RH unsigned char temp_alarm_threshold = TEMP_ALARM_HIGH_DEFAULT; unsigned char humi_alarm_threshold = HUMI_ALARM_HIGH_DEFAULT; bit alarm_flag = 0; void Alarm_Check() { alarm_flag = 0; if(temp_int >= temp_alarm_threshold) { alarm_flag = 1; } if(humi_int >= humi_alarm_threshold) { alarm_flag = 1; } P1_0 = alarm_flag ? 0 : 1; // 蜂鸣器低电平触发 P1_1 = alarm_flag ? 0 : 1; // LED低电平点亮 }按键调节部分，我用两个按键分别调节温度阈值和湿度阈值，支持“长按连加”和“单击加”。注意按键扫描要去抖，否则一次按键可能被识别成多次，阈值跳变非常恼人。软件去抖的标准做法是检测到低电平后延时10~20ms再确认一次，确认确实是低电平才执行按键功能。
调节阈值时顺便把当前阈值显示到液晶第三行不行？不行，LCD1602只有两行。所以我的方案是：正常显示模式下第一行显示温度、第二行显示湿度；当按键处于“调节温度阈值”状态时，第一行改为显示“Set Temp: xx C”，第二行显示当前实测温度，这样既能看到设定值、又能对比实测值，调节逻辑非常直观。调完温度后，再按确认键切换到湿度阈值调节界面，同理操作。
5. 调试经验与踩坑实录：三个经典案例的完整排查链路
这一节是我对这个项目最有价值的部分。下面这几个坑，是每一届做这个题目的学生几乎都会踩一遍的，我把完整的排查思路写出来，你以后遇到类似问题时可以照着这个链路走一遍，比漫无目的地改代码有效得多。
5.1 案例一：DHT11读出来的数据永远是0或者恒定值
这是最高频的问题。排查链路应该是这样的：
第一步，先确认时序是否满足要求。用Keil的软件仿真或者实际运行，在DHT11_Start函数返回后加一个临时断点，看返回标志位是什么。如果返回0，说明DHT11根本没有应答，问题出在起始信号或者硬件连接上。检查delay_us的延时是否准确，特别是晶振频率是不是12MHz。我曾见过有人代码里写的是12MHz的延时，实际板子上焊的是11.0592MHz晶振，DHT11时序整体偏慢，应答信号差了几十微秒就失败了。
第二步，确认采样周期。DHT11官方手册明确要求两次读取间隔必须大于1秒。如果你在主循环里不停地调用DHT11_ReadData，第二次开始就会读取失败，返回值全为0。解决办法就是前面说的，用一个标志位或者定时器，保证每次读取间隔在1秒以上，实测最稳妥是2秒。
第三步，确认校验和逻辑。DHT11的校验规则是“湿度整数+湿度小数+温度整数+温度小数=校验字节”。有人说把小数位也读出来自己处理太麻烦，干脆只读整数部分，那校验和就永远对不上。记住：就算你最终只显示整数，也必须把五个字节完整读完、完整校验，否则协议就是错的。
5.2 案例二：LCD1602花屏、黑块、只亮背光无字符
LCD不显示是最破坏心情的问题，但九成原因都可以归到下面四类。
第一类是初始化序列不对。4位模式下，如果你跳过了“三次0x03加一次0x02”的引导阶段，直接发0x28，液晶大概率显示乱码。按我上面给的LCD_Init顺序来，一个延时都不要省。
第二类是控制线接错。RS、RW、EN这三根线的状态组合决定了你发出去的是指令还是数据，任何一根接反，液晶收到的内容就是乱的。最恶心的是一开始画原理图时RS和RW接反了，代码检查半天发现不了。用万用表量一下引脚到单片机的通路，确认接线无误再往下查。
第三类是仿真模型V0引脚悬空或者电压不对，这个前面B节已经说过，仿真里V0直接接地。
第四类是P0口没加上拉电阻。如果你把LCD数据线接在P0口，又不加上拉，仿真和实物都会出现“时好时坏”的诡异现象。能换P2口就换P2口，不能换就老老实实加上拉排阻。
5.3 案例三：仿真模式下报警一直响，或者怎么都不响
报警一直响的问题通常出在蜂鸣器模型类型上。如果你用的是BUZZER模型，它的触发逻辑可能是“高电平响”，而我们的驱动电路设计的是“低电平导通”，仿真里就会出现逻辑颠倒。这不是代码问题，是元件模型问题。换成SOUNDER模型，或者把输出逻辑取反，就能解决。
报警怎么都不响的问题，先检查比较逻辑：阈值是用>=还是>？如果当前温度恰好等于阈值，用>就会漏报。再检查报警输出引脚有没有被复用，如果你把P1.0同时接了指拨开关或按键，IO口的电平被外部设备拉住了，单片机再怎么写0也驱动不了。仿真里可以用虚拟示波器或者电压表直接量P1.0引脚的电压，如果代码逻辑正确但引脚电压不对，一定是电路连接问题。
5.4 最后分享几个实用小技巧
经验一：程序里尽量多用宏定义和条件编译。我所有代码里开关DHT11、LCD1602用的都是#define，更换引脚时只改一处宏就行，不用全局搜索替换。项目做完之后如果想换个引脚布局，能省出半天时间。
经验二：做实物时把DHT11的引脚朝上焊接，而不是平贴在PCB上。因为DHT11外壳上的小孔是感湿通风孔，如果紧贴PCB下面，空气流通不畅，湿度测量会偏高好几个点。这个细节不提醒，很多人根本注意不到。
经验三：Proteus仿真跑完一遍后，不要只满足于“跑通了”，你可以故意改乱一个参数（比如把DHT11上拉电阻改成100kΩ），观察现象会怎么变化。用这种方式理解电路的工作边界条件，比做十遍重复仿真都有用。我带了这么多届学生，最后真正能拿高分的，都是那些肯花时间做这种“破坏性实验”的人，因为他们答辩时面对老师的提问完全不慌——这些问题他们全都已经自己踩过一遍了。
做这个项目的完整链路到这里就走完了：从需求拆解到硬件设计，从Proteus仿真到软件调试，最后是实物焊接时防坑。你在做自己那一版的时候，完全可以拿我这套思路当参考框架——先保证DHT11能读到有效数据，再搞定LCD1602正常显示，最后加上报警阈值逻辑。这三大块每一块都跑通了，整个系统也就成了。
本文还有配套的精品资源，点击获取
