On Thu, 4 Mar 2021 12:48:59 -0500, in gmane.comp.hardware.beagleboard.user
Don Pancoe <[email protected]> wrote:
>But if I used the following, would it not evaluate only at the start of the
>while loop? The main loop of the whole test lasts on the order of minutes
>even if all sub-tests pass, so how would that capture a <1sec button press?
>Or is Python an event-driven language, where a change in the evaluated
>condition will break the loop at any point?
>
>while pruio_gpio_Value(io, abortPIN)
Python is not event-driven -- Node.js/Bonescript MIGHT be such, but I
have never been able to make sense of even a short example where everything
seems to be written as a call-back function triggered by other
call-backs... I also have never been able to make sense of Python's asyncio
library either, for the same reason. Threads with some form of interprocess
(interthread) communication (Queue) is something I can work with.
The only difference between the above "while" and my "while" is that
the above is reading the pin when called, whereas mine is reading a global
variable that gets set by a call-back when Adafruit_BBIO detects a state
change on the pin. So the above may only see the button pressed at one
point in the code, and the next test may not see it -- and if the code does
not poll the pin fast enough, one may even miss the button press. libpruio
does not seem to support such -- cf:
https://groups.google.com/g/beagleboard/c/3wphAPs9Uws (which is the
underlying C level, I doubt the Python interface adds any features)
In both styles, you need to include a test (either "while" or "if") at
any point in the code where you can implement a break in execution. In both
styles, backing out from multiple levels of loops will require either a
custom exception which can be trapped at the point where you can clean-up
from the aborted loops, or some sort of "if" test immediately after a
single level "break".
while main-loop-conditional:
if abortFlag: break
while loop1-conditional:
if abortFlag: break
#do short bit of work
if abortFlag: break
#do more work
if abortFlag:
#clean up loop1 stuff
break
while loop2-conditional:
if abortFlag: break
#do short bit of work
if abortFlag: break
#do more work
if abortFlag:
#clean up loop2 stuff
break
if abortFlag:
#clean up main loop stuff
#otherwise normal exit of main loop
Note that the proposed in-line pruio_gpio_Value() version has the
problem that the state may change between reads -- so one might abort one
inner loop, but the next test finds the button is not pressed and doesn't
propagate the abort upwards.
OR using custom exception (but with 1-level cleanup)
while main-loop-conditional:
try:
if abortFlag: raise abortException
while loop1-conditional:
try:
if abortFlag: raise abortException
#do short bit of work
if abortFlag: raise abortException
#do more work
except abortException:
#clean up loop1 stuff
#if you want to propagate the abort
#reraise the exception
raise
#otherwise clear abortFlag to allow second loop
to run
#or just
break
#to move on
while loop2-conditional:
try:
if abortFlag: raise abortException
#do short bit of work
if abortFlag: raise abortException
#do more work
except abortException:
#clean up loop2 stuff
#if you want to propagate the abort
#reraise the exception
raise
#otherwise clear abortFlag to allow second loop
to run
#or just
break
#to move on
except abortException:
#clean up main loop stuff
#otherwise normal exit of main loop
OR IF you can postpone all clean-up to the end
while main-loop-conditional:
try:
if abortFlag: raise abortException
while loop1-conditional:
if abortFlag: raise abortException
#do short bit of work
if abortFlag: raise abortException
#do more work
while loop2-conditional:
if abortFlag: raise abortException
#do short bit of work
if abortFlag: raise abortException
#do more work
except abortException:
#clean up main loop stuff
break
#otherwise normal exit of main loop
Non Sequitur: "TJF" is, as I recall, the author of that libpruio package,
and pushes it as the only solution for everything related to Beaglebone
GPIO.
--
Dennis L Bieber
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/ael24gtjtf57mvkqn72kcbvcebrbkhnvte%404ax.com.
