Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: The Natural Philosopher <tnp@invalid.invalid>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: Need help with PI PICO...
Date: Fri, 29 Mar 2024 13:37:08 +0000
Organization: A little, after lunch
Lines: 184
Message-ID: <uu6g64$a7t1$3@dont-email.me>
References: <utn4f2$3p985$1@dont-email.me>
 <20240323183723.b2902fb94d75422b924c1bc7@eircom.net>
 <utnkjj$3t5m0$1@dont-email.me>
 <20240324072346.81064ff46570e669982a1f4e@eircom.net>
 <utp1sm$acjh$1@dont-email.me> <utrna6$113rn$3@dont-email.me>
 <uts6t5$163q2$1@dont-email.me> <utvgdi$2cg59$1@dont-email.me>
 <uu0rh5$2pcls$1@dont-email.me> <uu53c6$3tc51$1@dont-email.me>
 <uu66b9$83pi$3@dont-email.me> <uu6eqv$714f$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 29 Mar 2024 13:37:09 +0100 (CET)
Injection-Info: dont-email.me; posting-host="26cac3dc2e2ba3d6cb23b9feb54ec975";
	logging-data="335777"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX187+1QlNPAvmCRKr+12fX+wcRXKN4DrotM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MeR8Q7GWOitf59tFHrpcDYFI45E=
In-Reply-To: <uu6eqv$714f$2@dont-email.me>
Content-Language: en-GB
Bytes: 8550

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.

========== REMAINDER OF ARTICLE TRUNCATED ==========