Hello Wayne,
The only difference between LPM3 and LPM4 is that the ACLK is stopped in LPM4,
so moving onto LPM3 won't solve your problem. What is the P1.1 connected to? If
you wanted to wake the system up from LPM4 when there is an interrupt on P1.1,
you could do this: (I believe that you want to sleep only if the pin is down)
void function(){
P1IES &= BIT1;
P1IFG &= BIT1;
P1IE |= BIT1;
while(1){
sleep_if_down()
//do work
}
}
__attribute__((critical)) void sleep_if_down(){
if(! P1IN && BIT1){
LPM4();
}
}
interrupt(PORT1_VECTOR) PORT1_ISR(){
//wake up from LPM4
P1IFG &= BIT1;
_BIC_SR_IRQ(LPM4_bits);
}
What this does is that it checks if the P1.1 is down, if it is, it enters LPM4.
Now, the __attribute__((critical)) part tells the compiler (I learned this in
this mailing-list) to disable interrupts while in the function. So you won't
handle the interrupt until after the comparison is made.
You don't have to setup the IE and IES all the time, just the first time,
that's why I took it out of the while, and the IFG gets cleared in the
interrupt vector, no need to do it again.
I hope this helps. Best regards,
---------------------------------------
Sergio Campamá
sergiocamp...@gmail.com
On Dec 5, 2011, at 8:40 PM, Wayne Uroda wrote:
> I have a question which isn't technically related to MSPGCC (more of a msp430
> question) but I thought one of you smart people might know.
>
> Imagine the following scenario:
>
> /* 1*/ while (1)
> /* 2*/ {
> /* 3*/ if (!port1.in.pin1)
> /* 4*/ {
> /* 5*/ // Enable interrupt (rising edge) for pin 1.1
> /* 6*/ port1.ies.pin1 = 0;
> /* 7*/ port1.ifg.pin1 = 0;
> /* 8*/ port1.ie.pin1 = 1;
> /* 9*/
> /*10*/ // Enter sleep mode, but only if the pin is
> still not high
> /*11*/ if (!port1.in.pin1)
> /*12*/ {
> /*13*/ LPM4();
> /*14*/ }
> /*15*/ }
> /*16*/
> /*17*/ // Awake
> /*18*/ // Do real work here
> /*19*/ }
>
> The ISR for port1 interrupt just wakes up the processor from LPM4 and clears
> the IFG for pin 1.1.
>
> The problem I see is that there is a small window (between the execution of
> line 11 and line 13) where pin1.1 can go high, have the ISR handled and the
> IFG cleared, and then the system can incorrectly go into LPM4 even though
> pin1.1 is high.
>
> My thoughts are that the only way around this is to avoid using LPM4 and poll
> the state of pin 1.1, which is what I have done in previous designs. As far
> as I know there is no way to atomically enter LPM4 and enable interrupts so
> that the pending pin1.1 IFG can be handled AFTER entering LPM4, thus bringing
> the system out of LPM4.
>
> Has anybody come up against this? Is using LPM3 the best/only workaround?
>
> I am using 1 family chips, MSP430F148 in particular.
>
> Thanks,
>
> - Wayne
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
