Alex,
Actualy, the GIE bit is cleared when an ISR begins so, in order to allow
another interrupt to occur inside an ISR you must set GIE again. 
The prority encoding is used only to decide which interrupt must be serviced
first when multiple interrupts does happen simultaneously (within one clock
cycle, of course).
NMI is, indeed, an important call I forgot to mention before.
-Augusto


-----Original Message-----
From: msp430@msp4... [mailto:msp430@msp4...] On Behalf Of
alex@alex...
Sent: Tuesday, August 16, 2005 1:24 PM
To: msp430@msp4...
Subject: Re: [msp430] Re: Interrupt occurs in ISR A


Augusto,

GI has to be set to be able to vector to your ISR. Thus, once your ISR
started, an interrupt with a higher priority can preempt the initial ISR,
thus permitting ISR nesting without code intervention. One should dough be
careful to make sure that the interrupted ISR can tolerate the delays
introduced by the higher order Interrupt. Then, lets not forget NMI which
can preempt all ISRs. This can be a nasty problem if one does not provide a
gracious escape from Spurious NMIs.

Alex


----- Original Message ----- 
From: "augusto einsfeldt" <aee@aee@...>
To: <msp430@msp4...>
Sent: Tuesday, August 16, 2005 9:56 AM
Subject: RE: [msp430] Re: Interrupt occurs in ISR


Yes, since you have already enabled some peripheral interrupt. Each
peripheral like UART, timer, some I/O pins, etc, has an Interrupt Enable bit
that, if set prior to GIE, may allow the peripheral to generate an
interrupt. Then, when seting GIE first time you will have a first interrupt
servicing right after the set GIE instruction.

