不能用digitalWrite+delay做DHT11时序，因其微秒级精度要求（起始≥18ms、响应80μs、数据位高电平26–70μs）远超通用函数数百微秒误差，且受中断与调度干扰，无法满足单总线严格时序约束。
为什么不能用 digitalWrite + delay 做 DHT11 时序
DHT11 的通信完全依赖微秒级精确时序：起始信号要求主机拉低 ≥18ms，随后释放并等待 20–40μs；传感器响应脉冲宽度为 83μs/87μs；每位数据由 50μs 低电平起始，后接 27–70μs（“0”）或 70–267μs（“1”）高电平。标准库的 digitalWrite() 和 delayMicroseconds() 在通用操作系统（如 Linux）或非实时环境下误差常达数百微秒，且受中断、调度干扰，根本无法满足协议要求。
纯软件模拟单总线需手动控制引脚方向与电平
DHT11 单总线本质是开漏结构：主机需在输出模式下拉低总线发起通信，再切换为输入（高阻）模式让传感器能拉低总线回传数据。C++ 无硬件外设支持时，必须绕过抽象层直接操作寄存器或内存映射 GPIO —— 比如在树莓派 Linux 用户态，要用 mmap() 映射 /dev/gpiomem，再按 BCM 编号定位对应 GPIO 的控制寄存器（GPFSEL、GPSET、GPCLR、GPLEV）；在裸机 STM32 环境，则需手动置位/清零 GPIOx_ODR 和配置 GPIOx_CRL/CRH 模式。
关键操作包括：
- 设置引脚为推挽输出 → 拉低总线（
GPCLR或GPIOx_BSRR写低位） - 切换为浮空输入 → 释放总线（改写
GPFSEL清除功能位，或设GPIOx_CRL为IN_FLOATING） - 读取引脚电平前必须等至少 1–2μs，避免采样到切换过程中的亚稳态
- 所有延时必须用 NOP 循环或内联汇编实现，例如
__asm__ volatile ("nop" ::: "r0");配合循环计数校准
树莓派用户态下用 C++ 实现 DHT11 读取的硬约束
Linux 用户态无法禁用调度或屏蔽中断，因此严格时序只能靠“暴力采样+后期判别”：以远高于理论速率（如 1MHz）持续读取 GPLEV 寄存器，记录每次电平跳变的时间戳（用 clock_gettime(CLOCK_MONOTONIC, &ts)），再离线分析脉宽分布。这种方式规避了主动延时不准的问题，但代价是：
立即学习“C++免费学习笔记（深入）”；
- 需预留足够内存缓存数千次采样（典型一次 DHT11 通信含 1 起始 + 1 应答 + 80 数据位 = 至少 100+ 电平跳变）
- 必须在
/boot/config.txt中启用gpiomem=on并确保程序有gpio组权限 - BCM 编号必须准确（如物理引脚 7 对应 BCM 4），错一位就完全读不到信号
- 上拉电阻不可省：即使模块自带，实测仍建议外接 4.7kΩ 到 3.3V，否则高电平爬升缓慢导致“1”误判为“0”
STM32 裸机 C++ 中避免 SysTick 中断干扰时序
若用 C++ 封装 DHT11 类并在裸机运行（如基于 HAL 或标准库），必须确保时序关键段不被 SysTick 中断打断。常见错误是把 DHT11::read() 放在 main() 循环里，却未关闭全局中断：__disable_irq() 必须包裹整个起始信号+等待应答+采样过程（约 5ms），否则任意中断进入都会导致传感器复位或数据错位。
更稳妥的做法是：
- 将全部时序逻辑写成纯汇编函数（如
DHT11_Start()），避免 C++ 函数调用开销和栈操作不确定性 - 用
RCC_GetClocksFreq()获取 APB2 频率，反向计算 NOP 数量（例如 72MHz 下 1μs ≈ 72 个周期，需插入 20+ 个NOP） - 校验和失败时不要立即重试，先检查
GPIOx_IDR当前电平是否卡在低——这说明传感器未释放总线，需强制延时 200ms 后再初始化
真正棘手的不是读出数据，而是让不同平台上的“同一段 C++ 代码”在无外设驱动协助时，始终满足那几十微秒的窗口容差。这个精度边界，决定了你是在解析温湿度，还是在调试时序毛刺。
