Quitt, Walter wrote:

> Sure, if the interrupt servicing is SHORT.
> If long, like mine, then I want to get back to other stuff ASAP.

    I can see your point.  In fact, the method of interrupt handling can
and, probably should be, mixed.  It is reasonable to assume that
interrupts fall into approximately two categories; short, fast and
frequent ones, and long, slow and infrequent ones.

  By "mixed", I mean that your algorithm would be on entry, to check for
the fast, important interrupt first (of course this is what you always
do anyway).  If it is the source, then you service it and *exit*.

  If however, it is a slower interrupt, then you service that interrupt
and, because it is likely that *another* interrupt has occurred during
this time, you then loop back to the initial check for the fast
interrupt and either service that quickly and exit, or re-check for all
other interrupts, including the slow one just serviced.

  The general proposition being, fast interrupts exit, slow ones loop
back.

  If the slow interrupt is particularly slow, you may even wish to poll
for the fast interrupt regularly within that code, and service it as a
subroutine.  In which case you exit at the end anyway.

> Basically, I want the interrupts to not take too long and allow the
> main code to execute frequently.

  Of course, but this objective is achieved both by minimising entry
latency, and avoiding premature return-from-interrupt where a
particularly high probability exists that an interrupt is pending.
--
  Cheers,
        Paul B.