DHT11 - how to avoid delay?

How can one use the DHT sensors without holding up the entire execution of the Arduino?

I get that it takes a good second or two to read the temp/humidity, but dang, this needs to be done out of process. The libs I have found are full of inline delay() statements, such as: http://playground.arduino.cc/Main/DHTLib http://learn.adafruit.com/dht/using-a-dhtxx-sensor

Found this post, but the code is in a Sketch rather than a library, which is not ideal: http://forum.arduino.cc/index.php?topic=107553.0

And then I found this Lib that uses Interrupts, but I'm a noob at Arduino, and have no idea how to wire things up. http://forum.arduino.cc/index.php?topic=176332.0

Similar to above, a modified version of the idDHT11, again, no idea how to use it https://github.com/adalton/arduino/tree/master/projects/Dht11_Library

Is it possible to do what I am after? And possible to do without having to dive into driver land (I'm not that level of a hardware coder, I just need a good library, and wiring examples).

I really miss .NET Micro Framework. spin up a new thread, no problem. Set up callbacks and build an event based app, no problem. OO programming, no problem. Shewt.

Start the DHT11 measuring. Remember the time you started. Do other things. Check whether a second has elapsed since you started, by comparing the current time, to the time when you started. If not, keep doing other things. Once a second has elapsed, read the result from the device.

dapug: How can one use the DHT sensors without holding up the entire execution of the Arduino?

(I'm the author of the DHT lib and my reaction if restricted to that) There is indeed a delay(20) in the protocol. The way to solve this is to rewrite the library. Currently the lib is blocking by design. It is one object that can handle multiple sensors. If it was designed as one object per sensor - like ADaFruits - It would be possible to add a asynchronous interface to the library, something like DHT.start(); if (DHT.ready() ) { temp = DHT.temp(); hum = DHT.hum(); } For this lib it is not possible as it does not hold state per sensor.

I really miss .NET Micro Framework. spin up a new thread, no problem. Set up callbacks and build an event based app, no problem. OO programming, no problem. Shewt.

Ever thought about the FEZ processor or the NetDUino?

michinyon:
Start the DHT11 measuring.
Remember the time you started.
Do other things.
Check whether a second has elapsed since you started, by comparing the current time, to the time when you started.
If not, keep doing other things.
Once a second has elapsed, read the result from the device.

Thank you, but I know. This is what I am doing, else I wouldn’t have submitted this post. But there is still a blocking process (of about 21ms) that I was hoping to avoid even when trying to “do other things”.

robtillaart, thanks for the insight. A Start() / Ready() architecture would be awesome, and in my case, I only need a single device anyway. And yes, I use FEZ with C# for doing any serious work, threading, and projects that are network intensive and interact with real, online connected scenarios, but two things that drive me to Arduino are 1) insanely low cost when processor and network is not needed, and 2) WAY more community support and libraries, etc.

dapug:

michinyon: Start the DHT11 measuring. Remember the time you started. Do other things. Check whether a second has elapsed since you started, by comparing the current time, to the time when you started. If not, keep doing other things. Once a second has elapsed, read the result from the device.

Thank you, but I know. This is what I am doing, else I wouldn't have submitted this post. But there is still a blocking process (of about 21ms) that I was hoping to avoid even when trying to "do other things".

robtillaart, thanks for the insight. A Start() / Ready() architecture would be awesome, and in my case, I only need a single device anyway. And yes, I use FEZ with C# for doing any serious work, threading, and projects that are network intensive and interact with real, online connected scenarios, but two things that drive me to Arduino are 1) insanely low cost when processor and network is not needed, and 2) WAY more community support and libraries, etc.

(think you hit some toes here ;) There is a lot of serious work done with Arduino too, even networked, but definitely lower bandwidth. Worked on the FEZ too, a few years ago and yes it worked very well. In general the applications a FEZ can do are more heavyweight than an Arduino (UNO), what I liked much was the multi-threading, giving each sensor its own thread.

OK sofar the competition ;).

The 21ms delay can probably be circumvented but that is definitely not trivial as it is in the heart of the handshake for the bits. I would need to dive into the details of the datasheet to see if and how, and at the moment I have too little time for that.