Repository navigation
Fixed DHT timing error, Issue #5848 - #6044
seiuvwcdhol wants to merge 1 commit into
Conversation
|
The huge problem with this is on low end targets like esp8266, if you block interrupts for such a long time you interfere with PWM, making light flashes when leds are connected (even 3ms is too much here). On my side, since ESP8266 is not multi threaded, I took opposite approach and removed the interrupt blocking even for reading the values, to avoid these PWM issues. So the fix you propose is perfectly fine for your issue but is a total no-go for esp 8266 (and maybe other targets ?) Maybe it is time to differentiate dht implementations across different ports ? |
|
This is an automated heads-up that we've just merged a Pull Request See #13763 A search suggests this PR might apply the STATIC macro to some C code. If it Although this is an automated message, feel free to @-reply to me directly if |
|
Sorry no one got to review this PR until now. I think it's a good idea to be able to configure the initial timing values for the DHT protocol. I think it should be possible to configure both the 250ms and the 18ms delay, to arbitrary values. This PR itself is outdated and won't rebase or merge (due to |
4 participants
I fixed an error in the DHT driver which occurs if the system load is high: If there are many Python threads running, the DHT driver constantly reports a timeout error ETIMEDOUT. If the system load is low, there is no error.
The solution is to wait uninterruptable with mp_hal_delay_us_fast instead of interruptable with mp_hal_delay_ms.
As a further optimization if have added a parameter to the function dht_readinto to know if we have DHT11 or DHT22. The reason: DHT11 needs 18ms waiting after pulling the bus low, but DHT22 needs only 1-3ms waiting after pulling the bus low.
The python classes DHT11 and DHT22 have also been extended to store the DHT version in a member variable.
This solves the issue #5848 as was discussed with dpgeorge.
Stefan Hammes, Karlsruhe