Error Timeout

[pdgilbert]

I forked dht-sensor and have been adding an example that should work with several HALs and several MCUs. It also has a feature to use DHT11 or DHT22. So far, it builds with HALs stm32f0xx , stm32f1xx , stm32f3xx , stm32f4xx , stm32h7xx , stm32l0xx , stm32l1xx and on MCUs stm32f042, stm32f030xc, stm32f103, stm32f100, stm32f101, stm32f303xc, stm32f401, stm32f411, stm32f411, stm32h742, stm32l0x2, stm32l100, stm32l151.

Unfortunately I forked after a change that seem to have broken something. Using the suggestion of @azerupi in #1 to pull the pin high before initializing, my example ran on stm32f401 with DHT11 using c18aaea. With DHT22 (actually an AM2302) it crashed giving

panicked at 'attempt to add with overflow', /rustc/c7087fe00d2ba919df1d813c040a5d47e43b0fe7/src/libcore/ops/arith.rs:94:45

With the next commit, 28927cd, both the DHT11 and DHT22 give repeated 'Error Timeout' messages on all MCUs I have tried (stm32f103, stm32f401, stm32f411).

Any ideas?

[michaelbeaumont]

@pdgilbert can you try increasing the timeout_us parameter to say 1000 (in the lines introduced by that most recent change)?

[pdgilbert]

In the file src/read.rs there are four lines

    wait_until_timeout(delay, || pin.is_high(), 100)?;

The 100 is the timeout_us parameter, which is u8, so I can only change it to 255, not 1000. Changing the four lines to 255 has no effect. In the function fn wait_until_timeout<E, F> there is a line

        delay.delay_us(1_u8);

I can change that to

        delay.delay_ms(100_u8);

This also has no effect other than to slow down the repetition of Error Timeout.

[azerupi]

Hi @pdgilbert,
I have been trying to find the problem for the last two hours. Testing my example it worked, yours not so much. I tried to reduce your example until I practically had the same as my code, but still it would not work.

Until at some point I had a realization. The cargo run command in your example that I had been copying does not include the release flag. When not using release, optimizations are turned off and performance is pretty bad. So bad in fact that it messes up the timings when reading the bits when the sensor responds.

Changing your command to cargo run --target $TARGET --features $HAL,$MCU,dht22 --example dht-multi-hals --release worked for me. I have been successfully reading the temperature for the last 5 minutes 😉

Let me know if that solved the issue for you too.

Edit: Ok, apparently I spoke too soon. I reverted the changes I made to the code and it stopped working again. I will try to find what changed. I'll come back to you.

Edit2: My mistake, when reverting the code I aslo reverted back to the old pin which is not the same as in my setup. --release is definitely working 🙂

[michaelbeaumont]

@pdgilbert Sorry, wasn't a good suggestion. Got it in my head that I may have misread the timing in the datasheet when I made a change in that PR but the timing is correct.

@azerupi Thanks for taking a look, you saved me having to hook up my sensor 🙂

[pdgilbert]

Ok, I can confirm that adding --release seems to be the trick. I have now tested on bluepill with both dht11 and dht22 and it works. At the moment I'm having a bit of a jtag status problem on my blackpill stm32f401 but will report back after I shake a few wires.

[pdgilbert]

I have now tested running with --release added and it works with both DHT11 and DHT22 on bluepill (stm32f103), blackpill-stm32f401, and blackpill-stm32f411. There are run time errors :

• discovery-stm32f303 reports both DHT11 and DHT22 once but then fails at delay.
• discovery-stm32l100 gives Error Timeout with both DHT11 and DHT22.

The discovery-stm32f303 problem may be some conflict in the delay code, probably not a dht-sensor crate issue. The discovery-stm32l100 problem might require lengthening the timeout, but possibly this needs to be a parameter that can be set for slower processors? I don't use these boards or MCUs other than for this kind of test, so I don't have any need for them to be fixed. (And they may get fixed by newer hal versions.)

I have document most of this in comments in the dht-multi-hals example, along with the details for running the example with different MCUs.

A version of this example is reported at https://pdgilbert.github.io/eg_stm_hal/ along with other examples. The results reported there use current git versions of the hals whereas results above use release versions. (I will update the report to indicate the example runs.)