2024-02-22 02:40 PM
So, I'm trying to read data from a dht11 sensor.
In the datasheet says that you have to send high signal, wait 80ms, then low signal, and dht11 will start sending data.
My problem is, I don't know how to debug this. I don't know how to see if I my sensor is sending me data. How can I see this using STM32Cube IDE?
2024-02-22 09:14 PM
Arduino - DHT11 | Arduino Tutorial (arduinogetstarted.com)
Overview | DHT11, DHT22 and AM2302 Sensors | Adafruit Learning System
DHT11 Humidity & Temperature Sensor (mouser.com)
I think, you mean 80 micro-sec (not ms as milli-sec)?
As I understand this chip:
Break it down, how generate and sample such a waveform.
If the sensor sends you a 0 or a 1 is given by the duration how long (in time) the pin is 0 or 1.
Now, you could sample with the fastest speed, e.g. every X micro-sec. for the shortest period (e.g. a low bit). You sample with a constant speed and you get a bit stream (store it in memory):
now you can post-process the bits in memory: if you see a 101010 - it might be a sequence of bits as 0 from sensor, if it is 111111 it was a sequence of bits as 1 from sensor. If you see 10111011 - it was a sequence of bits like 0 1 0 1. Just analyze the duration and bit pattern in memory to "decode" the reponse.
You could also use GPIO interrupts plus a timer (TIM): set (or toggle) GPIO pin for falling and/or raising edge on signal and measure the time between the GPIO INTs: was it a long period - a 1 bit received, was it a short period - a 0 bit received.
Just check out what "Single Wire Interface" (SWI) is, if your MCU has support for it, or try to emulate via GPIO by "sampling" a bit sequence and do a post-processing.
BTW: you cannot really debug with steps or pausing the FW running: you can debug only on the final result. But stopping the SW (except, you would have a real SWI in MCU) will result in lost bits.
But if you use INTs, e.g. with falling and raising edge: you store also "time stamps" in memory. Later. you can use the "time stamps" in order to "measure" the duration, in order to realize a 0 vs. 1 sent from sensor.
A debugger cannot stop the sensor sending bit streams: you have to let it come in and verify later if you see the right bit pattern.
2024-02-23 09:42 AM
@pablo1409 wrote:I don't know how to debug this. I don't know how to see if I my sensor is sending me data.
You'll need an oscilloscope or logic analyser to see what the sensor's actually doing
As @tjaekel suggests, it's a widely-used sensor, so there's plenty of references and examples to look at ...
2024-02-23 09:46 AM
@tjaekel wrote:A debugger cannot stop the sensor sending bit streams: you have to let it come in and verify later if you see the right bit pattern.
Maybe; maybe not (entirely):
As the microcontroller is the Master, it "pulls" the data from the sensor - rather than the sensor just "pushing" it out.
I don't know the details of this interface but, with the Dallas 1-Wire(TM), it was only the timing within each bit that was critical - so you could halt the Master between bits...
2024-02-23 09:50 AM
First of all Thanks for using your time to give me this answer.
I don’t know most of the things you talking about. I have tried to máster the basic concepts as I did when I started learning C. I first learned about data types, conditionals, pointers, etc. But I cant find some type of roadmap to learn this kind of things in embedded programming.
Could you please suggest me any book/tutorial/course where I can learn about this concepts to be able to avoid problems like I asked?
Thanks you in advance
2024-02-23 10:13 AM
Several books out there: a good one:
Embedded Systems with ARM Cortex-M3 Microcontrollers in Assembly Language and C: Zhu, Yifeng: 9780982692622: Amazon.com: Books
Sure, understanding C/C++ is mandatory. Also some aspects how to use C/C++ for HW-oriented programming, like using H-files, libraries (HAL, BSP), accessing registers in HW, Real-Time OS (RTOS) concepts and API calls (e.g. semaphores), INT handling in MCUs, ...
When it comes to "system design" - for my feeling (experience)
In case of your sensor: you have to "learn", study fundamental things first before starting any coding. For instance: what is this "single wire interface"?, how does it work? how could you test/verify when building/programming? which HW support is there? what would you do in SW? how would you do in SW? ...
It is not magic. It is just an "organized way" to "analyze" and "synthesize". Not jumping ahead and if something is not really clear what and how: iterations (go back a bit again and maybe try to find another, better, easier way).
2024-02-23 10:39 AM
Very grateful for your answer. I will try my best and follow this advices, I feel there is a big learning curve.