Closed grukx closed 1 year ago
Hi, thank you for your issue.
I had a lot of problems with the timeout ^^ Because my timing was not very good. In the latest version (0.4.0), I have, normally, corrected this. Which version are you using? Is the DHT you use a breakout board or just the sensor? Is the pull-up resistor present? The capacitor too?
Jonathan
I am using 0.4.0 - tried 0.30 as well, with no louck. Its a breakoutboard and from I can see (and measure) its a 5.1k pull-up and a capacitor (unknown value, but small ceramic smd so not a lot).
Its kind of strange that this should be timing out. The signal looks nice enough on the scope and the timing looks to be according to the spec. and what the pio code should generate. I have no idea how to debug pio unfortunately :( Only thing I can think of is that the SM is not seeing the signal transitions properly, but they seem to be fine around the 1.6V mark (I am assuming this is close to trigger threshold, but havent checked Pico datasheet on this)
Geir
Very strange... I will observe the signal on my oscilloscope and measure the voltage. It seems the minimum threshold voltage is around 1.3V for the Pico.
Every PIO instruction take 1 cycle (I calibrate the cycle to 1 µs), so it shouldn't be the problème.
Which version of the Pico are you using ? All measure returned a timeout or just sometimes ?
Oh !
I've just tested it on GPIO10 and it didn't work for me either...But it works on GPIO0....
Maybe it's the into_function()
that's causing the problem...
There is no functional pin other than GPIO0 ^^. I must have missed something during configuration. (Investigating after work)
Got it!
The WAIT
instruction searches for the waiting pin from PINCTRL_IN_BASE
, in the rust lib it's the in_pin_base
function that defines this value. However, as I ran my tests on pin 0 and the default value of PINCTRL_IN_BASE
is 0, no problem. But as soon as you want to change pin, problems arise...
I took the opportunity to specify the output pins via out_pins
, which certainly had the same problem...
I'm currently pushing version 0.5.0 on crates.io, can you test it and tell me if it works for you too?
0.5.0 worked perfectly!
Thank you so very much for fixing this so quickly.
Geir
Without you I probably would never have found this bug ^^ So thank you very much!
Thanks for a great attempt at making a PIO base DHT crate.
I have tried to make your crate work, but without success. The readback of data fails with a timeout. I can see (with oscilloscope) that the readback is correctly triggered and that the protocol timing looks ok. Setting breakpoints in the dht.rs read_data() I can see that the response from the DHT22 is immediately after the self.tx_fifo_write(1). So the sm is running. But there is no data sampled and self.rx_fifo.read() always returns None. I cannot see any obvious flaws in the pio program, but I am not an expert at this. Any idea of what could cause this?
I have also compiled your example (using gpio10 btw) and it also returns timeout.
Br. Geir