Searching \ for '[PIC]:call termination stack' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'call termination stack'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:call termination stack'
2001\10\08@090219 by brah

flavicon
face
Howard Simpson wrote:
>
> > What happens to the return address on the stack if a call is terminated
> > before the return is reached?
Olin wrote:
{Quote hidden}

Howard wrote:
> > E.g. an interrupt could branch away at four, instead of the code shown,
> > and not be required to come back to the line after four with an retfie.

Olin Wrote:
{Quote hidden}

Howard replies:
OK, I understand the stack being overwritten.
I mignt not have been too clear with the above piece about the interrupt
in my desire to be brief.
What I am trying to do is to limit the time that a part of the program
will run. This part loops around testing input port bits for a desired
state.  I don't want those loops to run forever.
e.g.
;---------------
;interrupt vector
;an interrupt is generated when a long timer rolls over to zero
;usual disable interrupt and reset flag here.
       goto    five
;---------------
       enable interrupt
one     call    three
       goto    exit
       ;I don't want the next part to run forever looking for a set
       ;which may not arrive at portb,0 or portb,1
three   btfss   portb,0
       goto    three

;do instructions here based on the set at portb,0, say 20 lines of code

four    btfss   portb,1
       goto    four

;do instructions here based on the set at portb,1, say 20 lines of code

       disable interrupt and stop timer
       return  ;(from call three) - all OK, program has run sucessfully

five                    ;do something to fix the timeout
                       ;which generated the interrupt
       goto    one     ;and try again

exit                    ;disable interrupt
                       ;go on to other things
;---------------
There are other calls (not shown) within the interrupt time period, but
if
all runs as planned, the calls and instructions will all complete within
the time period of the interrupt timer, and it will be disabled.
However, if it doesn't, I want it to exit anywhere between

This has obvious problems!!
1       There's no retfie
2       The return address on the stack is corrupted if there's an interrupt.
3       If it times out, and the interrupt is generated several (unknown)
times
       there is a real corruption of the stack.
Problems I can see:
It's difficult to detect the timeout without an interrupt.  If I was
merely to check the timer int flag, I'd have to do it several times
right through the routine, which is much longer than demonstrated here.
If I use goto instead of call, that creates a return problem, as the
routine (three) is called from several places in the entire program.
Simply, I have to terminate a routine (with several loops) that has been
called, if the routine takes a longer time than I want it to.
Regards Howard.

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\10\08@105115 by Olin Lathrop

face picon face
> Problems I can see:
> It's difficult to detect the timeout without an interrupt.  If I was
> merely to check the timer int flag, I'd have to do it several times
> right through the routine, which is much longer than demonstrated here.
> If I use goto instead of call, that creates a return problem, as the
> routine (three) is called from several places in the entire program.
> Simply, I have to terminate a routine (with several loops) that has been
> called, if the routine takes a longer time than I want it to.

You can only do this for real on an 18 family PIC.  On the other PICs, there
is no way to pop a stack location and then continue returning to previous
stack locations.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2001\10\09@061728 by brah

flavicon
face
Olin Lathrop wrote:

>
> You can only do this for real on an 18 family PIC.  On the other PICs, there
> is no way to pop a stack location and then continue returning to previous
> stack locations.
>
> ********************************************************************
Yes, it's a problem not worth pursuing, I think!
I'm trying a new approach by avoiding the "interrupt - retfie" track,
and merely testing for a timer interrupt flag at appropriate places
within the program where there can be endless loops.  I've surprised
myself that with diligent examination, these can be reduced to four or
five, which aren't big overheads on the program, which doesn't have to
operate all that fast anyway.  When the timeout occurs, (if it does) I
merely take appropriate action, then jump to a "return" which avoids the
stack problem, by ensuring there's a "return" for every "call".
Thanks to all for their reply, and I will study them for future use.
Howard.

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


2001\10\09@131544 by Dwayne Reid

flavicon
face
At 08:19 PM 10/9/01 +1000, brah wrote:
>Olin Lathrop wrote:
>
> >
> > You can only do this for real on an 18 family PIC.  On the other PICs,
> there
> > is no way to pop a stack location and then continue returning to previous
> > stack locations.
> >
> > ********************************************************************
>Yes, it's a problem not worth pursuing, I think!
>I'm trying a new approach by avoiding the "interrupt - retfie" track,
>and merely testing for a timer interrupt flag at appropriate places
>within the program where there can be endless loops.

If the only purpose of the interrupt is to set a flag when the timer wraps,
there is no need for the interrupt!  Just test the timer interrupt flag.

In other words, the timer interrupt (T0IE) is disabled and can't cause an
interrupt.  Clear T0IF during initialization, then periodically test T0IF
during execution of your code.  Even though the TMR0 interrupt itself is
disabled, the interrupt flag still works.  Be sure to clear T0IF after you
have done whatever processing needs to be done with it.

dwayne





Dwayne Reid   <.....dwaynerKILLspamspam.....planet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 17 years of Engineering Innovation (1984 - 2001)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

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


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...