You can, in fact, set GIE inside an ISR to allow a higher priority interrupt
to take place. At least you can do that when using assembler because there
you have total control of what CPU is doing. In C I have no idea what
compilers do with registers but, I guess, all context is saved (what a waste
of time) and then you would have no problems there, too. The only problem
when enabling GIE inside an ISR would be a re-entry interrupt source (i.e.
the same interrupt source does interrupt again before it's ISR is complete)
where your stack pointer would run amok. (the "re-entry" expression
above
may be wrong in English... deep in my memory I recall "re-entrant" but
no
sure, too, if it is correct).

Anyway, you may do almost everything on ISRs when you have total control of
your system. Sometimes it is better to have a long ISR instead of setting a
flag and then testing this flag along the main loop. If in the main loop you
have very long duration math loops that are not timing tight you may not be
able to put your flag test inside that loops (in order to keep execution
time faster) and then your ISR will need to do all the job inside the ISR.
It is all matters of planning your design.

-Augusto


-----Original Message-----
From: msp430@msp4... [mailto:msp430@msp4...] On Behalf Of
agabuga@agab...
Sent: Tuesday, August 16, 2005 9:32 AM
To: msp430@msp4...
Subject: Re: [msp430] Re: Interrupt occurs in ISR


"michelqv" <michel@mich...> writes:

> When you go into an interrupt routine, the
interrupts are 
> automatically disabled, and the status register is saved on the stack. 
> If an interrupt occurs during execution of your ISR, it is not lost, 
> but it can only be executed after interrupts are enabled again. [...]

Ok, thanks for pointing this out.

Does this mean that when I set GIE to enable Interrupts the first time, that
then Interrupts might be generated which had their origin a long time before
I set GIE?

     Max




.


Yahoo! Groups Links








-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.10/73 - Release Date: 15/8/2005





.


Yahoo! Groups Links









---
avast! Antivirus: Inbound message clean.
Virus Database (VPS): 0533-0, 08/15/2005
Tested on: 8/16/2005 10:59:59 AM
avast! - copyright (c) 1988-2005 ALWIL Software. http://www.avast.com






.

 
Yahoo! Groups Links



 



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.10/73 - Release Date: 15/8/2005
 

Is this so Augusto??? Wow... TI did it again :(
Beside the extra NOPs now I need to take kare of the GIE also??? This is
silly :(
Beside, I read a bit on NMI which boils down it is not a TRUE NMI.
Once in the NMI ISR, a new NMI can not be triggered because it is MASKED !!!


OK. AUgusto ... thanks for the GIE clarification ...
Ah... rereading your message... shell I understand that priority is no more
active once an ISR is begun ???
A higher IRQ level can not interrupt a lower level ??? No Nesting of ISRs?

Alex


----- Original Message ----- 
From: "augusto einsfeldt" <aee@aee@...>
To: <msp430@msp4...>
Sent: Tuesday, August 16, 2005 1:06 PM
Subject: RE: [msp430] Re: Interrupt occurs in ISR A


> Alex,
> Actualy, the GIE bit is cleared when an ISR begins so, in order to allow
> another interrupt to occur inside an ISR you must set GIE again.
> The prority encoding is used only to decide which interrupt must be
serviced
> first when multiple interrupts does happen
simultaneously (within one
clock
> cycle, of course).
> NMI is, indeed, an important call I forgot to mention before.
> -Augusto
>
>
> -----Original Message-----
> From: msp430@msp4... [mailto:msp430@msp4...] On Behalf Of
> alex@alex...
> Sent: Tuesday, August 16, 2005 1:24 PM
> To: msp430@msp4...
> Subject: Re: [msp430] Re: Interrupt occurs in ISR A
>
>
> Augusto,
>
> GI has to be set to be able to vector to your ISR. Thus, once your ISR
> started, an interrupt with a higher priority can preempt the initial ISR,
> thus permitting ISR nesting without code intervention. One should dough be
> careful to make sure that the interrupted ISR can tolerate the delays
> introduced by the higher order Interrupt. Then, lets not forget NMI which
> can preempt all ISRs. This can be a nasty problem if one does not provide
a
> gracious escape from Spurious NMIs.
>
> Alex
>
>
> ----- Original Message ----- 
> From: "augusto einsfeldt" <aee@aee@...>
> To: <msp430@msp4...>
> Sent: Tuesday, August 16, 2005 9:56 AM
> Subject: RE: [msp430] Re: Interrupt occurs in ISR
>
>
> Yes, since you have already enabled some peripheral interrupt. Each
> peripheral like UART, timer, some I/O pins, etc, has an Interrupt Enable
bit
> that, if set prior to GIE, may allow the
peripheral to generate an
> interrupt. Then, when seting GIE first time you will have a first
interrupt
> servicing right after the set GIE instruction.
>
> You can, in fact, set GIE inside an ISR to allow a higher priority
interrupt
> to take place. At least you can do that when using
assembler because there
> you have total control of what CPU is doing. In C I have no idea what
> compilers do with registers but, I guess, all context is saved (what a
waste
> of time) and then you would have no problems
there, too. The only problem
> when enabling GIE inside an ISR would be a re-entry interrupt source (i.e.
> the same interrupt source does interrupt again before it's ISR is
complete)
> where your stack pointer would run amok. (the
"re-entry" expression above
> may be wrong in English... deep in my memory I recall
"re-entrant" but no
> sure, too, if it is correct).
>
> Anyway, you may do almost everything on ISRs when you have total control
of
> your system. Sometimes it is better to have a long
ISR instead of setting
a
> flag and then testing this flag along the main
loop. If in the main loop
you
> have very long duration math loops that are not
timing tight you may not
be
> able to put your flag test inside that loops (in
order to keep execution
> time faster) and then your ISR will need to do all the job inside the ISR.
> It is all matters of planning your design.
>
> -Augusto
>
>
> -----Original Message-----
> From: msp430@msp4... [mailto:msp430@msp4...] On Behalf Of
> agabuga@agab...
> Sent: Tuesday, August 16, 2005 9:32 AM
> To: msp430@msp4...
> Subject: Re: [msp430] Re: Interrupt occurs in ISR
>
>
> "michelqv" <michel@mich...> writes:
>
> > When you go into an interrupt routine, the interrupts are
> > automatically disabled, and the status register is saved on the stack.
> > If an interrupt occurs during execution of your ISR, it is not lost,
> > but it can only be executed after interrupts are enabled again. [...]
>
> Ok, thanks for pointing this out.
>
> Does this mean that when I set GIE to enable Interrupts the first time,
that
> then Interrupts might be generated which had their
origin a long time
before
> I set GIE?
>
>      Max
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
> -- 
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.338 / Virus Database: 267.10.10/73 - Release Date: 15/8/2005
>
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> ---
> avast! Antivirus: Inbound message clean.
> Virus Database (VPS): 0533-0, 08/15/2005
> Tested on: 8/16/2005 10:59:59 AM
> avast! - copyright (c) 1988-2005 ALWIL Software. http://www.avast.com
>
>
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
> -- 
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.338 / Virus Database: 267.10.10/73 - Release Date: 15/8/2005
>
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> ---
> avast! Antivirus: Inbound message clean.
> Virus Database (VPS): 0533-0, 08/15/2005
> Tested on: 8/16/2005 1:36:21 PM
> avast! - copyright (c) 1988-2005 ALWIL Software.
> http://www.avast.com
>
>
>

This is not so unusual. If GI was automatically enabled inside ISRs, 
then the whole context should be stored (16 registers, to start 
with), presumably on the stack, for every interrupt. Where do you 
stop then in the nesting of interrupts? Some of the MSP430 chips 
have very little RAM to spare. It sounds like you're ready to design 
your own chip.

Michel


--- In msp430@msp4..., <alex@s...> wrote:
> Is this so Augusto??? Wow... TI did it again :(
> Beside the extra NOPs now I need to take kare of the GIE also??? 
This is
> silly :(
> Beside, I read a bit on NMI which boils down it is not a TRUE NMI.
> Once in the NMI ISR, a new NMI can not be triggered because it is 
MASKED !!!
> 
> 
> OK. AUgusto ... thanks for the GIE clarification ...
> Ah... rereading your message... shell I understand that priority 
is no more
> active once an ISR is begun ???
> A higher IRQ level can not interrupt a lower level ??? No Nesting 
of ISRs?
> 
> Alex
> 
> 
> ----- Original Message ----- 
> From: "augusto einsfeldt" <aee@t...>
> To: <msp430@msp4...>
> Sent: Tuesday, August 16, 2005 1:06 PM
> Subject: RE: [msp430] Re: Interrupt occurs in ISR A
> 
> 
> > Alex,
> > Actualy, the GIE bit is cleared when an ISR begins so, in order 
to allow
> > another interrupt to occur inside an ISR you
must set GIE again.
> > The prority encoding is used only to decide which interrupt must 
be
> serviced
> > first when multiple interrupts does happen simultaneously 
(within one
> clock
> > cycle, of course).
> > NMI is, indeed, an important call I forgot to mention before.
> > -Augusto
> >
> >
> > -----Original Message-----
> > From: msp430@msp4... [mailto:msp430@msp4...] On 
Behalf Of
> > alex@s...
> > Sent: Tuesday, August 16, 2005 1:24 PM
> > To: msp430@msp4...
> > Subject: Re: [msp430] Re: Interrupt occurs in ISR A
> >
> >
> > Augusto,
> >
> > GI has to be set to be able to vector to your ISR. Thus, once 
your ISR
> > started, an interrupt with a higher priority
can preempt the 
initial ISR,
> > thus permitting ISR nesting without code
intervention. One 
should dough be
> > careful to make sure that the interrupted ISR
can tolerate the 
delays
> > introduced by the higher order Interrupt.
Then, lets not forget 
NMI which
> > can preempt all ISRs. This can be a nasty
problem if one does 
not provide
> a
> > gracious escape from Spurious NMIs.
> >
> > Alex
> >
> >
> > ----- Original Message ----- 
> > From: "augusto einsfeldt" <aee@t...>
> > To: <msp430@msp4...>
> > Sent: Tuesday, August 16, 2005 9:56 AM
> > Subject: RE: [msp430] Re: Interrupt occurs in ISR
> >
> >
> > Yes, since you have already enabled some peripheral interrupt. 
Each
> > peripheral like UART, timer, some I/O pins,
etc, has an 
Interrupt Enable
> bit
> > that, if set prior to GIE, may allow the peripheral to generate 
an
> > interrupt. Then, when seting GIE first time
you will have a first
> interrupt
> > servicing right after the set GIE instruction.
> >
> > You can, in fact, set GIE inside an ISR to allow a higher 
priority
> interrupt
> > to take place. At least you can do that when using assembler 
because there
> > you have total control of what CPU is doing.
In C I have no idea 
what
> > compilers do with registers but, I guess, all
context is saved 
(what a
> waste
> > of time) and then you would have no problems there, too. The 
only problem
> > when enabling GIE inside an ISR would be a
re-entry interrupt 
source (i.e.
> > the same interrupt source does interrupt
again before it's ISR is
> complete)
> > where your stack pointer would run amok. (the "re-entry" 
expression above
> > may be wrong in English... deep in my memory
I recall "re-
entrant" but no
> > sure, too, if it is correct).
> >
> > Anyway, you may do almost everything on ISRs when you have total 
control
> of
> > your system. Sometimes it is better to have a long ISR instead 
of setting
> a
> > flag and then testing this flag along the main loop. If in the 
main loop
> you
> > have very long duration math loops that are not timing tight you 
may not
> be
> > able to put your flag test inside that loops (in order to keep 
execution
> > time faster) and then your ISR will need to
do all the job 
inside the ISR.
> > It is all matters of planning your design.
> >
> > -Augusto
> >
> >
> > -----Original Message-----
> > From: msp430@msp4... [mailto:msp430@msp4...] On 
Behalf Of
> > agabuga@f...
> > Sent: Tuesday, August 16, 2005 9:32 AM
> > To: msp430@msp4...
> > Subject: Re: [msp430] Re: Interrupt occurs in ISR
> >
> >
> > "michelqv" <michel@q...> writes:
> >
> > > When you go into an interrupt routine, the interrupts are
> > > automatically disabled, and the status register is saved on 
the stack.
> > > If an interrupt occurs during execution
of your ISR, it is not 
lost,
> > > but it can only be executed after
interrupts are enabled 
again. [...]
> >
> > Ok, thanks for pointing this out.
> >
> > Does this mean that when I set GIE to enable Interrupts the 
first time,
> that
> > then Interrupts might be generated which had their origin a long 
time
> before
> > I set GIE?
> >
> >      Max
> >
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> > -- 
> > No virus found in this outgoing message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.338 / Virus Database: 267.10.10/73 - Release Date: 
15/8/2005
> >
> >
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---
> > avast! Antivirus: Inbound message clean.
> > Virus Database (VPS): 0533-0, 08/15/2005
> > Tested on: 8/16/2005 10:59:59 AM
> > avast! - copyright (c) 1988-2005 ALWIL Software. 
http://www.avast.com
> >
> >
> >
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> > -- 
> > No virus found in this outgoing message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.338 / Virus Database: 267.10.10/73 - Release Date: 
15/8/2005
> >
> >
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---
> > avast! Antivirus: Inbound message clean.
> > Virus Database (VPS): 0533-0, 08/15/2005
> > Tested on: 8/16/2005 1:36:21 PM
> > avast! - copyright (c) 1988-2005 ALWIL Software.
> > http://www.avast.com
> >
> >
> >

Before replying this thread I must comment that our group server seems do
be
doing its hiccups again... I am not receiving most of messages, even my own
replys. Got this from Michel, only, in the last hour or so...
Well, regarding GIE, it is reset (the whole SR is cleared with the exception
of SCG0) when starting the ISR (remind that the SR is pushed to stack before
it is cleared).
You can nest interrupt servicing enabling GIE again inside the ISR.
Actually, in mosto fo my designs it is the first thing I do on each ISR. The
priority encoder is allways working but it's result will act only when the
GIE is set.
Regarding context saving it is one reason to like assembler. I am used to
handle nested interrupts with no context saving at all: working directly
with memory address or using a set of registers unique to each handler.
I wonder if you can disable context saving in C and if you can choose
compiler solution to optimize using memory access instead of registers.
Thinking again, I wonder if C uses registers at all. It's nature is for
memory/stack handling and there may be a waste of not used registers.
Alex, regarding NMI there is one more thing: the NMI's handler must reset
the NMI's sources (OFIE, NMIE, ACCVIE) because otherwise it may nest itself
and overflow the stack since they are level triggered and not edge
triggered.
-Augusto


-----Original Message-----
From: msp430@msp4... [mailto:msp430@msp4...] On Behalf Of
michelqv
Sent: Tuesday, August 16, 2005 2:58 PM
To: msp430@msp4...
Subject: [msp430] Re: Interrupt occurs in ISR A


This is not so unusual. If GI was automatically enabled inside ISRs, 
then the whole context should be stored (16 registers, to start 
with), presumably on the stack, for every interrupt. Where do you 
stop then in the nesting of interrupts? Some of the MSP430 chips 
have very little RAM to spare. It sounds like you're ready to design 
your own chip.

Michel


--- In msp430@msp4..., <alex@s...> wrote:
> Is this so Augusto??? Wow... TI did it again :(
> Beside the extra NOPs now I need to take kare of the GIE also???
This is
> silly :(
> Beside, I read a bit on NMI which boils down it is not a TRUE NMI. 
> Once in the NMI ISR, a new NMI can not be triggered because it is
MASKED !!!
> 
> 
> OK. AUgusto ... thanks for the GIE clarification ...
> Ah... rereading your message... shell I understand that priority
is no more
> active once an ISR is begun ???
> A higher IRQ level can not interrupt a lower level ??? No Nesting
of ISRs?
> 
> Alex
> 
> 
> ----- Original Message -----
> From: "augusto einsfeldt" <aee@t...>
> To: <msp430@msp4...>
> Sent: Tuesday, August 16, 2005 1:06 PM
> Subject: RE: [msp430] Re: Interrupt occurs in ISR A
> 
> 
> > Alex,
> > Actualy, the GIE bit is cleared when an ISR begins so, in order
to allow
> > another interrupt to occur inside an ISR you
must set GIE again. The 
> > prority encoding is used only to decide which interrupt must
be
> serviced
> > first when multiple interrupts does happen simultaneously
(within one
> clock
> > cycle, of course).
> > NMI is, indeed, an important call I forgot to mention before. 
> > -Augusto
> >
> >
> > -----Original Message-----
> > From: msp430@msp4... [mailto:msp430@msp4...] On
Behalf Of
> > alex@s...
> > Sent: Tuesday, August 16, 2005 1:24 PM
> > To: msp430@msp4...
> > Subject: Re: [msp430] Re: Interrupt occurs in ISR A
> >
> >
> > Augusto,
> >
> > GI has to be set to be able to vector to your ISR. Thus, once
your ISR
> > started, an interrupt with a higher priority
can preempt the
initial ISR,
> > thus permitting ISR nesting without code
intervention. One
should dough be
> > careful to make sure that the interrupted ISR
can tolerate the
delays
> > introduced by the higher order Interrupt.
Then, lets not forget
NMI which
> > can preempt all ISRs. This can be a nasty
problem if one does
not provide
> a
> > gracious escape from Spurious NMIs.
> >
> > Alex
> >
> >
> > ----- Original Message -----
> > From: "augusto einsfeldt" <aee@t...>
> > To: <msp430@msp4...>
> > Sent: Tuesday, August 16, 2005 9:56 AM
> > Subject: RE: [msp430] Re: Interrupt occurs in ISR
> >
> >
> > Yes, since you have already enabled some peripheral interrupt.
Each
> > peripheral like UART, timer, some I/O pins,
etc, has an
Interrupt Enable
> bit
> > that, if set prior to GIE, may allow the peripheral to generate
an
> > interrupt. Then, when seting GIE first time
you will have a first
> interrupt
> > servicing right after the set GIE instruction.
> >
> > You can, in fact, set GIE inside an ISR to allow a higher
priority
> interrupt
> > to take place. At least you can do that when using assembler
because there
> > you have total control of what CPU is doing.
In C I have no idea
what
> > compilers do with registers but, I guess, all
context is saved
(what a
> waste
> > of time) and then you would have no problems there, too. The
only problem
> > when enabling GIE inside an ISR would be a
re-entry interrupt
source (i.e.
> > the same interrupt source does interrupt
again before it's ISR is
> complete)
> > where your stack pointer would run amok. (the "re-entry"
expression above
> > may be wrong in English... deep in my memory
I recall "re-
entrant" but no
> > sure, too, if it is correct).
> >
> > Anyway, you may do almost everything on ISRs when you have total
control
> of
> > your system. Sometimes it is better to have a long ISR instead
of setting
> a
> > flag and then testing this flag along the main loop. If in the
main loop
> you
> > have very long duration math loops that are not timing tight you
may not
> be
> > able to put your flag test inside that loops (in order to keep
execution
> > time faster) and then your ISR will need to
do all the job
inside the ISR.
> > It is all matters of planning your design.
> >
> > -Augusto
> >
> >
> > -----Original Message-----
> > From: msp430@msp4... [mailto:msp430@msp4...] On
Behalf Of
> > agabuga@f...
> > Sent: Tuesday, August 16, 2005 9:32 AM
> > To: msp430@msp4...
> > Subject: Re: [msp430] Re: Interrupt occurs in ISR
> >
> >
> > "michelqv" <michel@q...> writes:
> >
> > > When you go into an interrupt routine, the interrupts are 
> > > automatically disabled, and the status register is saved on
the stack.
> > > If an interrupt occurs during execution
of your ISR, it is not
lost,
> > > but it can only be executed after
interrupts are enabled
again. [...]
> >
> > Ok, thanks for pointing this out.
> >
> > Does this mean that when I set GIE to enable Interrupts the
first time,
> that
> > then Interrupts might be generated which had their origin a long
time
> before
> > I set GIE?
> >
> >      Max
> >
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.338 / Virus Database: 267.10.10/73 - Release Date: 
15/8/2005
> >
> >
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---
> > avast! Antivirus: Inbound message clean.
> > Virus Database (VPS): 0533-0, 08/15/2005
> > Tested on: 8/16/2005 10:59:59 AM
> > avast! - copyright (c) 1988-2005 ALWIL Software.
http://www.avast.com
> >
> >
> >
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.338 / Virus Database: 267.10.10/73 - Release Date: 
15/8/2005
> >
> >
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---
> > avast! Antivirus: Inbound message clean.
> > Virus Database (VPS): 0533-0, 08/15/2005
> > Tested on: 8/16/2005 1:36:21 PM
> > avast! - copyright (c) 1988-2005 ALWIL Software. 
> > http://www.avast.com
> >
> >
> >






.

 
Yahoo! Groups Links



 




-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.10/73 - Release Date: 15/8/2005
 

Rachel Adamec <adamec.rachel@adam...> writes:

Thanks to all who answered to my topic. 

One last question: Where get you your information? I read the User
Guide, the Data sheet and the German book "Das gro MSP430
Praxisbuch"
and I never found any information if interrupts are lost when GIE is 0.
There always stood: "Interrupts are 'disabled' if GIE is 0"


      Max

Are they lost? I assumed the flags would get set, but no vector would be 
executed.. So in other words you can tell an ISR has been triggered by 
polling the flags even if your GIE is 0.. 

But I may be wrong.. just off the top of my head. 

-Micah 

On Tuesday 16 August 2005 6:34 pm, agabuga@agab...
wrote:
> Rachel Adamec <adamec.rachel@adam...> writes:
>
>  Thanks to all who answered to my topic.
>
>  One last question: Where get you your information? I read the User
>  Guide, the Data sheet and the German book "Das gro MSP430
Praxisbuch"
>  and I never found any information if interrupts are lost when GIE is 0.
>  There always stood: "Interrupts are 'disabled' if GIE is
0"
>
>
>   Max
>
>
>  .
>
>
>
>
>
>
> SPONSORED LINKS
> Msp430   Texas instruments   Hardware
>
>
> .

Interrupt flags are not lost when GIE=0. They just sit there, in their
simple and happy lives, waiting for GIE to be set or them to be cleared by
software. :-)
If you do not set GIE inside an ISR and any other interrupt occurs before
this ISR is finished their flags will stay set and the most priority
interrupt will be serviced first just after current ISR's RETI.
-Augusto


-----Original Message-----
From: msp430@msp4... [mailto:msp430@msp4...] On Behalf Of
Micah Stevens
Sent: Tuesday, August 16, 2005 3:48 PM
To: msp430@msp4...
Subject: Re: [msp430] Re: Interrupt occurs in ISR



Are they lost? I assumed the flags would get set, but no vector would be 
executed.. So in other words you can tell an ISR has been triggered by 
polling the flags even if your GIE is 0.. 

But I may be wrong.. just off the top of my head. 

-Micah 

On Tuesday 16 August 2005 6:34 pm, agabuga@agab...
wrote:
> Rachel Adamec <adamec.rachel@adam...> writes:
>
>  Thanks to all who answered to my topic.
>
>  One last question: Where get you your information? I read the User  
> Guide, the Data sheet and the German book "Das gro MSP430 
> Praxisbuch"  and I never found any information if interrupts are lost 
> when GIE is 0.  There always stood: "Interrupts are
'disabled' if GIE 
> is 0"
>
>
>   Max
>
>
>  .
>
>
>
>
>
>
> SPONSORED LINKS
> Msp430   Texas instruments   Hardware
>
>
> .



.

 
Yahoo! Groups Links



 




-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.10/73 - Release Date: 15/8/2005
 

>From: agabuga@agab...
>Subject: Re: [msp430] Re: Interrupt occurs in ISR

>One last question: Where get you your information?
I read the User
>Guide, the Data sheet and the German book "Das gro?e MSP430
Praxisbuch"
>and I never found any information if interrupts are lost when GIE is 0.
>There always stood: "Interrupts are 'disabled' if GIE is
0"

Oh, Max, did you ask the right question here!

One of the primary sources I?ve been using is the MSP43x1xx Family User?s Guide
(slau049e.pdf) from TI?s website.

Information is in there... somewhere ;-)

For example, Section 2.2.2 Maskable Interrupts and 2.2.3 Interrupt Processing
says:


2.2.2 Maskable Interrupts
... Each maskable
interrupt source can be disabled individually by an interrupt enable bit, or all
maskable interrupts can be disabled by the general interrupt enable (GIE) bit
in the status register (SR).

Each individual peripheral interrupt is discussed in the associated peripheral
module chapter in this manual.


2.2.3 Interrupt Processing
When an interrupt is requested from a peripheral and the peripheral interrupt
enable bit and GIE bit are set, the interrupt service routine is requested. Only
the individual enable bit must be set for (non)-maskable interrupts to be
requested.
Interrupt Acceptance
The interrupt latency is 6 cycles, starting with the acceptance of an interrupt
request, and lasting until the start of execution of the first instruction of
the
interrupt-service routine, as shown in Figure 2−7. The interrupt logic
executes
the following:
1) Any currently executing instruction is completed.
2) The PC, which points to the next instruction, is pushed onto the stack.
3) The SR is pushed onto the stack.
4) The interrupt with the highest priority is selected if multiple interrupts
occurred during the last instruction and are pending for service.
5) The interrupt request flag resets automatically on single-source flags.
Multiple source flags remain set for servicing by software.
6) The SR is cleared with the exception of SCG0, which is left unchanged.
This terminates any low-power mode. Because the GIE bit is cleared,
further interrupts are disabled.
7) The content of the interrupt vector is loaded into the PC: the program
continues with the interrupt service routine at that address.



