Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.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: Mon, 25 Mar 2024 15:57:25 +0000
Organization: A little, after lunch
Lines: 72
Message-ID: <uts6t5$163q2$1@dont-email.me>
References: <utn4f2$3p985$1@dont-email.me>
 <20240323183723.b2902fb94d75422b924c1bc7@eircom.net>
 <utnkjj$3t5m0$1@dont-email.me>
 <20240324072346.81064ff46570e669982a1f4e@eircom.net>
 <utp1sm$acjh$1@dont-email.me> <utrna6$113rn$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 25 Mar 2024 16:57:26 +0100 (CET)
Injection-Info: dont-email.me; posting-host="81f8b70d9843cfe2836fddc8de21ad3c";
	logging-data="1249090"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/P8S3Q87t7E5+xoy6g+4w15ehV2IOTiAY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:qIHnDS2YsxlG1BcPf/lnKXnrPCM=
In-Reply-To: <utrna6$113rn$3@dont-email.me>
Content-Language: en-GB
Bytes: 3763

On 25/03/2024 11:31, Pancho wrote:
> On 24/03/2024 11:13, The Natural Philosopher wrote:
> 
>> However on trawling the internet I discovered a conversation  with 
>> someone else *on here* (c.s.r-pi) last year, who was finding that 
>> *sleep_us(x)* was highly inconsistent for certain (small) values of x. 
>> Sometimes taking a day to end.
>>
>> Further investigation reveals that in fact it really is a 'sleep' with 
>> the processor being put in low power mode and requiring an interrupt 
>> to 'wake it up'.
>>
> 
> Why not use threads/timers, wait on a lock/semaphore rather than sleep.
> 
Good point Pancho, but I was really looking for the simplest code 
possible.  Interrupts can be tricky things on a platform whose 
architecture you do not understand completely. In any case it was a 
learnning curve I preferred not to negotiate if i didnt need to

> But looking at PICO code samples, they commonly use sleep, so I'd be 
> surprised if it was that bad.
> 
I am veering away from that explanation, as with the test board located 
at some distance from any target, the problem has not reappeared.

I am beginning  to think that it may be possible for the echo pulse to 
'come *and* go' before the high level PICO code has got round to 
actually looking for it in the first place.

That is, some asynchrounous event in this sequence

	gpio_put(ULTRASONIC_OUT,1);
	sleep_us(10);
	gpio_put(ULTRASONIC_OUT,0); //reset the input
//if asynch event lasting more than 100uS occurs here...
	// wait for echo pulse start
	while(!gpio_get(ULTRASONIC_IN))
		;
//then the low-high-low echo pulse will never be detected.

It is also not clear from the documentation whether it is the low to 
high, or the high to low sequence, that triggers the ultrasonic board.

If it is low to high, then there is an opportunity for an occasional 
very  long delay in the	

sleep_us(10);

to delay resetting the pulse until Elvis has left the building,. so to 
speak...

So I have tow things to do. Understand how the ES module works in terms 
of timings, and replace that sleep_us with a different delay mechanism.
It's now been 24 hours with no lockup with a distant target...

OIL-SENSOR
OIL-TANK
-85dBm
57.60cm
23.7°C
4.6V

I have noticed that with absoluteley no change in sensor location I get 
up to ± 0.5cm variation in delay.

-- 
If I had all the money I've spent on drink...
...I'd spend it on drink.

Sir Henry (at Rawlinson's End)