简介：面向嵌入式开发者的STM32 HAL库驱动HDC2080工程包，基于STM32L051K8U6实现了TI低功耗温湿度传感器HDC2080的完整驱动方案。该传感器温度精度0.2°C、湿度精度2%，支持触发与自动两种测量模式，睡眠功耗仅50nA，适合电池供电的物联网节点。工程代码包含寄存器读写、温湿度采集、阈值中断配置等核心函数，并针对纽扣电池供电场景给出了低功耗优化建议，同时强调PCB布局中热隔离对测量精度的影响。驱动采用模块化设计，可便捷移植到智能家居或环境监测项目。压缩包共145个文件，以h头文件与c源码为主，配合uvprojx工程配置、hex和axf可执行文件、ioc引脚配置以及md说明文档，整体大小396KB，结构清晰，便于直接查阅与二次开发。文件类型涵盖源码、配置与编译产物，可辅助理解工程构建流程。已有51人学习下载，适合需要快速集成HDC2080或学习STM32 HAL库外设驱动的开发者参考。 上次画完一块温湿度采集板，贴片回来后第一件事不是跑DEMO，而是先把HDC2080这颗传感器调通。TI这颗HDC2080在低功耗产品里出镜率不低，I2C接口、20位?（实际是14位ADC）、内置加热器，配合STM32的HAL库，原本以为半天能搞定，结果还是踩了几个不大不小的坑。这篇文章就把整个驱动过程拆开讲清楚，从选型、硬件连接到寄存器配置，再到HAL库的代码实现和实测问题排查，给正准备用这颗传感器的朋友一个参考。

1. 选型笔记：为什么挑中HDC2080而不是DHT11和SHT30

先说说这颗传感器的定位。HDC2080是TI出的温湿度一体传感器，I2C数字接口，供电范围1.62V到3.6V，测量精度标称±0.2°C（典型值）和±2%RH。这个精度的意义在于：像DHT11那种±2°C、±5%RH的货色，用在环境监测里基本只能"看个趋势"，真要做温控补偿或数据记录，误差大到没法看。而SHT30在低功耗模式下表现也不错，但HDC2080的优势在于芯片内部自带加热器和低功耗测量模式，适合电池供电的户外IoT节点和冷链记录仪这类场景。

我当时选它还有一个原因：I2C地址可配。板上有两组传感器的时候，AD0引脚拉高拉低就能把地址错开，总线仲裁省心很多。再加上TI提供了完整的寄存器手册和参考代码，HAL库环境下写驱动基本就是读寄存器、写寄存器的事。如果你用的是STM32的CubeMX生成工程，HAL库的I2C驱动封装得比较完善，不用关心底层时序细节，开发效率比标准库高不少。不过HAL库函数名长、参数多，如果只照着CubeMX生成的模板抄，很容易在I2C读写超时这类问题上翻车。

还有一点值得提：HDC2080的休眠电流极低，典型值在几十纳安级别。对电池供电的产品来说，这意味着传感器可以一直挂在总线上，不用额外加MOS管做电源开关。我见过不少项目给传感器做"伪低功耗"，就是外部关断供电，结果I2C总线悬空漏电反而更麻烦。这颗芯片直接靠寄存器的触发模式就能"测量完自动入睡"，电路可以省很多事。

2. 硬件连接与I2C地址陷阱

硬件部分没有太多玄学，但有几个细节很容易在画板时忽略。HDC2080的引脚定义不算多：VDD、GND、SDA、SCL、AD0，还有一个可选的RDY引脚（用于中断通知MCU数据就绪）。我用的板子把RDY空着，靠读状态寄存器来确认转换完成，省一根线。

接线建议如下：

引脚	连接目标	注意事项
VDD	3.3V	并联0.1uF和1uF去耦电容，电容尽量靠近VDD引脚
GND	GND	地回路要短，避免和功率地共用一段长走线
SDA	MCU I2C数据线	必须外部上拉，典型4.7kΩ
SCL	MCU I2C时钟线	必须外部上拉，典型4.7kΩ
AD0	GND或VDD	接地时I2C地址0x40，接VDD时0x41

I2C总线为什么一定要上拉？因为I2C是开漏结构，SDA和SCL引脚本身只能拉低，不能主动拉高。没有上拉电阻，总线永远停在低电平，通信直接瘫痪。这个老生常谈的问题，我在新画板时还是中招了一次——原理图库里拷贝的上拉电阻位号被误删了，结果整条总线拉不起来，费了半天劲才发现。

