Searching \ for '[PIC]Nested Interrupts' 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/ints.htm?key=interrupt
Search entire site for: 'Nested Interrupts'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]Nested Interrupts'
2007\08\08@060213 by jtroxas

picon face
How do you do nested interrupts on a PIC?
when an interrupt happens it saves the program counter of the mainloop..
then sets the program counter to point to address 0x0004 or 0x0008 or
whereever, depends on the pic... and restores this counter when RETFIE is
executed at the end of the Interrupt service routine also enables GIE bit..
so the program counter can return executing the MainLoop

Is it posible to gain access to this saved counter.. i.e. save to a
temporary variable then restore therm in an interrupt routine.. so I can do
nested interrupts??... i.e. interrupt an interrupt..

I thought I read some entry about Nested Interrupts in the MPLAB user
Manuals.. but it did not give clear examples of how to do it exactly...
How do you do Nested Interrupts exactly?? Or is this not possible on a PIC??



2007\08\08@064047 by Jinx

face picon face
> How do you do nested interrupts on a PIC?

I don't believe it's possible on the 10 / 12 / 16 series. It is more
flexible for higher PICs though.

As you said, generally, and basically, upon an IRQ, interrupts are
disabled by the h/w setting GIE = 0, and re-enabled by the RETFIE
setting GIE = 1. Any pending interrupts won't cause program flow
to jump to an interrupt vector until GIE = 1, which is usually at the
end of the ISR

I presume you're wanting to detect one event whilst processing the
IRQ from another ? You should look at the scheme used on the
18 / 24 / 30. High priority can interrupt low priority

2007\08\08@071711 by Alan B. Pearce

face picon face
>How do you do Nested Interrupts exactly?? Or is this not possible on a
>PIC??

You cannot on a 16 series. The 18 series can have one nested interrupt, as
you can assign each peripheral to a high priority or low priority interrupt.

There should be no real need for nested interrupts for most applications.

2007\08\08@074102 by jtroxas

picon face
I just Found out from the datasheet "Stack Pointer" that Program Counter is
saved/Pushed on the PIC's Hardware Stack and poped when a retfie is
executed.. just like when you execute a CALL and RETLW instruction... My
Particular PIC has 32 levels of stack.. so now I dont think I need to access
it anyway to do restoring of return addresses.. The PIC will do it all for
me... i.e.

1st Interrupt interrupts Main
push next address to execute in Main to stack
Move to address 0x0008
set GIE = 1 wait for other interrupts
2nd Interrupt Interrupts 1st Interrupt
push next address to execute in 1st interrupt routine to stack
Move to address 0x0008
set GIE = 1 wait for other interrupts
No more Interrupts...************
RETFIE
pop 1st interrupts address and execute
1st Interrupt continue execution..
RETFIE
pop Main's address
Continue Main Loop execution...

although I'm not sure about this though have to try it first..
if it works all I have to do is watch out for stack overflows or the PIC
resets... and save registers in between interrups...

"Jinx" <spam_OUTjoecolquittTakeThisOuTspamclear.net.nz> wrote in message
news:02c301c7d9a7$f077b010$0100a8c0@ivp2000...
{Quote hidden}

> --

2007\08\08@081028 by Jan-Erik Soderholm

face picon face
It's mess. Context saving will be complex.
You need to know in the start of your ISR
which "interrupt level" you're on. Extra
code that will take cycles from the main
ISR code.

32-levels, are you using a PIC18?
(Why not simply tell us which PIC it is?)

Note that on the PIC18, you can not use the
shadow-regs for context switching. They saves
a (relatively) lot of cycles from short ISR's.

But the main question is, *why* do you think
that your application needs this "nested interrupt"
handling ?

Jan-Erik.

jtroxas wrote:
{Quote hidden}

>> --

2007\08\08@082608 by Jinx

face picon face

> saved/Pushed on the PIC's Hardware Stack and poped when
> a retfie is executed.. just like when you execute a CALL and
> RETLW instruction

