----- Original Message -----
From: Olin Lathrop <olin_piclist@EMBEDINC.COM>


> >    Well, the nature of my app is that everything is scheduled, so the
main
> > routine is just loop:goto loop.
> > ...
> > I pretty much invented my own scheduling routine.
> > Couldn't find zippo on the subject @ Microchip.  Suggestions eagerly
> > accepted.
>
> I like to use a different approach.  The interrupt routine handles
anything
> that is time-critical.  The main code handles the less time critical tasks
> by running in a loop looking for any of a list of things that need
service.
> Quite often the interrupt routine handles some immediate issue, then sets
a
[....]
> For an example, see HAL_MAIN.ASPIC at http://www.embedinc.com/pic/hal.htm.

I have a different concern in the general topic.  I am writing a chip where
there may be as many as four interrupt sources and I am concerned that I
might overflow the hardware stack when I have a few nested subroutines in
the ISR and in the main program.  I am seeing an 8 level stack to be a big
potential limitation particularly if I am in a nested subroutine when an
interrupt gets called and I can see the potential of a different interrupt
happening when I'm in the middle of handling one of the other interrupt
sources.  I want to make solid code so I can't just hope that any particular
interrupt is unimportant.  So is there a way to extend the hardware PC stack
into software or should I resort to sneaky tactics to reduce nested loops?

I am almost to the point of using two chips, I was going to eventually for
scaling to larger projects but for the short term I had hoped to only use
one for the small projects.

Jeff

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