Item #5 give the clue: ?reset automatically? or ?remain set for servicing?. You
need to understand which one you?re trying to use based on you interrupt source.

Also note #6: ?Because the GIE is cleared, further interrupts are disabled.?
This answers some of the other questions that came up.

Now, let?s look at how a peripheral describes it?s operation:

------------------------

9.2.5 P1 and P2 Interrupts

Each pin in ports P1 and P2 have interrupt capability, configured with the
PxIFG, PxIE, and PxIES registers. All P1 pins source a single interrupt vector,
and all P2 pins source a different single interrupt vector. The PxIFG register
can be tested to determine the source of a P1 or P2 interrupt.

Interrupt Flag Registers P1IFG, P2IFG

Each PxIFGx bit is the interrupt flag for its corresponding I/O pin and is set
when the selected input signal edge occurs at the pin. All PxIFGx interrupt
flags request an interrupt when their corresponding PxIE bit and the GIE bit
are set. Each PxIFG flag must be reset with software. Software can also set
each PxIFG flag, providing a way to generate a software initiated interrupt.

-----------
So, this tells you that the IFG (interrupt flag) gets set when its condition
occurs (note that the Px interrupt flags are edge sensitive), and it will stay
set until you clear it. 
-----------

Bit = 0: No interrupt is pending
Bit = 1: An interrupt is pending
Only transitions, not static levels, cause interrupts. If any PxIFGx flag
becomes
set during a Px interrupt service routine, or is set after the RETI instruction
of
a Px interrupt service routine is executed, the set PxIFGx flag generates
another interrupt. This ensures that each transition is acknowledged.

