Re: Need help with PI PICO...

On 24/03/2024 09:39, Theo wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

It would seem from the pin states that it gets permanently stuck in
>
while(!gpio_get(ULTRASONIC_IN))
                 ;
>
Which as understand it is waiting for the module (HCSR04) to *start* to
send a pulse.

 Can you scope it to see if the module is actually sending a pulse?
 

I could, but in fact it was easier to simply look at it in 'stuck' mode with a DVM.

Is the pulse perhaps too short for the Pico to detect?  eg if the loop or
gpio_get() function took some time, it could be the signal goes 0-1-0 in the
middle of a loop iteration and so the gpio_get() never sees it go 1.
 

As you can see from my last reply that is roughly where I am headed. Or similar. Lacking full ICE., its all a bit 'poke the black box with different sized sticks, and try and infer from what it does, what is happening inside it'
I think this must be where it sticks, because this is the only infinite loop with both input and output to the module in a low state, which is what I measured:
gpio_put(ULTRASONIC_OUT,1);
sleep_us(10);
gpio_put(ULTRASONIC_OUT,0); //reset the input
// wait for echo pulse start
while(!gpio_get(ULTRASONIC_IN))
;
I.e that it (allegedly) sends a 10µs wide high pulse, and then waits for that to trigger a response from the unit, but that response never happens.
However that should not vary with the echo *delay*, and a longer target distance seems to improve things..
...unless, thinking a bit more, the pulse is so short it comes *and* goes inside that loop, as you suggested.. it certainly should *not*  be, as even on a few cm of target distance, its hundreds of microseconds (i make it 58µs per cm roughly)

Theo

--
“It is dangerous to be right in matters on which the established authorities are wrong.”
― Voltaire, The Age of Louis XIV