On Sat, 24 Feb 2018 15:10:46 -0800, ewholz wrote:

> I have been considering using an interrupt for this, but question
> whether or not it will save any thing.
> Whether or not I use an interrupt, I still have to run the program
> using:
> "python my_interrupt.py"  This program will be running all the time. My
> program called new_monitor.py needs to be invoked the same way.  Do I
> save anything using interrupt vs. the while loop code?
>
It depends on the length of the scan cycle, how many conditions must be
checked and how long a signal persists in comparison with the time for a
loop to complete.

Your system will work to monitor your door because its unlikely that the
door will be opened and and closed within a second. On the other hand, if
you used the same 1 second loop to check for somebody pressing a
microswitch or a hand passing through a light beam, then its likely that
many events would be missed. The same problem can occur if the action the
event triggers takes as long as the loop  cycle  time to complete, then
you'd miss other types of events that the loop is scanning for.

Its better to use interrupts if several events are being monitored and if
any of the actions they trigger will take time to complete, but the
program structure can become quite a lot more complex. For example, if
you're monitoring several interrupt sources and the associated actions
are long compared with the maximum rate at which interrupts may occur,
then, to avoid missing any interrupts, you may need a multithreaded
program which has:

- a set of threads, each waits for a specific interrupt and, when the
  interrupt fires, the thread adds an action request to an event queue
  and then waits on the interrupt monitor for the next one to occur. If
  its not possible to wait on an interrupt then these threads would scan
  for an interrupt and, if one is not found, wait a short time before
  scanning again.

  If detection is fast and there are only a few interrupt sources then
  this could be a single loop that scans for interrupts and adds an
  associated action request to the queue for every interrupt it sees.
  At the end of the scan list it should wait a short time before
  repeating the scan.

- there is only one event queue, organised as a first-in / first-out
  (FIFO) queue so action requests are held in the same order as they
  arrive

- one or more worker threads. Each grabs the next action request off the
  event queue, carries out the requested action and discards the request.
  Then it checks to see if the queue is empty. It there is another action
  request waiting it handles it. If the queue is empty the thread starts
  a timer and suspends itself.

- the timer. When this times out, it adds a wakeup action request to the
  event queue and stops.

- A wakeup action request does nothing: the worker thread grabs it off
  the queue, discards it and looks for the next request.

> Let me know what you think.  I do plan do check the resources used of my
> inline coded program and then create the same funtionality using the
> interrupt method.
>
As I said above: in the simple case a simple scan loop may do the job,
but if there are a lot of things to scan for or dealing with an event
takes a long time, then a more complex interrupt handling system may be
needed.

A 'short wait' might be in the range of 10 - 100 mS for starters and
should be tweaked to suit the tasks the program is being asked to do,
i.e. shortened if the program is slow to respond to events and lengthened
if the program is just spinning and burning mpu cycles while its waiting
for something to do.


--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05