----------
So, take too long in an ISR so that an interrupt condition happens again, or
have another pin?s interrupt condition occur, and upon performing the RETI, the
interrupt service will again be requested.

Other sections have their own descriptions, but you should see from above that:

1. You need GIE set for non-NMI events to cause an interrupt.
2. An event just sets the flag (IFG), but these are gated by an interrupt enable
flag (IE)
3. The ISR may or may not have to clear the IFG, but this is written up in the
section about the unit.

Hope this helps!

Rachel Adamec
Norristown, PA
 

Augusto,

You seem to think C compiler writers must be idiots...? The compiler
obviously uses registers, and when an interrupt occurs, it will save
only the registers it uses. How could it work any other way? The
compilers know the cost of using or not using each register, and the
cost of saving it. They make a decision based on *calculated facts*
from the architecture's instruction cycle timings, unlike the decisions
made by assembly code developers, which *may* be optimal, but are often
emotional, stylised and aesthetic. Assembly code is only ever better
than a good compiler because the developer has more global context, and
is able to detect and work around the consequences of a wrong
assumption.

So please refrain from uninformed speculation about what C might or
might
not do. Try to write some C, enable full optimization, and look at the
generated code, then you might have grounds to complain. Meantime, think
on my motto: it's better to keep your mouth shut and be thought an idiot
than open it and remove all doubt :-).

