INTL 3:770/1 3:770/3
REPLYADDR invalid@invalid.invalid
REPLYTO 3:770/3.0 UUCP
MSGID: 8e086bd7
REPLY: f2e1da15
PID: SoupGate-Win32 v1.05
CHRS: LATIN-1 2
On Mon, 25 Mar 2024 15:57:25 +0000, in ,
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
>
>> 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.
--
Jim H
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
SEEN-BY: 10/0 1 15/0 90/1 103/705 105/81 106/201 128/260 129/305 135/225
SEEN-BY: 153/757 7715 218/0 1 601 700 840 870 930 220/70 221/1 6 226/17
SEEN-BY: 226/30 100 227/114 229/110 111 112 113 200 206 307 317 400
SEEN-BY: 229/426 428 470 550 616 664 700 240/1120 266/512 267/800
SEEN-BY: 282/1038 291/111 292/854 301/1 113 812 310/31 320/219 322/757
SEEN-BY: 335/364 341/66 342/200 396/45 460/58 633/280 712/848 770/1
SEEN-BY: 770/3 100 330 340 772/210 220 230 5020/400 1042 5058/104
SEEN-BY: 5075/35
PATH: 770/3 1 218/840 221/6 301/1 218/700 229/426
|
