DHT driver only supports AVR
simonlbn opened this issue · comments
Hey,
I wanted to try out the DHT driver for some of the DHT11 / DHT21 sensors I have, but it's AVR only and I can see it depends on time_micros() which doesn't seem implemented e.g. on ESP8266. So, my main question is: Why was it changed to use time_micros in commit
4c2b432 ?
If it's just more efficient, could the "old" way be used for MCU's which does not have time_micros ?
Separate question is - DHT11 and DHT21 are different (at least in the Arduino driver you need to select the right one as you otherwise get bogus results), so which one(s) does the Simba DHT driver support? Don't have an AVR board handy right now so I can't see what works which was my original plan.
The DHT driver has not yet been tested using real hardware. I have two AOSONG AM2302 (I believe those are DHT22) on my desk, but have not managed to test the driver with them yet.
Using sys_uptime_isr() should work, given that its resolution is sufficient. Most ports only increment the uptime every system tick, which usually is in the millisecond range.
The idea of time_micros-family of functions is to have a high resolution time with minimal overhead, to be used in drivers with hard timing requirements.
Also, the current DHT-driver implementation disables interrupts for a long time (a few milliseconds). An alternative to this implementation is to leave interrupts enabled and use the CRC to validate readings.
OK, thanks for the information!
I have a number of DHT21 and DHT11 around which I got before I found out how annoying the protocol is compared to I2C based sensors :-).
I will bring an AVR board on my next trip and may try playing with the driver against real hardware.
I think it makes sense to keep this issue open, so it's simpler to find the state of the driver and your ideas for making it work on more platforms. The DHT sensors are fairly popular / available so other people may care.
PS. extra naming fun / confusion, I recently found DHT12 which seems to be made by AOSONG, but is actually I2C based.
DHT12 is sensor (with protocol), there is many variants that outputs I2C, SPI and plain Serial packages of it.
Think like ESP ... packed as wimo, nosemcu... heart is ESP, and package is pins, power supply etc.
So, ASONG is package for DHT and exposes I2C.
Great, any help testing/using drivers is appreciated. I started working on the DHT driver 3-4 months ago and it is not yet part of any release. Would be lovely to have it working in the next release =)
Yeah, let's keep the issue open. Ideally the driver documentation should be updated with its current state/limitations.
What about system_get_time() from Espressif's sdk? Can't we use it in time_micros() implementation for esp?
/**
* @brief Get system time, unit: microsecond.
*
* @param null
*
* @return System time, unit: microsecond.
*/
uint32 system_get_time(void);
In fact, I already tried it :) And even got some readings from my DHT11, but nothing meaningful. For example I got the following bytes: 172,8,44,0,120 - the 44,0 shall denote temperature and in my case should be something around 21°C.
I also noticed, that probably reading order is reversed. In my example, 172 is checksum, 44,8 is temperature data. After reversing I'm getting successful reading, i.e. checksum is valid, but still data is meaningless, 44.8°C is too high :)
My changes are here: https://github.com/toomyem/simba/tree/dht_esp8268, just in case you would like to take a look.
Ok, I found the problem. Reading bits was wrong. The resulting byte was shifted to much to the left. I've pushed the fix to my branch also.
Now the readings are ok, but as @simonlbn mentioned earlier, the decoding formulas for DHT11 and DHT22 are different. Creating separate functions for both sensors seems to be good idea.
I've added this change to my branch too.
Using the Espressif SDK function system_get_time() might work as long as it does not enable interrupts. The DHT read_isr() functions is called with interrupts disabled, and they should preferably not be enabled within that function. I think the behavior is undefined if so.
As written earlier in this issue interrupts are disabled for a long time reading from the DHT sensor due to hard real time requirements on the bit-banged communication. Since a CRC is provided by the sensor, one could consider have interrupts enabled and return a failure code if the CRC does not match the read data.
Please create a PR with the DHT driver data shift fix. If the time_micros() implementation with system_get_time() proves to be working we can possibly merge that as well. The better solution would be to implement it using the hardware timer register(s) used by the Simba system tick, I think. Was quite some time since I looked at the ESP8266 port, so I might oversee something.
Ok, I will create two separate PRs. One with data shift fix, the other with system_get_time() function. My testing showed that this is working, however I did get crc errors from time to time. So I leave the decision of what to merge for you.
Regarding hardware based timing, I'm afraid it is not something I can easily handle by myself, but of course I will give it a try.
I think now we can close this issue and also #148.
Thank you!