Sujet : Re: Need help with PI PICO...
De : tnp (at) *nospam* invalid.invalid (The Natural Philosopher)
Groupes : comp.sys.raspberry-piDate : 27. Mar 2024, 13:18:28
Autres entêtes
Organisation : A little, after lunch
Message-ID : <uu12qk$2r0cg$3@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10
User-Agent : Mozilla Thunderbird
On 27/03/2024 11:59, David Higton wrote:
In message <uu0rh5$2pcls$1@dont-email.me>
The Natural Philosopher <tnp@invalid.invalid> wrote:
I am slightly curious as to how the PICO could miss what is a several
hundred microsecond wide pulse.
AFAICS there are many pitfalls:
1) An interrupt can be being serviced, so the pulse is over before you
get to see it.
2) If you're looking for a pulse, you should be looking edge triggered
rather than level triggered, but even then you may not get to react to
the edge immediately because of an interrupt being serviced, so you'd
get an anomalous result.
3) You can look level triggered, but you need to turn off all interrupts
to ensure you really are loking at it in real time.
4) I had a play with an ultrasonic ranger a couple of years or so ago.
I couldn't understand why I wasn't getting any return pulses at all.
I eventually realised that I was sending another start pulse before
the current cycle had finished.
Regardless, you need an escape from any and every potential infinite
loop. Whatever you're doing.
If you can use a hardware timer in the chip, that's a much more reliable
solution.
David
Thanks David
All make sense.
I think the next stage is to provide an escape from the infinite loops, that documents itself and see where its hanging.
If interrupts are buggering it up, I am not sure how using an interrupt would not also be buffered up by an interrupt.
The LWIP stack is all interrupt driven and I am loath to mess around for fear of breaking comms.
In the end the pragmatic answer may be to simply abort a failed reading and try again.
-- In todays liberal progressive conflict-free education system, everyone gets full Marx.