I was going to comment on the stack but didn't know which PIC
you were using, so didn't comment. RETURN and RETFIE pop
addresses off the stack for you (what a mess it would be if they
didn't) and manipulating the stack is certainly OK to do. An ISR
is just another routine, the only difference being that the PIC itself
"calls" it. As long as you're aware of what's going on, I don't see
there being any problems. It's simply a question of management,
same as it is when s/w routines are called. You can get in a pretty
good tangle without interrupts too ! ;-)

2007\08\08@090525 by Gerhard Fiedler

picon face
jtroxas wrote:

> 1st Interrupt interrupts Main
> push next address to execute in Main to stack
> Move to address 0x0008
> set GIE = 1 wait for other interrupts

In general, normally, in almost all cases... you /never/ wait for anything
inside an interrupt handler. I'd say if your code architecture calls for
waiting for something inside one, there's something wrong with the
architecture. If you need to wait, you can just as well wait in the main
loop and spare yourself the nested interrupts. As Jan-Erik said, at the
very least context saving will be problematic. (You don't save context on
the stack!)

Gerhard

2007\08\08@104311 by Hector Martin

flavicon
face
Jinx wrote:
>> How do you do nested interrupts on a PIC?
>
> I don't believe it's possible on the 10 / 12 / 16 series.

