On Oct 1, 6:35=A0pm, Stefan <df...@amsat.org> wrote:
> > I'm not sure if there is a third way to handle the semantics
> > and there is nothing intrinsically better about one way or
> > the other, so I honestly don't think one is weirder.
>
> I think, it would be better, if the processor would not go into sleep
> after reti.
>
> If it keeps awake, you can simply make an endless loop to execute a new
> sleep command after reti.
>
> But if you want it to stay awake after the reti, you have to manipulate
> the stack, which could cause some trouble. I don=B4t know, if this can be
> done in 'C'. I think, you would need some inline assembler to do the
> stack manipulation.
>
> best regards
>
> Stefan

In the _old_ days You did have to have a little bit of assembler to
fiddle the stack - I still have a copy taken from a very old IAR
application note and used with version 1.2x of the compiler.  Since
then the compiler vendors have all implemented intrinsic functions
that put the processor into their low power mode or make the processor
exit the interrupt handler and go into active mode ( for recent
versions of the IAR tools it is  __low_power_mode_off_on_exit( ) ).

Ian

>
> If you imagine that your argument _is_ a fundamental one --
> that it applies to ALL situations regardless -- then you are
> wrong.  Another poster provided a sufficient example for you
> to know that much.
>
> Jon

Yes, I understand. I made a similar system a few month ago with an avr 
processor. The avr was send into sleep and with external int, it should 
awake, do something and after this, it should go to sleep again.

In my application, the behaviour of the MSP430 would be perfect too, but 
the behaviour of the avr makes no problem. Only if i would not want the 
processor go to sleep after reti, it would be a problem.

But this discussion is obsolete. It is only necessary to know, what the 
processor really does. ;-)

On Fri, 01 Oct 2010 19:35:57 +0200, Stefan <df9bi@amsat.org>
wrote:

>> I'm not sure if there is a third way to handle the semantics
>> and there is nothing intrinsically better about one way or
>> the other, so I honestly don't think one is weirder.
>
>I think, it would be better, if the processor would not go into sleep 
>after reti.
>
>If it keeps awake, you can simply make an endless loop to execute a new 
>sleep command after reti.
>
>But if you want it to stay awake after the reti, you have to manipulate 
>the stack, which could cause some trouble. I don&#4294967295;t know, if this can be 
>done in 'C'. I think, you would need some inline assembler to do the 
>stack manipulation.

When I wrote, I was talking about fundamentals when saying
"intrinsically better."  I didn't mean that there might not
be some technical argument.

If you imagine that your argument _is_ a fundamental one --
that it applies to ALL situations regardless -- then you are
wrong.  Another poster provided a sufficient example for you
to know that much.

Jon

Stefan wrote:

>> I'm not sure if there is a third way to handle the semantics
>> and there is nothing intrinsically better about one way or
>> the other, so I honestly don't think one is weirder.
> 
> I think, it would be better, if the processor would not go into sleep
> after reti.
> If it keeps awake, you can simply make an endless loop to execute a new
> sleep command after reti.

That's the behaviour I'm used to with AVRs
> 
> But if you want it to stay awake after the reti, you have to manipulate
> the stack, which could cause some trouble. I don&acute;t know, if this can be
> done in 'C'. I think, you would need some inline assembler to do the
> stack manipulation.

Conversely, the MSP430 way avoids wasting some number of nanoJoules on every 
interrupt that would be spent in coding a loop around the sleep instruction.  
Low power is one of the stated goals ...

	Mel.

> I'm not sure if there is a third way to handle the semantics
> and there is nothing intrinsically better about one way or
> the other, so I honestly don't think one is weirder.

I think, it would be better, if the processor would not go into sleep 
after reti.

If it keeps awake, you can simply make an endless loop to execute a new 
sleep command after reti.

But if you want it to stay awake after the reti, you have to manipulate 
the stack, which could cause some trouble. I don&#4294967295;t know, if this can be 
done in 'C'. I think, you would need some inline assembler to do the 
stack manipulation.




best regards

Stefan

On 09/30/2010 12:17 PM, Jon Kirwan wrote:
> On Thu, 30 Sep 2010 10:24:50 -0700, Tim Wescott
> <tim@seemywebsite.com>  wrote:
>
>> <snip>
>> I misunderstood the sleep action of the MSP430, then
>
> Without actually having used one, it's reasonable to imagine
> that way.  It's unreasonable to express an opinion about it
> without first checking when you know that you don't know the
> processor.  Except, of course, in a forum like this where no
> one can reasonably expect researched answers.  So it's
> entirely reasonable, anyway.  ;)
>
> -- yes, I'm being argumentative only because I'm in 'that
> mood' today.
>
>> (it seems weird, but functional).
>
> It's largely whether or not a cpu designer decides to cause
> the bits that control the sleep state of the processor to be
> saved and restored through the interrupting event, or not.
>
> If the bits are kept someplace that isn't saved and restored
> by some automatic process, then when the interrupt turns the
> processor back on (which it must do, if the cpu is going to
> do anything) the cpu will then have to be explicitly turned
> back off, later on, by additional code.  Which is the way I
> think you assumed it worked here.
>
> If they are pushed and popped (saved and restored), as the
> MSP430 actually handles it, then the processor can wake up
> and shut back down without additional code being involved.
>
> I'm not sure if there is a third way to handle the semantics
> and there is nothing intrinsically better about one way or
> the other, so I honestly don't think one is weirder.  There
> are two ways, both within the bounds of 'reasonable.'  Some
> go one way, some the other.  I've used both kinds and don't
> find either of much preference.  You just look it up on the
> sheet and do what they say to do.
>
> Jon
Only seems weird 'cause I hadn't run into it before -- to date anything 
that I've put to sleep has a 'sleep' instruction (or several, to give 
you more than one level of 'sleep') that exits after an interrupt.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

