4 releases

0.2.1 Feb 26, 2021
0.2.0 Feb 16, 2021
0.1.1 Jan 11, 2020
0.1.0 Jan 11, 2020

#1820 in Embedded development

Download history 364/week @ 2023-12-15 373/week @ 2023-12-22 231/week @ 2023-12-29 230/week @ 2024-01-05 233/week @ 2024-01-12 103/week @ 2024-01-19 132/week @ 2024-01-26 188/week @ 2024-02-02 180/week @ 2024-02-09 153/week @ 2024-02-16 249/week @ 2024-02-23 120/week @ 2024-03-01 93/week @ 2024-03-08 79/week @ 2024-03-15 96/week @ 2024-03-22 132/week @ 2024-03-29

407 downloads per month
Used in rp2040-hal

MIT license

12KB
181 lines

DHT11/DHT22 sensor driver

crates.io Docs

This library provides a platform-agnostic driver for the DHT11 and DHT22 sensors.

Use one of two functions dht11::Reading::read and dht22::Reading::read to get a reading.

Usage

The only prerequisites are an embedded-hal implementation that provides:

  • Delay-implementing type, for example Cortex-M microcontrollers typically use the SysTick.
  • InputOutputPin-implementing type, for example an Output<OpenDrain> from stm32f0xx_hal.

See the stm32f042 example for a commented example of how to use the library.

Tests

To run the tests, use something like cargo test --lib --target x86_64-unknown-linux-gnu.


lib.rs:

DHT11/DHT22 sensor driver

This library provides a platform-agnostic driver for the DHT11 and DHT22 sensors.

Use one of two functions dht11::Reading::read and dht22::Reading::read to get a reading.

Usage

The only prerequisites are an embedded-hal implementation that provides:

  • Delay-implementing type, for example Cortex-M microcontrollers typically use the SysTick.
  • InputOutputPin-implementing type, for example an Output<OpenDrain> from stm32f0xx_hal.

When initializing the pin as an output, the state of the pin might depend on the specific chip used. Some might pull the pin low by default causing the sensor to be confused when we actually read it for the first time. The same thing happens when the sensor is polled too quickly in succession. In both of those cases you will get a DhtError::Timeout.

To avoid this, you can pull the pin high when initializing it and polling the sensor with an interval of at least 500ms (determined experimentally). Some sources state a refresh rate of 1 or even 2 seconds.

Example

See the stm32f042 example for a working example of how to use the library.

#![no_std]
#![no_main]

use crate::hal::{delay, gpio, prelude::*, stm32};
use cortex_m_rt::entry;
use cortex_m_semihosting::hprintln;
use panic_halt as _;
use stm32f0xx_hal as hal;

use dht_sensor::*;

#[entry]
fn main() -> ! {
    let mut p = stm32::Peripherals::take().unwrap();
    let cp = stm32::CorePeripherals::take().unwrap();
    let mut rcc = p.RCC.configure().sysclk(8.mhz()).freeze(&mut p.FLASH);

    // This is used by `dht-sensor` to wait for signals
    let mut delay = delay::Delay::new(cp.SYST, &rcc);

    // This could be any `gpio` port
    let gpio::gpioa::Parts { pa1, .. } = p.GPIOA.split(&mut rcc);

    // An `Output<OpenDrain>` is both `InputPin` and `OutputPin`
    let mut pa1 = cortex_m::interrupt::free(|cs| pa1.into_open_drain_output(cs));
    
    // Pulling the pin high to avoid confusing the sensor when initializing
    pa1.set_high().ok();

    // The DHT11 datasheet suggests 1 second
    hprintln!("Waiting on the sensor...").unwrap();
    delay.delay_ms(1000_u16);
    
    loop {
        match dht11::Reading::read(&mut delay, &mut pa1) {
            Ok(dht11::Reading {
                temperature,
                relative_humidity,
            }) => hprintln!("{}°, {}% RH", temperature, relative_humidity).unwrap(),
            Err(e) => hprintln!("Error {:?}", e).unwrap(),
        }
        
        // Delay of at least 500ms before polling the sensor again, 1 second or more advised
        delay.delay_ms(500_u16);  
    }
}

Dependencies

~71KB