Path: ...!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: Wed, 27 Mar 2024 10:13:57 +0000
Organization: A little, after lunch
Lines: 84
Message-ID: <uu0rh5$2pcls$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> <utvgdi$2cg59$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 27 Mar 2024 10:13:58 +0100 (CET)
Injection-Info: dont-email.me; posting-host="0d00ec6fd763a89ac80a664009a70bc2";
	logging-data="2929340"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/97USLJ007O7rIBYTVKInqWasp1qPotrs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:BmBxCdAKBCkCSckSgZsX4t+Q2g4=
Content-Language: en-GB
In-Reply-To: <utvgdi$2cg59$1@dont-email.me>
Bytes: 5015

On 26/03/2024 21:58, Pancho wrote:
> 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.
> 
Oh. The manufacturers sample code is the source of ALL the 'examples' 
that other people publish as their own., I am just being honest :-)

> 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.
> 
Well the averaging out will happen anyway at the server side. I make the 
clients as simple as possible for resilience. In practice oil levels 
only change quickly if you have had the oil stolen overnight or if a 
supplier has filled the tank up, so gross deviations can have code 
exceptions, the rest would be the running average of maybe 20 samples.
BUT it isn't inaccuracy that worries me per se, it's that it may be an 
indication of underlying timing issues.

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

It is:  send a 10µs pulse to the unit, wait for the echo pulse start , 
get the time, wait for the echo pulse end, get the time, subtract the 
difference.

What appears to be happening is that at short range the echo pulse never 
starts, or ends before the code is aware of it.

> You can investigate further, by recording fail stats, as well as 
> distance stats.
> 
Failure is very very rare. I am sampling for test purposes once a 
second, and its usually an hour or more before it locks up.

I could simply  turn the while loop into a for loop with a counter so 
that even if I got a null result it wouldn't lock up. Missing one sample 
is no big deal: just take another!

I am slightly curious as to how  the PICO could miss what is a several 
hundred microsecond wide pulse.

So far I have managed to get stuff reliable without having to unpick the 
ARM interrupt pandora's box. I am keen to leave it closed. The LWIP 
stack was bad enough...:-)

Obviously interrupt on GPIO pin state would be the thing, but it would 
take some research to find out what the ISR was allowed to do in terms 
of library code that was re-entrant..

-- 
Civilization exists by geological consent, subject to change without notice.
  – Will Durant