On Thu, 30 Sep 2010 10:24:50 -0700, Tim Wescott
<tim@seemywebsite.com> wrote:

><snip>
>I misunderstood the sleep action of the MSP430, then

Without actually having used one, it's reasonable to imagine
that way.  It's unreasonable to express an opinion about it
without first checking when you know that you don't know the
processor.  Except, of course, in a forum like this where no
one can reasonably expect researched answers.  So it's
entirely reasonable, anyway.  ;)

-- yes, I'm being argumentative only because I'm in 'that
mood' today.

>(it seems weird, but functional).

It's largely whether or not a cpu designer decides to cause
the bits that control the sleep state of the processor to be
saved and restored through the interrupting event, or not.

If the bits are kept someplace that isn't saved and restored
by some automatic process, then when the interrupt turns the
processor back on (which it must do, if the cpu is going to
do anything) the cpu will then have to be explicitly turned
back off, later on, by additional code.  Which is the way I
think you assumed it worked here.

If they are pushed and popped (saved and restored), as the
MSP430 actually handles it, then the processor can wake up
and shut back down without additional code being involved.

I'm not sure if there is a third way to handle the semantics
and there is nothing intrinsically better about one way or
the other, so I honestly don't think one is weirder.  There
are two ways, both within the bounds of 'reasonable.'  Some
go one way, some the other.  I've used both kinds and don't
find either of much preference.  You just look it up on the
sheet and do what they say to do.

Jon

On 09/30/2010 10:11 AM, Niklas Holsti wrote:
> Tim Wescott wrote:
>> On 09/30/2010 04:27 AM, jack_e wrote:
>>> Hi
>>>
>>> I am having trouble understanding RETI instruction. Being a novice at
>>> MSP430 architecture, have begun exploring by writing simple snippets.
>>> I am
>>> trying to blink a LED using a timer. I want to control the dutycycle
>>> of the
>>> flashing.
>>> My query is that after exiting the ISR on RETI, which instruction
>>> does the
>>> control flow go to. Have tried debugging via different methods but its
>>> still unclear. Here is my code. PLzz help.
>>> ;*****************************************************************************
>>>
>>> .cdecls C,LIST,"msp430x11x1.h" ; Include device header file
>>>
>>> ;*****************************************************************************
>>>
>>> ;----------------------------------------------------------------------------
>>>
>>> .text ; Progam Start
>>> ;-----------------------------------------------------------------------------
>>>
>>> RESET mov.w #300h,SP ; Initialize stackpointer
>>> StopWDT mov.w #WDTPW+WDTHOLD,&WDTCTL ; Stop WDT
>>> SetupP1 bis.b #04h,&P2DIR ; P1.0 output
>>> SetupC0 mov.w #CCIE,&CCTL0 ; CCR0 interrupt enabled
>>> mov.w #0ffffh,&CCR0 ;
>>> SetupTA mov.w #TASSEL_2+MC_2,&TACTL ; SMCLK, contmode
>>> ; bis.w #CPUOFF+GIE,SR ; CPU off, interrupts enabled
>>> nop
>>> ;-----------------------------------------------------------------------------
>>>
>>> TA0_ISR; Toggle P1.0
>>> ;-----------------------------------------------------------------------------
>>>
>>> xor.b #04h,&P2OUT ; Toggle P1.0
>>> add.w #10,&CCR0 ; Add Offset to CCR0
>>> reti
>>> ;-----------------------------------------------------------------------------
>>>
>>> ; Interrupt Vectors
>>> ;-----------------------------------------------------------------------------
>>>
>>> .sect ".reset" ; MSP430 RESET Vector
>>> .short RESET ;
>>> .sect ".int09"
>>> .short TA0_ISR
>>> .end
>>>
>
> [ snip ]
>
>> If I'm reading your code correctly, you do some set up, then you put
>> the processor to sleep. When your interrupt happens the processor will
>> be at the "bis.w" instruction,
>
> It is my understanding that the "bis.w" causes the MSP430 to enter the
> "LPM0" low-power mode, in which the program does not run (SR.CPUOFF is
> set). The PC is left pointing at the next instruction, the "nop". The
> "nop" is not executed, since the program does not run. If the processor
> can be said to "be" anywhere, it "is" at the "nop", since the PC points
> to the "nop".
>
> When the interrupt happens, the processor stores the PC and the SR (the
> status register) on the stack, clears the SR bits CPUOFF and GIE to let
> the program run and to disable interrupts, and enters the interrupt
> handler.
>
>> so it'll return to the nop.
>
> When the interrupt handler executes RETI, the processor pops the SR and
> PC off the stack. If the interrupt handler did not modify the stacked
> values, the processor goes back to LPM0 mode (program stopped) with the
> PC still pointing at the "nop". The "nop" is not executed. New
> interrupts can come in, and be handled, and the processor always returns
> to sleep at the "nop".
>
>> Since you're missing a loop instruction to branch back to the "bis.w"
>> instruction, your code will then erroneously fall through to the ISR
>> which will get executed, including the reti instruction.
>
> For that to happen, the interrupt handler would have to change the
> stacked SR by turning off its CPUOFF bit, for example by "bic
> #CPUOFF,0(SP)". If that were done, the RETI would restore the PC to
> point at the "nop" and restore the SR with CPUOFF cleared, meaning that
> the processor would continue to execute from the "nop" (and fall through
> to the ISR in this code).
>
> Changing the stacked SR is the normal way to make a sleeping MSP40
> program wake up after an interrupt, but of course the resumption point
> should then contain some useful code, and not be as in the OP's case.
>
I misunderstood the sleep action of the MSP430, then (it seems weird, 
but functional).

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html