Sujet : Re: Need help with PI PICO...
De : tnp (at) *nospam* invalid.invalid (The Natural Philosopher)
Groupes : comp.sys.raspberry-piDate : 25. Mar 2024, 16:57:25
Autres entêtes
Organisation : A little, after lunch
Message-ID : <uts6t5$163q2$1@dont-email.me>
References : 1 2 3 4 5 6
User-Agent : Mozilla Thunderbird
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)