Hello I have a problem receiving a data frame from a DHT11 sensor.
The program directly in C based on the NONOS SDK for ESP8266.
My idea is this. trigger a low state for 18ms (to start communication, according to ds). The sensor is connected to GPIO2. After these 18ms I configure GPIO as an input and interrupt from edges (whatever), in the callback from the interrupt I check which edge and count the time since the previous occurrence of the edge, then I have two times l_time and h_time corresponding to the duration of each level.
The "internal" clock is responsible for counting the time and I read it with the system_get_time() function;
Here's a bit of code, sorry for the mess but I've already tried on only falling or only rising edges and the code may be a bit chaotic but I wanted to get the data and then it gets added
Now I get this, the problem is that it's not what I would like .
The code above generates something similar to this in the terminal:
In the curly brackets [] is a 1, i.e. the value of dht11Data.pos which should increase after each bit, what is in front of the brackets is the read state 0 or 1 as you can see something is going down there but instead of 40 bits there are 27 sometimes 30. That is, some of the data sent by the sensor is "lost".
I have no influence on the functions provided by the SDK and in the documentation I also did not find information whether system_get_time() is "atomic", i.e. maybe some "internal" ESP processes influence the result of this function or the course of interrupts.
I'm just starting out with ESP, I've previously done an RC5 frame transmit support with an IR diode, there I used a hardware timer to generate a 36kHz carrier and that worked fine. And with this readout I have a problem.
Maybe I overlooked something and don't see something obvious anymore, I don't know. It would be nice if someone else would take a look at the idea and the code
The program directly in C based on the NONOS SDK for ESP8266.
My idea is this. trigger a low state for 18ms (to start communication, according to ds). The sensor is connected to GPIO2. After these 18ms I configure GPIO as an input and interrupt from edges (whatever), in the callback from the interrupt I check which edge and count the time since the previous occurrence of the edge, then I have two times l_time and h_time corresponding to the duration of each level.
The "internal" clock is responsible for counting the time and I read it with the system_get_time() function;
Here's a bit of code, sorry for the mess but I've already tried on only falling or only rising edges and the code may be a bit chaotic but I wanted to get the data and then it gets added
Code: C / C++
Log in, to see the code
Now I get this, the problem is that it's not what I would like
.
The code above generates something similar to this in the terminal:
Quote:.SYNC: 0:[1] 0:[1] 1:[1] 0:[1] 0:[1] 1:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 1:[1] 1:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 0:[1] 1:[1]
In the curly brackets [] is a 1, i.e. the value of dht11Data.pos which should increase after each bit, what is in front of the brackets is the read state 0 or 1 as you can see something is going down there but instead of 40 bits there are 27 sometimes 30. That is, some of the data sent by the sensor is "lost".
I have no influence on the functions provided by the SDK and in the documentation I also did not find information whether system_get_time() is "atomic", i.e. maybe some "internal" ESP processes influence the result of this function or the course of interrupts.
I'm just starting out with ESP, I've previously done an RC5 frame transmit support with an IR diode, there I used a hardware timer to generate a 36kHz carrier and that worked fine. And with this readout I have a problem.
Maybe I overlooked something and don't see something obvious anymore, I don't know. It would be nice if someone else would take a look at the idea and the code
