ESP32 + DHT + SAUL reading two endpoints causes freeze.

[mmaxus35]

BOARD=ESP32
Related features: esp32, saul, dht sensor.
I have a definitions as follows:

Using SAUL i try to gather temperature and humidity values. However, in dht there are two and points and i tried to gather both of them. Using saul_reg_find_type(SAUL_SENSE_HUM); i can switch to gathering humidity but this time i cannot acquire temperature. So, i tried to do following logic. However, then i try to read two values at " **HERE ** " chip stops running and led never blinks. I couldn't understand why and if there is a way to acquire both temperature and humidity values using one saul_reg_read( ) function. Because if you have more than one for one device for two endpoints it freeze the chip, i think.

static saul_reg_t* saul_dht_temp;
static saul_reg_t* saul_dht_humid;

saul_dht = saul_reg_find_type(SAUL_SENSE_HUM);
saul_dht2 = saul_reg_find_type(SAUL_SENSE_TEMP);

phydat_t phy;
phydat_t phy2;

while(1){
    gpio_toggle(g2); // stops after this

    saul_reg_read(saul_dht_temp, &phy); ** HERE **
    saul_reg_read(saul_dht_humid, &phy2);

    printf("temperature: %d %d %d Humid: %d %d %d \n",
           phy.val[0], phy.unit,phy.scale, phy2.val[0], phy2.unit, phy2.scale);
}

[mmaxus35]

Sorry, it is my bad. I connected to sensor to wrong pin. However, freezing problem is a big deal. Maybe a timeout can be beneficial for saul_reg_read.

[mmaxus35]

I had to re-open this issue because during the sensor reading if a sensor is somehow lose wiring connection from any pin or it is forgotten to be wired this causes somehow freeze in the chip at the " saul_reg_read " function called.

Update: Moreover, during open terminal with "cutecom" it also causes to freeze when open/close device.
Update: I can also reproduce the problem in ESP8266.

@gschorcht @miri64

[gschorcht]

@mmaxus35 The question is, whether it is really a problem of ESP32/ESP8266 or rather a problem caused by the driver. The platform shouldn't be the problem if basic functionalities like GPIOs and Interrrupts are working stable what they seem to do. So it sounds for me rather a problem of the driver. Are you able to check it with RIOT on another platform, e.g., Arduino? As I remember, you were starting your work with some Arduino sketch.

[mmaxus35]

@gschorcht I managed to run Arduino example in the Riot examples folder. I will edit my code and give feedback about it.

Update: I tried it in the Arduino platform and reproduced the same problem. It freezes where saul read operation is made.
Here is the code that I used.

`#include <stdio.h>
#include <string.h>
#include "xtimer.h"  //for udp and tcp and processes
#include "thread.h" //for threads
#include "msg.h" //for threads

#include "periph/gpio.h"

//#include "net/ipv6/addr.h"  //for udp and tcp

#ifndef ARDUINO_LED
#define ARDUINO_LED     (0)
#endif


#ifdef STDIO_UART_BAUDRATE
#define SERIAL_BAUDRATE STDIO_UART_BAUDRATE
#else
#define SERIAL_BAUDRATE 115200
#endif

// Assign the default LED pin
int ledPin = ARDUINO_LED;

// input buffer for receiving chars on the serial port
int buf[64];

// counter that counts the number of received chars
int count = 0;

void setup(void)
{
    // configure the LED pin to be output
    pinMode(ledPin, OUTPUT);
    // configure the first serial port to run with the previously defined
    // baudrate
    Serial.begin(SERIAL_BAUDRATE);
    // say hello
    Serial.println("Hello Arduino!");
}


#include "saul_reg.h"
#include "xtimer.h"
static saul_reg_t* saul_dht;



void loop(void){
digitalWrite(ledPin, !digitalRead(ledPin));

phydat_t phy;
phydat_t phy2;

//gpio_toggle(g2);
//printf("%d \n",gpio_read(g15) );

//int res=0;

// res = saul_reg_read(saul_dht, &phy);

//saul_dht = saul_reg_find_type(SAUL_SENSE_HUM);


//int res = saul_reg_read(saul_dht, &phy);


Serial.println("before");


saul_dht = saul_reg_find_type(SAUL_SENSE_TEMP);
//saul_reg_read(saul_dht, &phy);  //uncomment to test

saul_dht = saul_reg_find_type(SAUL_SENSE_HUM);
//saul_reg_read(saul_dht, &phy2); //uncomment to test

Serial.println("after");
Serial.println(phy.val[0]);
Serial.println(phy2.val[0]);


xtimer_sleep(1);
}
`

[Eleftheria-99]

@mmaxus35 Which pins did you use ?

[maribu]

I recall the that DHT driver didn't had a timeout for unsuccessful reads at some point in time. Likely this in combination with a cabling / configuration issue cause this.

Anyway, the DHT driver does now reliably report back communication issues rather than freezing and without further input from the reporter, we cannot provide further assistance. Thus, I'm closing this now.

@mmaxus35: If you want to give this another spin, I would gladly help out you run into issues again.