Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: The Natural Philosopher <tnp@invalid.invalid>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: Need help with PI PICO...
Date: Sun, 24 Mar 2024 11:43:27 +0000
Organization: A little, after lunch
Lines: 54
Message-ID: <utp3l0$bcu6$1@dont-email.me>
References: <utn4f2$3p985$1@dont-email.me>
 <QZq*00-Fz@news.chiark.greenend.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 24 Mar 2024 11:43:28 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="7cae268abee9cfb09fee7c9189a2892f";
	logging-data="373702"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ZrpSOwuYfHdZjwQACtMrDQ30pVNQ+Dhg="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:5hyn+YPQjiUpBZ0MEykoA5+N4/U=
In-Reply-To: <QZq*00-Fz@news.chiark.greenend.org.uk>
Content-Language: en-GB
Bytes: 3069

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