Hi,

It's possible that the approach you are taking that requires this type
of solution might be better coded a totally different way; I don't know
without being your Systems Analyst.

However,  what you are asking is easy on non-PIC systems where access to
the stack pointer is possible.  Perhaps an explanation will help you
come up with a solution that works for you.

When an interrupt occurs,  the program counter is pushed onto the
hardware stack. On some processors other registers like processor status
are also pushed.  Inside the interrupt routine,  your code will save any
additional registers that may be used within the routine.

When the interrupt routine is done,  it pops these values off the stack
and executes a return from interrupt which normally then re-enables the
interrupt code after the return instruction completes.  That avoids an
interrupt occuring during the return instruction.  Your applications
continues as if it had never been interrupted.

Inside your interrupt routine,  on a more powerful processor,  you can
save a copy of the status flags and then trash the stack back up to a
particular point by loading the stack pointer with a value saved in a
global variable.  If the stack at this point has been properly
conditioned,  the return from the interrupt routine will take you back
to a point before you called the loop code you were executing at the
time of the interrupt.  The code at the point that you end up, (you are
in effect branching to),  has to be robust enough to not expect
registers to hold certain values.  Variables used at that point are best
named volatile so that the compiler loads them from RAM again.

A GOTO from inside a nested series of subroutine calls to a place
outside of the nesting does the same sort of thing.  The GOTO label is a
location where the stack pointer and the code address is saved.  It's
why in PASCAL,  the goto's are so difficult to implement,  all that
stuff saved on the stack. Just imagine doing a goto into a nested
structure that then has to do a return to get out.  A return to where?
It's why GOTOs aren't really allowed in structured programming.  Hard to
implement and can make messy, yucky hard to follow code.

What you are asking is for a GOTO from inside a nested function (the
interrupt routine) to some outer higher level.  A high level language
that supports GOTO upwards could support this but the underlying
processor has to be able to do it too by manipulating the stack.  That's
why a PIC C can never be ANSI compatible;  you don't have access to the
stack pointer or the stack.

In your case,  you probably have to do your processing inside the
interrupt routine, perhaps enabling interrupts while inside it to handle
other priority events.  Just remember,  the stack on a PIC isn't very
big and can byte you in the butt really easily.

Hope this helps a bit,

John Dammeyer




> -----Original Message-----
> From: pic microcontroller discussion list
> [mailto:PICLIST@MITVMA.MIT.EDU] On Behalf Of Gordon Varney
> Sent: Wednesday, April 17, 2002 2:58 PM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: [PIC]:c interrupts
>
>
> Tim,
>         I use C to decrease the time spent programming. I can
> program in ASM and C, however I am a hardware engineer, and my
> programming skills are not as efficient as someone that will
> program all day.
>
> I need to use the ISR to exit out of the loop, not post pone
> it. All I am asking is, is there a way to use the ISR to
> stop the loop, in only a few instructions. Keeping the loop
> in tack is not important. I will call the loop again when I
> am ready.
>
>
> Gordon Varney
> www.iamnee.com
>
>
> > Hello!
> >
> > Am I missing something, or isn't that the whole point of an
> ISR?  To handle
> > interrupts immediately so the body of your code doesn't
> have to worry about
> > it?  Why can't your ISR handle the interrupt (or at least jump to a
> > function that can) in the first place?
> >
> > Or is there some limitation of the C compiler you're using?
> >
> > Tim Massey
> >
> > P.S.:  I'm new to PIC's.  I understand the value of C
> compilers on "normal"
> > computers, especially computers like IBM PC's, with 10
> different memory
> > models, 100 different hardware devices to manage, 1,000
> different ASM
> > instructions and 1,000,000 lines of code.  But on a PIC?
> Why do people
> > choose C over straight ASM when you're almost always
> talking about just a
> > couple of k of code and few hardware devices to worry
> about?  Or am I just
> > not sophisticated enough yet?
> > T.J.M.
> >
>
> --
> http://www.piclist.com hint: PICList Posts must start with ONE topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>
>
>
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads