Arduino Uno作品入门指南：温湿度传感器应用

温湿度监测 Arduino Uno 作品：从接线到可靠运行的实战手记

刚拿到 DHT22 传感器时，我把它插进面包板、连上 Arduino Uno、烧录完示例代码，盯着串口监视器里跳动的数字——心里却没底：这到底是真实环境数据，还是引脚接触不良导致的随机抖动？为什么有时显示NaN？LCD 屏上温度突然变成-127.0°C是不是传感器坏了？这些问题，几乎每个第一次用 DHT 系列传感器的人都会撞上。而真正卡住新手的，从来不是“怎么接线”，而是不知道哪根线在什么时候该是什么电平、为什么必须等 80 微秒、以及当数据出错时，该怀疑硬件、库、还是自己的延时逻辑。

这篇笔记不讲抽象概念，也不堆砌手册原文。它是我用 DHT22 搭了七版温湿度监测节点后，把踩过的坑、调通的波形、反复修改的寄存器配置和最终稳定运行三个月的实物经验，一条一条捋出来的真实记录。

DHT22 不是“即插即用”，它是一台微型状态机

DHT22 的本质，不是“输出温湿度的黑盒子”，而是一个靠精确时序对话才能唤醒的微型设备。它的通信协议没有起始位、停止位，不走 UART，不依赖中断，全靠主机（Arduino）用 GPIO 拉低、释放、再采样——像两个人用手势打暗号：你先压住我的手 20 毫秒，我回你一个短按+长按表示“收到”，然后开始一拍一拍地报数，每拍的长短代表 0 或 1。

这就决定了三件事：

• delay()害死人：delay(1)最小单位是毫秒，而 DHT22 的关键脉冲宽度在27~70μs量级。用delay()去等，早就错过整个响应帧了。
• micros()是命门，但不是万能解药：micros()返回的是自启动以来的微秒数，精度约 4μs（受 16MHz 主频限制），足够判别 DHT22 的“0”与“1”。但它不解决另一个问题：CPU 在执行digitalRead()时有指令开销，不同编译优化等级下延迟浮动可达 3~5μs。这意味着，你写的“等待高电平持续 ≥50μs”逻辑，在实际运行中可能提前或延后触发。
• 校验和不是摆设，是救命稻草：DHT22 发送的 40 位数据最后 8 位是前 4 字节之和。很多初学者看到readTemperature()返回NAN就慌，其实只要把原始数据帧打印出来（比如用Serial.print(raw_data[i], HEX)），一眼就能看出是第 3 字节错了，还是校验和对不上——前者大概率是时序偏差，后者更可能是电源噪声或接触不良。

✅ 实战技巧：想确认是不是时序问题？用示波器抓 D2 引脚波形。正常启动信号是 >18ms 低电平；DHT22 回应是 80μs 低 + 80μs 高；随后每个数据位先是 50μs 低电平（同步头），再跟一段可变高电平（27μs=0，70μs=1）。如果同步头之后全是乱跳的窄脉冲，基本可以断定micros()轮询没对齐，或者digitalRead()被其他中断打断了。

Arduino Uno 的 I/O 不是“开关”，是寄存器的映射

我们习惯写pinMode(2, INPUT_PULLUP)，但这句话背后发生了什么？

ATmega328P 的每个端口（PORTB、PORTC、PORTD）都对应一组三个寄存器：
-DDRx（Data Direction Register）：决定引脚是输入还是输出
-PORTx：输出时设高低电平；输入时设 1 启用内部上拉，设 0 则为浮空
-PINx：只读，反映当前引脚物理电平

以 D2（即 PD2）为例：

pinMode(2, OUTPUT); // DDRD |= (1 << PORTD2); digitalWrite(2, LOW); // PORTD &= ~(1 << PORTD2); // ……稍后切换为输入并启用上拉： pinMode(2, INPUT_PULLUP); // DDRD &= ~(1 << PORTD2); PORTD |= (1 << PORTD2);

这个切换动作本身就有延迟：DDRD和PORTD是两个独立寄存器，两次写操作至少耗时 2 个 CPU 周期（125ns）。而 DHT22 要求主机在拉低 18ms 后立刻释放并转为输入，否则它会认为“握手失败”，直接沉默。

所以，标准库里的dht.begin()并不只是初始化对象，它干了这些事：
1. 把 D2 配成OUTPUT，拉低至少 20ms（留足余量）
2.立刻切为INPUT_PULLUP，让总线靠内部上拉回到高电平
3. 然后进入while(digitalRead(DHTPIN) == HIGH)循环，等待 DHT22 的响应脉冲

如果你自己手写驱动，漏掉“立刻”二字——比如中间加了个Serial.print("waiting...")，那通信就废了。

✅ 实战技巧：避免在 DHT 通信窗口内做任何串口打印、millis()查询、甚至analogRead()。这些函数内部可能触发 ADC 中断或改变定时器状态，干扰微秒级时序。真要调试？用 LED 闪灯代替：亮 = 进入等待，灭 = 收到响应，快闪 = 校验成功，慢闪 = 校验失败。

LCD1602 显示不是“打印字符串”，是操控 HD44780 控制器

很多人以为lcd.print("Temp: 25.3C")就是把字符发过去，其实这是个“翻译+调度”的过程。

LCD1602 内部的 HD44780 芯片，本质上是个带 RAM 的状态机：
- 它有两块内存：DDRAM（Display Data RAM，存要显示的字符码）和 CGRAM（Character Generator RAM，存自定义符号）
- 每次写入，必须先送“指令”告诉它：“接下来我要改光标位置（0x80+addr）”，或“我要清屏（0x01）”，或“我要写字符（ASCII）”
- 所有指令/数据都通过 4 根数据线分两次传（高 4 位 + 低 4 位），每次传输都要给 E 引脚一个下降沿来“锁存”