Sure it is. Note that nothing prevents you from setting GIE again in the
middle of an interrupt. Save the interrupt context registers (whatever
registers you've used, like W_TEMP, STATUS_TEMP, etc) to a *different*
set of registers. Clear the interrupt flag for the interrupt you're
processing, and the interrupt enable as well (unless you're prepared to
deal with reentrant interrupt handlers). Enable interrupts (set GIE), do
whatever you need to do in the current interrupt (while other interrupts
continue to run), disable interrupts, and restore the second set of
registers instead, then RETFIE (which re-enables interrupts).
Alternatively, restore the second set of registers to the first, then
continue to your standard interrupt-return code, which will restore the
first set of registers to the real processor registers before RETFIE.

You can even implement a full software stack for multiple levels of
interrupt nesting, though code should probably never be complex enough
to call for this.

I've only ever done this once: on an application that was supposed to
respond to an incoming IR stream (which generated an interrupt via
RB0/INT). The carrier modulation was done by a TMR0 interrupt, which
needed to be active during the response, still in the initial interrupt.
This was a very simple case, since the TMR0 interrupt was about as
simple as they get (check a bit, if set toggle the output pin, if clear
turn off the output pin), so it wasn't too hard. I did have to account
for the lost time due to the TMR0 interrupt - this was accomplished by
using timers for bit timing, instead of the usual
instruction-cycle-based delays.

> As you said, generally, and basically, upon an IRQ, interrupts are
> disabled by the h/w setting GIE = 0, and re-enabled by the RETFIE
> setting GIE = 1. Any pending interrupts won't cause program flow
> to jump to an interrupt vector until GIE = 1, which is usually at the
> end of the ISR

Though, as I mentioned, you can re-enable GIE yourself.

--
Hector Martin (hectorspamKILLspammarcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2007\08\08@112735 by jtroxas

picon face
its PIC18F
It has to react on Both USART Full duplex and I2c  on a single PIC.. I'm not
using software USART and I2c and  no polling.... I was thinking of writing
the receive transmit code using the interrupt and fill a buffer..

I was thingking also of creating a software stack for the saving and
restoring of registers in the interrupts.. like this one I found on the
list..
www.piclist.com/techref/microchip/sstack.htm
Although I am wondering if C18 software stack would also work in an
interrupt without breaking something.. I'm thinking of doin it like this and
mabe I wont need to implement my own stack... will this work or is this a
bad idea??...
void Interrupt()
{
   //Save push to C18 stack..
   unsigned char wregsave = WREG;
   unsigned char statussave = STATUS;

   //set GIE = 1.. If another interrupt happens before setting this(it will
not interrupt coz GIE = 0 but the InteruptFlags will be set) and will be
handled below anyway...
   //Iam thinking If a 2nd interrupt source happens after above.. will just
push new WREG-STATUS atop the stack and poped out after the 2nd interrupt
ended..
   //check interrupt Flags.......... and handle them

   //restore
   STATUS = statussave;
   WREG = wregsave;
   //wregsave and statussave must pop out of stack when it goes out of
scope.. I'm just hoping that this out of scope thing also work in an
interrupt maybe somebody knows.. coz I dont really know how C18 stack
works...
}

I2c communicates to other PIC's and USART to the PC..
I have no way of telling when a signal will be received from the other PICs
and the PC side.. and they may even happen at the same time..
The PIC must either pass the signal from I2c to USART and vice versa or
Handle it on its own and reply..

"Jan-Erik Soderholm" <.....jan-erik.soderholmKILLspamspam.....telia.com> wrote in message
news:EraseME46B9B1F5.5090207spam_OUTspamTakeThisOuTtelia.com...
{Quote hidden}

2007\08\08@115344 by Alan B. Pearce

face picon face
>its PIC18F
>It has to react on Both USART Full duplex and I2c  on a single PIC.. I'm
>not using software USART and I2c and  no polling.... I was thinking of
>writing the receive transmit code using the interrupt and fill a buffer..

I have done that on a 16F without using nested interrupts. In both cases the
receive and transmit data was in FIFO ring buffers, and the interrupt did
minimal handling of the data.

2007\08\08@120458 by Jan-Erik Soderholm

face picon face
jtroxas wrote:

> its PIC18F
> It has to react on Both USART Full duplex

What baud rate ?
You usualy have *a lot* of time to "react" before the
next character comes in. If you are not running like
115 KBaud or something...

> and I2c  on a single PIC.. I'm not
> using software USART and I2c and  no polling....

> I was thinking of writing
> the receive transmit code using the interrupt and fill a buffer.

Sure, no problem, but you usualy have enough time to react
so that you can wait for any other interrupt to finish
first and *then* take care of the USART stuff. Have you
done some calculations on that ?

> I2c communicates to other PIC's...

Is the PIC we are talking about master or slave ?

> and they may even happen at the same time..

Yes, but again, that doesn't realy matter. *Usualy* you have
enough of time to react anyway. Just let the current
interrupt finish and the other will be called automaticly
as soon as you RETFIE's.

As long as you can't proof that you positively *need*
to "interrupt an interrupt", most will continue to tell
yo that you *probably* don't need to... :-)

Jan-Erik.

2007\08\08@120728 by Jan-Erik Soderholm

face picon face
jtroxas wrote:
> its PIC18F

Ah, forgott. You could at least use the *built-in*
two-level interrupt priority in the PIC18's before
going out and inventing something of your own.

But even that is very often not needed with a
clean (interrupt-) architecture. And note also
that in that case you can not use the automatic
context saving shadow registers.

Jan-Erik.

2007\08\08@123750 by Robert Rolf

picon face

Jan-Erik Soderholm wrote:
>
>>its PIC18F
>>It has to react on Both USART Full duplex
>
> What baud rate ?
> You usualy have *a lot* of time to "react" before the
> next character comes in. If you are not running like
> 115 KBaud or something...

I have no problems @ 115kbaud on a 1.8432Mhz '876.
I just check for Rxint before I exit the ISR (which services a lot of other stuff
like SPI/timers/CCP etc.), and jump back to the RXint
routine if it's set again. Saves a lot of time on the context restore/save
by skipping them if I have another interrupt pending.
I also poll my critical int's WITHIN the ISR to make sure I don't miss a character
or CCP/SPI byte. My data is bursty but the repeat polling of RxInt ensured I
never lost a byte.

> Yes, but again, that doesn't realy matter. *Usualy* you have
> enough of time to react anyway. Just let the current
> interrupt finish and the other will be called automaticly
> as soon as you RETFIE's.

As noted above, if you have a very fast interrupt, you can check if it's up
again before doing the context restore, and save a lot of time by skipping the
restore/save a pending int would cause.


> As long as you can't proof that you positively *need*
> to "interrupt an interrupt", most will continue to tell
> yo that you *probably* don't need to... :-)

Unless extremely low latency is a requirement, I have yet to see a
good reason to interrupt an interrupt. The extra context save is a time killer.

Robert

2007\08\08@130405 by Jan-Erik Soderholm

face picon face
Robert Rolf wrote:

> Saves a lot of time on the context restore/save
> by skipping them if I have another interrupt pending.
> ...
> ...
> As noted above, if you have a very fast interrupt, you can check if it's up
> again before doing the context restore, and save a lot of time by skipping the
> restore/save a pending int would cause.

Both are non-issues since the OP was runnig an PIC18
where the context save/restore takes *no* extra cycles anyway.
(*IF* *not* using two-level prio interrupts...)

Jan-Erik.

2007\08\08@140209 by jtroxas

picon face
Sorry but I did not mean to say that the pic have not enough time to
react... My first question was how to do Nested Interrupt??.. which I think
now I know how..
Now comes up the next question.. which is..

Will C18 stack work inside an interrupt as with the code in my previous Post
without breaking?? I have no Idea how to test C18 stack in nested
interrupt... Maybe I could just use an array as a software stack but if I
could use C18 stack in an interrupt might be better for me even if its not
faster.. at least its more readable code for me and wont waste extra memory
that may otherwise be assigned to the array... does anybody know..

"Jan-Erik Soderholm" <@spam@jan-erik.soderholmKILLspamspamtelia.com> wrote in message
news:KILLspam46B9E98A.9080606KILLspamspamtelia.com...
{Quote hidden}

> --

2007\08\08@140308 by John Temples

flavicon
face
On Wed, 8 Aug 2007, jtroxas wrote:

> My Particular PIC has 32 levels of stack..

There is no PIC with 32 levels of stack.  If you're referring to the
PIC18, it has 31 levels.

--
John W. Temples, III

2007\08\08@140601 by John Temples

flavicon
face
On Wed, 8 Aug 2007, Jan-Erik Soderholm wrote:

> Both are non-issues since the OP was runnig an PIC18
> where the context save/restore takes *no* extra cycles anyway.

Only if the high priority ISR doesn't use any resources that need
saving beyond WREG, STATUS, and BSR.

> (*IF* *not* using two-level prio interrupts...)

The high priority interrupt can still use the shadow registers even if
low priority interrupts are being used as well.

--
John W. Temples, III

2007\08\08@172827 by Jan-Erik Soderholm

face picon face
jtroxas wrote:

> Sorry but I did not mean to say that the pic have not enough time to
> react... My first question was how to do Nested Interrupt??..

And aprox 9 out of 10 replies said "don't do that*.

So the question still remains, why do you think that
you *have* to build a more complex interrupt arhitecture
the that aleady available ? And in particular on the PIC18
which has pretty fast interrupts anyway ?

At what baudrate is your USART running ?

I know nothing about implementing what you are asking
about in C18, but I think these questions are important
anyway.

Jan-Erik.



 which I think
{Quote hidden}

>> --

2007\08\08@181548 by Jinx

face picon face

> > I don't believe it's possible on the 10 / 12 / 16 series.
>
> Sure it is. Note that nothing prevents you from setting GIE again
> in the middle of an interrupt

Of course, you're right. My mind wandered to the two-level h/w
in the 18 and > series. All you'd need would be to set GIE at an
appropriate time, using IF...THENs in the ISR to find out which
IRQ is current

2007\08\08@215130 by Gerhard Fiedler

picon face
jtroxas wrote:

> Will C18 stack work inside an interrupt as with the code in my previous
> Post without breaking?? I have no Idea how to test C18 stack in nested
> interrupt...

Don't do this. Testing won't buy you much; review the stack code and make
sure it's interrupt-safe. If you don't know how to do this, this is
probably not something you want to undertake. (Unless it's for learning how
to do it, but then you'd probably have to bite yourself all the way through
it... :)

> Maybe I could just use an array as a software stack but if I could use
> C18 stack in an interrupt might be better for me even if its not
> faster.. at least its more readable code for me and wont waste extra
> memory that may otherwise be assigned to the array...

I haven't yet worked with C18, but the last statement is very likely wrong.
You need to provide the space for context saving for each interrupt level
you want to provide, whether in an array or on a (software) stack. So the
array wouldn't "waste" any memory; it would use the same amount that you
would have to assign to the (software) stack if you did it with the
(software) stack.

This all sounds to me as if you didn't yet have the vision of the can of
worms you're opening -- and since you haven't yet given the slightest clue
of why this might be necessary, the big question remains: are you /really/
sure that it's worth it? Unless you have a really unusual requirement, it's
probably a lot easier the "normal" way.

Gerhard

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