上拉电阻阻值的选择和总线速率、走线长度有关。标准模式100kbps用10kΩ没问题，快速模式400kbps建议用4.7kΩ，如果板子走线较长、总线电容偏大，有时候要降到2.2kΩ才能保证上升沿够快。我习惯默认放4.7kΩ，实测STM32的I2C1跑400kHz一点问题没有。另外STM32的GPIO配置要注意，用CubeMX生成I2C初始化后，PB6/PB7（I2C1的默认引脚）会自动配置为开漏复用模式，别手动改成推挽，否则电气特性会乱。

还有一个小坑：HDC2080的AD0不是"无引脚"状态，如果你把它悬空，地址会变成不确定状态。千万别想着省一个电阻直接把AD0浮空，手册里要求必须接GND或VDD。我板子上画了一个0欧电阻来切换地址，调试的时候挺方便。

3. 寄存器表里的三件套：数据、配置、状态

HDC2080的寄存器不多，核心就那么几个。如果你习惯一上来就"照着参考代码抄一遍"，那我建议先花十分钟把寄存器表过一遍，因为后面排查问题全靠它。

寄存器地址	名称	功能说明
0x00	TEMP_LOW	温度数据低字节（只读）
0x01	TEMP_HIGH	温度数据高字节（只读）
0x02	HUM_LOW	湿度数据低字节（只读）
0x03	HUM_HIGH	湿度数据高字节（只读）
0x04	CONFIG	温湿度分辨率配置、加热器控制
0x0C	MEASUREMENT_CONFIG	测量使能与触发方式
0x0D	STATUS	温湿度数据就绪标志（只读）
0x0E	MANUFACTURER_ID	厂商ID，固定0x5449
0x0F	DEVICE_ID	设备ID，固定0x2080

数据寄存器很简单：温度占两个字节，湿度占两个字节。但要注意，HDC2080不是"读一个字节地址自动递增"那种风格，你最好用I2C的寄存器地址连续读功能，一次性读4个字节。这样拿到的温度和湿度是同一时刻的样本，如果你分开两次读，中间可能插入一次新的转换，导致温度和湿度不是同一个时间点采出来的。对大多数应用来说这不是致命问题，但做曲线对比时就会出现莫名其妙的数据跳变。

CONFIG寄存器主要管分辨率。默认值0x00对应14位温湿度分辨率，对绝大多数场景够用了。如果你对转换时间敏感，可以把分辨率降到11位或9位，转换时间会短很多。不过说实话，HDC2080的14位转换时间本来就很短（毫秒级），没有特殊需求就用默认值。

MEASUREMENT_CONFIG这个寄存器是驱动里最关键的。单次测量模式下，你需要把TEMP_EN和HUM_EN对应的位置1，然后设置触发位，传感器就会开始一次转换。转换完成后数据锁存到0x00到0x03，传感器自动进入低功耗状态。这种方式比让传感器"一直不断地测"省电得多，也更可控——你决定什么时候测，而不是被动的被传感器牵着走。

STATUS寄存器的低两位分别是温度和湿度数据就绪标志，读出来是1表示数据已经更新。实际写驱动时，可以用两种方式判断转换完成：一种是轮询STATUS寄存器，读到标志位拉高再取数；另一种是直接延时，算好转换时间后睡一觉再读。轮询方式更稳妥，代码也不复杂。我一般轮询加超时保护，避免I2C通信异常时死等。

4. HAL库读写代码怎么写才稳

CubeMX配置I2C1，时钟设为400kHz，7位地址模式，然后生成工程。这里有个小细节：STM32的I2C外设时钟源要确认一下，如果系统时钟用了PLL，I2C模块的时钟输入最好别选得太离谱，否则实际波特率偏差太大，传感器可能直接NACK。CubeMX默认配置通常没问题，但我见过有人手动改过APB1分频，导致I2C时钟变成了一堆乱码频率，通信各种不稳定。

驱动代码的核心是封装两个函数：写寄存器、读寄存器。HAL库里面有现成的 HAL_I2C_Mem_Write 和 HAL_I2C_Mem_Read ，专门用来操作带寄存器地址的I2C器件。千万别用 HAL_I2C_Master_Transmit 裸发数据，因为那个函数不带寄存器地址参数，你还需要自己拼一帧"寄存器地址+数据"的buffer，麻烦且容易漏。

#define HDC2080_I2C_ADDR      (0x40 << 1)   // 7位地址0x40，HAL库要求传8位地址
#define HDC2080_REG_TEMP_LOW  0x00
#define HDC2080_REG_HUM_LOW   0x02
#define HDC2080_REG_CONFIG    0x04
#define HDC2080_REG_MEAS_CFG  0x0C
#define HDC2080_REG_STATUS    0x0D
#define HDC2080_REG_DEV_ID    0x0F