这就是为什么LiquidCrystal库的构造函数要传 6 个引脚：RS、RW、E、D4、D5、D6、D7（注意：D4-D7 是数据线，不是地址线）。它不是在控制 LCD，而是在模拟一个“HD44780 工程师”的手动操作流程。

最常被忽视的一点：HD44780 对指令执行需要时间。比如清屏指令0x01，官方手册注明“执行时间最大 1.64ms”。如果你在lcd.clear()后马上lcd.print("Hello")，而没加延时或忙信号检测，LCD 可能还在擦除第一行，第二行就已开始写入——结果就是“Hel”出现在第一行，“lo”出现在第二行。

✅ 实战技巧：不要迷信lcd.begin(16,2)。它只是初始化，不代表 LCD 已就绪。首次使用前，加一句delay(50)；后续操作中，若发现显示错位、字符残留，优先检查是否某次lcd.print()前忘了lcd.setCursor()，或是否连续写入太快。更稳妥的做法是：每次更新前，先lcd.setCursor(0,0); lcd.print(" ");清空第一行 8 个位置，再写新值——比“覆盖式更新”更可靠。

电源，才是藏得最深的“隐形故障源”

DHT22 标称工作电压 3.3~5.5V，Arduino Uno 输出 5V，看起来天作之合。但实测发现：用 Uno 的 5V 引脚直供 DHT22，误码率高达 8%；换成外接稳压模块（AMS1117-5.0）供电，误码率降至 0.2%。

原因在于：
- Uno 板载的 NCP1117 稳压芯片，在 USB 供电（500mA 限流）且同时驱动 LCD+LED+串口芯片时，负载瞬态响应差，纹波可达 80mVpp
- DHT22 内部 ADC 对参考电压极其敏感。80mV 纹波直接转化为温湿度读数跳变（实测 ±0.8℃ / ±3%RH 抖动）
- 更隐蔽的问题是：Uno 的 GND 走线太细。当 DHT22 在转换瞬间汲取 5mA 电流时，GND 路径上的压降会让传感器“以为”自己的地比 MCU 地高了几毫伏——通信电平阈值偏移，导致“1”被误判为“0”

解决方案不是换芯片，而是重构供电路径：
- DHT22 的 VCC 和 GND不经过面包板电源轨，而是用杜邦线单独连接到 Uno 的 5V 和 GND 引脚焊盘（物理距离最短）
- 在 DHT22 的 VCC-GND 之间，紧贴其引脚焊接一颗 100nF X7R 陶瓷电容（不是电解电容！高频特性差）
- 若同时接 LCD，将 LCD 的 VCC/GND 也单独引至 Uno 同一焊盘，形成“星型接地”

✅ 实战技巧：用万用表直流档测 DHT22 的 VCC-GND 电压，正常应为 4.95~5.05V。如果低于 4.85V，或在dht.readTemperature()执行瞬间电压跌落 >0.1V，立刻检查电源路径。这不是传感器坏了，是你的供电设计在报警。

让作品真正“活”过一周：那些手册不会写的细节

• DHT22 的最小间隔不是建议，是铁律：数据手册写“recommended interval ≥2s”，意思是“少于 2 秒，它可能拒绝响应，也可能返回上次缓存值，也可能直接吐NAN”。别试图用millis()精确卡在 2000ms 整，留 50ms 余量（如if(millis() - last_read > 2050)），否则在串口打印、LCD 刷新等操作挤占 CPU 时间时，极易触发超时。
• LCD 的“°”符号不是°字符，是 ASCII 223：lcd.print((char)223)才能在 HD44780 的 CGROM 中找到那个小圆圈。直接写"°"会显示问号或方块——因为 LiquidCrystal 库默认用的是标准 ASCII 字集，不支持 Unicode。
• 串口不是“管道”，是带缓冲的队列：Serial.print("Temp:")不会立刻发出，而是先存进发送缓冲区（64 字节）。如果缓冲区满（比如你每 100ms 发一次大 JSON），Serial.print()会阻塞等待空间。所以高频日志场景，务必用Serial.write()+ 手动拼包，或升级波特率到 115200。
• 物理安装比代码更重要：DHT22 的感光窗（白色塑料盖）正对热源（如 Uno 的 USB 接口芯片）时，实测温度虚高 3.2℃。用黑色电工胶布遮住感光窗上方 1/3，既能防直射热辐射，又不影响湿敏元件透气性。

现在，你可以试着拆掉所有库，用纯寄存器操作重写一遍 DHT22 读取——不是为了炫技，而是为了看清每一微秒里，电流如何在铜箔上奔跑，电平如何在晶体管间翻转，数据如何从硅片深处被一比特一比特地托举上来。

真正的 Arduino Uno 作品，从来不在 IDE 的“上传成功”弹窗里，而在你第一次用示波器抓到那条干净的 80μs 响应脉冲时，在你亲手焊上的那颗 100nF 电容让 LCD 不再闪烁时，在你把 DHT22 移到窗台边、看着三天湿度曲线平稳爬升过 65% 时。

如果你也在调试中遇到了“明明接线正确却一直 NaN”的情况，或者发现 LCD 第二行总显示乱码，欢迎在评论区贴出你的接线图和关键代码段——我们可以一起看波形、查寄存器、拧紧那颗松动的杜邦线。