LaunchXL-CC2650+Contiki读取DHT11超时问题求助

已知条件：

• 硬件已排除故障：更换过2块开发板、2个同型号DHT11，传感器供电正常（LED亮起）
• 代码基于Contiki-NG develop分支的dht11.c修改，去年学长可正常运行
• 编译仅生成.elf文件，用TI Programmer 2烧录成功（其他示例程序可正常运行）
• 核心症状：传感器读取超时

1. 优先排查GPIO引脚配置不匹配 #

你代码里定义了DHT11_GPIO_PORT (1)和DHT11_GPIO_PIN (12)，但实际调用configure时传入的是IOID_0，这里明显存在矛盾：

• CC2650的IOID_12才对应PORT1 PIN12，而IOID_0对应的是物理引脚DIO23
• 立即检查硬件接线：确认传感器数据引脚是接在IOID_0对应引脚，还是PORT1 PIN12对应引脚
• 修正代码：如果接线是PORT1 PIN12，把配置行改成dht11_sensor.configure(DHT11_CONFIGURE_GPIO_PIN, IOID_12);，同时删除冗余的BOARD_IOID_DIO0定义

2. 检查Contiki-NG分支的API变更 #

你用的是最新的develop分支，而学长去年使用的是旧版本，分支代码可能有破坏性变更：

• 对比当前develop分支和学长去年使用版本的dht11-sensor.c/dht11-sensor.h文件，重点看：
  • 传感器配置宏（DHT11_CONFIGURE_GPIO_PIN）的定义是否改变
  • SENSORS_ACTIVATE的实现逻辑是否有调整
  • 超时时间的计算方式是否变动
• 临时切换到学长去年使用的Contiki-NG标签/分支，重新编译测试，验证是否是版本问题

3. 调整传感器初始化和读取时序 #

DHT11对时序要求极严格，代码里的等待时长可能不足以满足传感器要求：

• 将初始化后的等待时间从1秒延长到3秒：etimer_set(&timer, CLOCK_SECOND * 3);
• 查看dht11-sensor.c内部的起始信号实现：确认起始低电平时长至少18ms，等待传感器响应的超时窗口是否足够大（建议至少200us）

4. 排查系统时钟配置差异 #

Contiki-NG的系统时钟配置会直接影响时序精度：

• 检查当前项目的board-conf.h或contiki-conf.h，确认BOARD_CONF_CLOCK_HZ的值是否和学长去年的配置一致
• 如果时钟频率被修改，会导致DHT11读取的时序计算错误，触发超时

5. 验证编译选项是否破坏时序 #

虽然elf文件能正常烧录，但编译优化可能导致时序代码变形：

• 修改Makefile，添加CFLAGS += -O0关闭编译优化，重新编译烧录测试
• 检查链接脚本，确认GPIO外设的时钟未被错误禁用

内容的提问来源于stack exchange，提问作者edward