static I2C_HandleTypeDef *hdc_i2c;

uint8_t HDC2080_WriteReg(uint8_t reg, uint8_t data)
{
    return HAL_I2C_Mem_Write(hdc_i2c, HDC2080_I2C_ADDR, reg,
                             I2C_MEMADD_SIZE_8BIT, &data, 1, 100);
}

uint8_t HDC2080_ReadRegs(uint8_t reg, uint8_t *buf, uint8_t len)
{
    return HAL_I2C_Mem_Read(hdc_i2c, HDC2080_I2C_ADDR, reg,
                            I2C_MEMADD_SIZE_8BIT, buf, len, 100);
}

HAL库的 I2C_MEMADD_SIZE_8BIT 表示寄存器地址是8位宽度，HDC2080的寄存器地址正好是8位。如果传成16位，I2C总线会先发两个字节的寄存器地址，传感器根本认不出来，结果就是通信失败。这个参数看着不起眼，但我见过不少人在这里卡住，总以为是地址写错了，实际是寄存器地址宽度不匹配。

初始化函数就做两件事：读设备ID确认通信正常，然后配置测量模式。

uint8_t HDC2080_Init(I2C_HandleTypeDef *i2c_handle)
{
    uint8_t id = 0;
    hdc_i2c = i2c_handle;

    if (HDC2080_ReadRegs(HDC2080_REG_DEV_ID, &id, 1) != HAL_OK)
        return 0;
    if (id != 0x20)   // 设备ID低字节，HDC2080是0x2080
        return 0;

    // 配置寄存器，保持默认14位分辨率
    HDC2080_WriteReg(HDC2080_REG_CONFIG, 0x00);

    return 1;
}

读取一帧温湿度数据的流程是：先写测量配置触发一次转换，等待数据就绪，然后一次性读取4个字节。

uint8_t HDC2080_ReadTempHum(float *temperature, float *humidity)
{
    uint8_t buf[4];
    uint8_t status = 0;
    uint16_t raw_temp, raw_hum;
    uint32_t timeout = 0;

    // 触发单次测量：TEMP_EN|HUM_EN|MEAS_TRIG
    uint8_t meas_cfg = 0x08 | 0x04 | 0x01;
    HDC2080_WriteReg(HDC2080_REG_MEAS_CFG, meas_cfg);

    // 轮询STATUS寄存器，等待温度和湿度都就绪
    do {
        HDC2080_ReadRegs(HDC2080_REG_STATUS, &status, 1);
        HAL_Delay(2);
        timeout++;
        if (timeout > 100)   // 超时保护，约200ms
            return 0;
    } while ((status & 0x03) != 0x03);

    // 一次读取4字节：TEMP_LOW, TEMP_HIGH, HUM_LOW, HUM_HIGH
    HDC2080_ReadRegs(HDC2080_REG_TEMP_LOW, buf, 4);

    raw_temp = (uint16_t)(buf[0] << 8) | buf[1];
    raw_hum  = (uint16_t)(buf[2] << 8) | buf[3];

    *temperature = ((float)raw_temp / 65536.0f) * 165.0f - 40.0f;
    *humidity    = ((float)raw_hum  / 65536.0f) * 100.0f;

    return 1;
}

那行注释里的 0x08 | 0x04 | 0x01 分别对应TEMP_EN、HUM_EN和触发位。这个字段的具体位定义在不同版本的手册里描述都比较接近，但如果你用的是TI后来出的HDC3020之类的型号，位定义会不一样，最好还是对照自己的芯片手册核对一遍。我调的时候用逻辑分析仪抓过I2C波形，确认传感器有正确的ACK回包，才继续往下走。

主函数里的调用就很简单了：

float temp, hum;
if (HDC2080_ReadTempHum(&temp, &hum)) {
    printf("温度: %.2f C, 湿度: %.2f %%RH\r\n", temp, hum);
}

这段代码在STM32F103C8T6和STM32L431上都实测跑通过。F103的I2C外设历史上被不少人吐槽有bug，但实际上用HAL库的阻塞模式，加上正确的时序和超时处理，稳定运行完全没有问题。如果你用的是新版HAL库，还支持中断和DMA模式，不过对单次读取需求来说，阻塞模式简单可靠，没必要引入回调复杂度。

5. 温湿度换算和误差校正

HDC2080的原始数据是16位无符号数，但14位有效值，所以数据范围相当于把16位的整个刻度都用了。温度量程是-40°C到125°C，跨度165°C，对应的公式是：

