d2r2
commented
7 years ago Hi @Stanier!
You have a good chance to rewrite it in clear golang :) I'm not sure that you will be succeed, but there is a reason that you will be succeed. Few years ago, when I wrote this interaction with DHT sensor, I found that it not work in clear golang because of Garbage Collector "stop-the-world" problem. "Stop-the-world" lead to unpredictable interruption of your app in golang when it can take up to 10 milliseconds and more (taking in account that golang environment run on low performance embedded device this time might be significantly bigger). In this specific case if pause emerged in the process of reading data from sensor it lead to destructive results - your will miss 1 or few bits from sensor. Thanks to golang creators they pay much attention to this problem and with fresh golang installation (>= go 1.5) GC "stop-the-world" pause is almost either completely eliminated.
Regarding difference in sensors - I do not see significant discrepancies in sensors specification. Protocol is the same, delays almost the same: 1) DHT11: 54 ms + 24 ms = 78 ms for bit '0'; 54 ms + 70 ms = 124 ms for bit '1' 2) DHT22: 50 ms + 26 ms = 76 ms for bit '0'; 50 ms + 70 ms = 120 ms for bit '1'
May be you exceed somehow array limits in the process of reading from sensor? Could you give me a link to your code and send how warnings looks like?
If you still have some doubts about times from the code, please specify which place in gpio_read_seq_until_timeout raises questions, I will try to remind what thoughts were behind it.
So I created a fork of this project in an attempt to achieve a completely "go-only" implementatiton (I know, sue me, but I have my reasons).
I got everything working, but noticed that the errors I had periodically received warning of invalid array lengths were now much more frequent. When I started digging through the code, I noticed that the function
gpio_read_seq_until_timeoutsleeps for times not quite on par with the DHT11 single-wire communication bus specification, though mostly compatible with it's DHT22 counterpart.My question is this: do these functions actually support the DHT11 communication bus? Are the delays in place somehow calculated to work for both DHTxx models?