Clifford Heath.

Hi Clifford. Actually there is (or was) at least one compiler out there 
that insisted on stacking every register before entering an ISR, even 
when no registers were used!

Clifford Heath wrote:

>Augusto,
>
>You seem to think C compiler writers must be idiots...? The compiler
>obviously uses registers, and when an interrupt occurs, it will save
>only the registers it uses. How could it work any other way? The
>compilers know the cost of using or not using each register, and the
>cost of saving it. They make a decision based on *calculated facts*
>from the architecture's instruction cycle timings, unlike the decisions
>made by assembly code developers, which *may* be optimal, but are often
>emotional, stylised and aesthetic.
>
You mean C programmers don't do the same? The code posted here to
the 
group says differently. It ranges from plain/open to almost qualifying 
for the obfuscated C competition. I'm pretty certain that compilers 
wouldn't always produce the same code no matter how it was written. thus 
the result you get from a compiler depends as much on your knowledge of 
the compiler as does the results an assembler programmer gets depend 
upon their knowledge of the architecture, and foreknowledge of the 
system they are designing. As you state below. I would therefore 
disagree with the ONLY EVER comment. But you probably knew I would anyway.

cheers

Al

> Assembly code is only ever better
>than a good compiler because the developer has more global context, and
>is able to detect and work around the consequences of a wrong
>assumption.
>
>So please refrain from uninformed speculation about what C might or
>might
>not do. Try to write some C, enable full optimization, and look at the
>generated code, then you might have grounds to complain. Meantime, think
>on my motto: it's better to keep your mouth shut and be thought an
idiot
>than open it and remove all doubt :-).
>
>Clifford Heath.
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>