temperature = (raw_temp / 65536) * 165 - 40

湿度量程是0%RH到100%RH，对应公式是：

humidity = (raw_hum / 65536) * 100

很多刚接触这颗芯片的人会对65536这个除数困惑——既然只有14位精度，为什么不直接除以16384？原因在于传感器输出的数据是左对齐的：14位数据放在16位寄存器的最高位，低两位补零。所以实际满量程对应的数值就是16位能表达的最大值65535，而不是14位的16383。如果除以16384，你会发现任何数值都变成了原来的4倍，换算出来的温度和湿度完全离谱。

换算公式还有一个隐性好处：线性。整条温度曲线在-40°C到125°C范围内是线性的，不需要做分段校正。湿度在20%RH到80%RH范围内线性度也相当不错，超出这个区间会有一定的非线性，但对大多数监测应用来说，用线性公式就够了。

我实测过两个HDC2080放在同一个恒温箱里，温度读数偏差在0.3°C以内，符合标称精度。但需要注意的是，传感器自身会轻微发热。如果测量间隔很短，连续触发测量，自热会让读数比环境温度略高0.1到0.2°C。所以产品里做温度采集，测量频率不要太高，间隔几秒到几十秒完全够用。

误差校正方面，常见的做法是单点校准。用一个精度更高的参考温度计和湿度计，放在同一环境下稳定后，记录传感器读数和参考值的偏差，然后在软件里加一个偏移量。湿度传感器的个体差异比温度大，有条件的话建议每片板子在产线上做一次湿度校准，标定偏移量写进Flash。对于成本敏感的产品，至少要保证回流焊后做一次恢复处理，否则湿度读数会明显偏离。

6. 实测中的三个坑和排查思路

第一个坑是温度传感器的读数整体偏高。板子放在桌面上，室温显示比水银温度计高了将近2°C。排查了一圈，发现问题不在传感器本身，而是PCB布局问题——HDC2080旁边走了一根电源线的过孔，板子工作时电源线上有几十毫安的电流，局部温升传导到传感器附近。解决办法很简单：把传感器挪到离电源走线和MCU远一点的位置，或者在两者之间留一段地铜皮做热隔离。这个案例提醒我，温湿度传感器在PCB上的位置比想象中重要，它测量的是"芯片周围的微气候"，不是"整个房间的温度"。

第二个坑是I2C总线偶发NACK，有时上电能读到数据，有时读不到。用示波器抓波形才发现，SDA的上升沿很缓，也就是上拉电阻太大，总线电容又偏高，导致上升沿时间超出了I2C协议规范。把上拉电阻从4.7kΩ换成2.2kΩ后，问题消失。另外还有个容易被忽略的点：如果你用的是杜邦线连接传感器模块，杜邦线本身有十几厘米长，等效电容会明显增加，这时候更得用小阻值上拉。

第三个坑是湿度数据在焊接后明显不准。刚回流焊完的板子，湿度读数比正常环境低了差不多10%RH，过几天才慢慢恢复。这是湿敏传感器的通病——焊接高温会让感湿材料内部的水分流失，需要重新吸收环境水分才能恢复正常。TI手册里建议对HDC2080做"恢复处理"：在85°C、相对湿度大于80%的环境下存放24小时。实际生产中，如果条件不允许，至少要在正常环境下放置48到72小时，让传感器自然恢复。我后来在售后文档里专门加了一条：传感器板子出货前必须做湿度恢复和校准，否则客户端测试数据根本没法看。

还有一次比较隐蔽的问题：在自动测量模式下，数据有时候读到的始终是旧值，即使STATUS寄存器已经就绪。原因是我在触发完一次测量后，紧接着又触发了一次，把前一次的转换结果覆盖了。排查思路是把触发逻辑改成单次触发，确保每次转换完成后、读取数据前，不做任何额外的寄存器写入操作。这些经验让我后来写驱动时养成了一个习惯：每次改代码前先看一遍寄存器操作时序，尤其是和触发、状态相关的寄存器，宁可多读一遍手册，也比抓一晚上波形强。

最后分享一个小技巧。调试的时候，初始化函数里读设备ID这一步非常关键。如果I2C通信有问题， HAL_I2C_Mem_Read 返回的是HAL_ERROR，你立刻就能知道是硬件连接问题还是代码问题，不用等读到温湿度数据后才开始猜。我在工程里还加了一个调试用的计数器，如果I2C连续失败超过5次，直接点亮一个故障LED。这个习惯帮我省了不少排查时间。

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