Re: Need help with PI PICO...

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