Prerequisites:

 

HardwareCY8CKIT-062-WIFI-BT/CY8CKIT-062-BLE/CY8CPROTO-063-BLE

Software/IDE PSoC Creator 4.3 and PDL 3.1.1

 

Introduction: 

 

DHT-11 is a popular sensor to measure temperature and humidity. The sensor is manufactured by many companies one of which is Adafruit and the Adafruit sensor can be found here. This blog provides 2 ways to interface DHT-11 with PSoC 6 one using the interrupts and the other without. The PSoC Creator projects for the two applications are attached as part of this blog.

 

Working of DHT-11 Sensor:

 

DHT-11 is a single wire digital humidity and temperature sensor, which provides humidity and temperature values serially with one-wire protocol. DHT11 sensor provides relative humidity value in percentage (20 to 90% RH) and temperature values in degree Celsius (0 to 50 °C). DHT11 sensor uses a resistive humidity measurement component and NTC temperature measurement component.

 

The sensor has 3 pins – Vcc, Data, Gnd. The operating voltage of the sensor is 3.3V to 5V and thus Vcc is connected to 3.3V and Gnd to Ground of the kit. Data pin acts as the asynchronous interface between the sensor and the PSoC device. The Data pin should be configured as a bidirectional pin with drive mode set as Resistive Pull Up. The communication protocol followed by the sensor is asynchronous with a START condition, ACKNOWLEDGEMENT and 5 bytes of Data.

The 5 bytes contain the following data –

 

Byte 1 - Humidity (whole number part)

Byte 2 - Humidity (fractional part)

Byte 3 - Temperature (whole number part)

Byte 4 - Temperature (fractional part)

Byte 5 - Checksum

 

1. START – Start condition is sent by the PSoC 6 device. An 18 ms low pulse is sent to the sensor.

 

Figure 1: Communication protocol of sensor

   

 

2. ACKNOWLEDGMENT – The sensor detects the low pulse from the MCU and sends an acknowledgment signal by pulling the Data line low for approximately 54 us. The sensor then sends a logic high for about 80 us and then starts sending Data to the PSoC MCU.

 

3. DATA – Data is sent serially in terms of bits. Bit-level logic is represented as follows,

  • Logic 0 – 54 us low and 24 us high signal
  • Logic 1 – 54 us low and 70 us high signal

40 bits are sent in a similar way after which the communication terminates. The last byte contains the checksum and needs to be verified to ensure that the data received is valid. The checksum is obtained by simply adding the first 4 bytes.

 

Figure 2: Bit 0

 

Figure 3: Bit 1

 

 

 

Application 1:

 

  • The first approach puts the CPU to sleep when not in use and makes use of the interrupt. The interrupt is triggered at the rising edge of the Data pin which wakes the CPU.
  • The START condition is sent first and the ACK is checked. The interrupt is now enabled, and the CPU is put to sleep.
  • To transmit a ‘0’ (Logic LOW), the sensor sends a 54 us low signal followed by a high signal. This LOW to HIGH transition wakes up the CPU.
  • If the sensor is transmitting a ‘0’ then it sends a 24 us high signal followed by the 54 us low signal of the next bit. If the sensor is transmitting a ‘1’ then it sends a 70 us high signal followed by the 54 us low signal of the next bit.
  • Therefore, the value of Data pin is read after a delay, greater than 24 us, which gives the value of the bit. So, if the bit is ‘0’ then after 24 us the Data pin is low and if the bit is ‘1’ then after 24 us the Data pin is high. Hence, reading the data pin after the will directly provide the bit that was sent by the sensor.
  • This is repeated for 40 times (for 5 bytes) and the bit values are stored in a separate variable for each byte. The interrupt is then disabled.
  • The checksum is verified by summing the first four bytes and checking with the fifth byte, and the temperature and humidity values are calculated. The firmware can then run the application to process these values (in this case report to the user via UART protocol).
  • All the variables are cleared for the next iteration and the process is repeated.

 

Application 2:

 

  • The second approach is simpler and more direct without the use of any interrupts.
  • START condition is sent as usual. A counter variable is incremented continuously from the START condition until the next rising edge.
  • The entire duration will be a little over 54 us which is the ACKNOWLEDGEMENT and the counter variable value is stored. If the counter value is more than the maximum allowed value (user-defined), it means there is a communication error. So, communication is terminated and needs to be restarted.
  • The counter variable is reset, and the CPU waits till the signal is low – for the 54 us low signal of the first bit. The counter variable is again incremented for as long as the Data line is high. If the counter value is greater than half of the previously stored value (half of 54 us ~ 27 us) i.e., if the data signal is high for more than 24 us, then the bit value is 1 or else, it is 0.
  • This is repeated 40 times and the bit values are stored in a separate variable for each byte.
  • The checksum is verified, and the temperature and humidity values are calculated. The firmware can then run the application to process these values (in this case report to the user via UART protocol).
  • All the variables are cleared for the next iteration and the process is repeated.

 

Comparison of the two approaches:

 

  • The first approach is to be used when power efficiency is crucial. The CPU remains in Sleep state for almost half the time during communication and wakes up only to read the bit value thereby increasing power efficiency. Please refer to the respective device datasheet for information regarding the current consumption of the device in Active and Sleep mode.
  • The second approach is more reliable comparatively and the user need not worry about interrupt latency, interrupts not getting triggered or false interrupts. The program can easily be ported. The only disadvantage being that this method polls for bit value, wasting the CPU processing time.
  • Also, for the second application to work as expected, there should not be any interrupts disturbing normal code execution flow during the communication. If that happens the communication fails. To avoid this the communication logic in the code is put in a critical section.

 

 

Note:

  • The projects have been tested on CY8CKIT-062-WIFI-BT using PSoC Creator 4.3 and PDL 3.1.1.
  • DHT-22 also follows the same communication protocol and the same projects can be used to interface the DHT-22 sensor.