Re: Need help with PI PICO...

On 26/03/2024 17:33, Jim H wrote:

On Mon, 25 Mar 2024 15:57:25 +0000, in <uts6t5$163q2$1@dont-email.me>,
The Natural Philosopher <tnp@invalid.invalid> 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
>

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.

 Assuming the "oil" you're talking about is kerosene/heating fuel, the
speed of sound is 1330 m/sec so 0.5cm takes 3.76 micro-sec. I don't
know the specs for the PICO, but perhaps comparing that to the time it
takes to execute your code will give you an answer. I'd guess
(emphasis on guess) that +/- 0.5 cm is doing fairly well.
 

Oh the sensor is above the oil. Its just an electronic dipstick - measures distance to the oil surface.
It did over a full 30 hours on long delays. Ive modded the code *slightly* and put it back on uber short delays.
So far so good...
--
"What do you think about Gay Marriage?"
"I don't."
"Don't what?"
"Think about Gay Marriage."