INTL 3:770/1 3:770/3
REPLYADDR tnp@invalid.invalid
REPLYTO 3:770/3.0 UUCP
MSGID: 82101ef6
REPLY: 69740f9f
PID: SoupGate-Win32 v1.05
On 29/03/2024 13:14, Pancho wrote:
> On 29/03/2024 10:49, The Natural Philosopher wrote:
>> On 29/03/2024 00:52, Pancho wrote:
>>> On 27/03/2024 10:13, The Natural Philosopher wrote:
>>>> 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.
>>>>
>>>
>>>
>>> I understood the idea of a ping delay time. It is just my experience
>>> that things rarely work exactly as I expect them to.
>>>
>>> FWIW, I'd also massively underestimated the difficulty of coding the
>>> PICO, I'd assumed it was running a multitasking OS, like busybox, but
>>> I see it isn't. I guess there are a whole bunch of gotchas there too.
>>>
>>>> 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.
>>>>
>>>
>>> I'm unclear on terms, but that sounds like the length of the pulse,
>>> 10µs. Not the distance travelled by the pulse. Surely, you should be
>>> measuring the time between sending the pulse and receiving the pulse.
>>> I've probably misunderstood something, if the code is giving a
>>> sensible distance.
>>>
>> No.
>> Maybe ascii art will help
>>
>> CONTROL=10µs
>> ____| |________
>>
>> RETURN = wahatever
>> _____|^^^^^^^^^^^^|____________
>>
>
> Yeah, I know what a ping is supposed to do. It is the time interval
> between sending a ping and receiving the echo, simples. But... that
> isn't what your code looks like.
>
> You have:
>
> while(!gpio_get(ULTRASONIC_IN));
> //read clock and store
> start=get_absolute_time ();
>
> Which is presumably waiting for silence, no echo, it might work if that
> is the default start state, i.e. if it does nothing, but it is
> redundant. You should start the time interval when the ping is sent.
>
That is what the code does. You send a trigger pulse,. The board farts
around, waits, sets its output high to mark the pulse start, and then
low when it ends
That code is waiting for the pulse to *start*
> A short pulse always fails? I wasn't clear if it just made it more
> vulnerable to failure. Failure caused by something else? Maybe
> wavelength? Interference. I really don't know. I don't know how you can
> rule stuff out. Apart from empirically, test reliability, in which case
> you need to record failure stats as well as success.
>
The shorter pulses failed *sometimes*, the longer ones never did.
New code is in and it hasn't failed yet...
static float get_distance()
{
int i;
absolute_time_t start;
absolute_time_t end;
static int64_t us_delay;
//set output pin high
gpio_put(ULTRASONIC_OUT,1);
busy_wait_us(10); //sleep_us() possibly unreliable here
gpio_put(ULTRASONIC_OUT,0); //reset the input
// wait for echo pulse start
for (i=0;i<100000;i++)
{
if(gpio_get(ULTRASONIC_IN)) //pulse start
{
//read clock and store
start=get_absolute_time ();
//wait for echo pin to go low;
while(gpio_get(ULTRASONIC_IN))
;
end=get_absolute_time ();
//get clock difference
us_delay=absolute_time_diff_us(start,end);
//convert to float and return it as cm
return (((float)(us_delay))*0.034/2);
}
}
//we ran out of time here.
return(0.0);
}
>> You can get some sort of Free BSD RTOS port to a Pico, but in fact
>> mostly what you tend to be doing is just one thing at a time and so
>> linear code with callbacks works pretty well
>>
>
> Yeah, you say that, but virtually all my experience is based upon a
> multitasking OS: VMS, Unix, Windows NT, Linux. I can't remember stuff I
> did in the early 1980s. I have a huge store of experience, intuition, in
> the multitasking Posix like world, none in single process.
>
Well I cut my teeth on assembler on Z80s and 8080s and bare metal
programming LONG before Unix was part of my knowledge
> I'm a little paranoid, pessimistic, I think the world is out to mess me
> up. If things can go wrong, they will go wrong, which is why I'm
> unwilling to step into such a different paradigm.
>
It's like going back to the days spent messing around in BASIC on 6800
kits my friend had built.
Its just another way of doing stuff. Like a coder friend once said 'it's
all just bits, in silicon'
:-)
>
>
--
In theory, there is no difference between theory and practice.
In practice, there is.
-- Yogi Berra
--- 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/220
SEEN-BY: 135/225 153/757 7715 218/0 1 601 700 840 870 930 220/70 221/1
SEEN-BY: 221/6 226/17 30 100 227/114 229/110 111 112 113 200 206 307
SEEN-BY: 229/317 400 426 428 470 550 616 664 700 240/1120 266/512
SEEN-BY: 267/800 282/1038 291/111 292/854 301/1 113 812 310/31 320/219
SEEN-BY: 322/757 335/364 341/66 342/200 396/45 460/58 633/280 712/848
SEEN-BY: 770/1 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
|
