Add timeouts in read functions for reliability #2
Conversation
Timeouts avoid getting stuck in infinite loops if the sensor does not respond as expected. Now if the sensor does not respond we return a DhtError::Timeout and the user can choose how to handle it.
src/lib.rs
Outdated
| //! ## Notes | ||
| //! | ||
| //! On the bluepill (STM32F103) the pin seems to be pulled low by default causing the sensor | ||
| //! to be confused when actually reading it for the first time. The same thing happens when | ||
| //! the sensor is polled too quickly in succession. In this case you will get a `DhtError::Timeout` | ||
| //! | ||
| //! To avoid this, you can pull the pin high when initializing it and polling the sensor with an | ||
| //! interval of at least 500ms. |
There was a problem hiding this comment.
I think you can add this before the above ## Example heading, worded in a non chip specific way
src/lib.rs
Outdated
| //! } | ||
| //! | ||
| //! // Delay of at least 500ms before polling the sensor again, 1 second or more advised | ||
| //! delay.delay_ms(500_u16); |
There was a problem hiding this comment.
You can also add this loop reading to both examples and call out the minimum delay there.
src/lib.rs
Outdated
| //! let mut dht = gpiob.pb15.into_open_drain_output(&mut gpiob.crh); | ||
| //! | ||
| //! // Pulling the pin high to avoid confusing the sensor when initializing | ||
| //! dht.set_high().ok(); |
There was a problem hiding this comment.
I think you can update the above, existing example and /examples/stm32f042.rs with a set_high().unwrap()
My pleasure, thanks for the crate 😉
Yes, I especially like the for loop instead of the wile loop. 👍 I'll update the documentation with the suggested changes. |
michaelbeaumont
force-pushed
the
bluepill
branch
from
6e834ab to
f9ea223
Compare
Yeah, good to know, I'll pick one up as my first scope once I can justify buying it to myself 😅 |
Hi!
As mentioned in #1, I have implemented a simple timeout strategy for the read functions. This should remove any possibility to end up in an infinite loop.
After some analysis of a bluepill with a DHT22 I have adapted the timeout values to be a bit tighter towards the measured values.
As can be seen in the pictures below the whole communication (after releasing the pin) takes less than 5ms and the individual state changes take between 26 and 78µs. Therefore I set the timeouts to 100µs. This hasn't given me any problems, but it might be worth to test it with a couple of other sensors and especially the DHT11 (I can't test because I don't have that variant).
I have also added the example for the bluepill that I used in the doc, however since the setup of crates, configuration, memory layout is different I marked it as
ignoreso that it does not throw any errors. I'm not sure how we can have examples for multiple boards that compile.Let me know if I can improve something
Fixes #1