Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Pancho <Pancho.Jones@proton.me>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: Need help with PI PICO...
Date: Tue, 26 Mar 2024 21:58:09 +0000
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <utvgdi$2cg59$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>
 <uts6t5$163q2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 26 Mar 2024 21:58:11 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1ec13bc17cc71cba7c8441755c54b811";
	logging-data="2506921"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1911kvPBtILOHcO85zhpv1QkpAjhwireUU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:1vaC4CJbDBynLZzGE0N0hVyfWyc=
In-Reply-To: <uts6t5$163q2$1@dont-email.me>
Content-Language: en-US
Bytes: 3077

On 25/03/2024 15:57, The Natural Philosopher wrote:
> 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
> 

A timer isn't complicated, just a call back routine, and a semaphore. 
Interrupts are something an OS does, not me :o). I hate multithread 
code, but async handling of an external resource is one of the two main 
places I would use another thread.

I had a look at your code, it looks extraordinarily like a python 
example on Tom's hardware.

I'm not clear how many times it is succeeding vs failing, but I suspect 
you really need to bite the bullet and introduce timeouts/error 
handling, if it fails try again, average out multiple results. i.e. 
accept it as flawed and that results are statistical, like GPS.

In many ways the resilience code will be simple, because it is just 
normal code, rather than cargo culting a novel ultrasonic device.

You can investigate further, by recording fail stats, as well as 
distance stats.