Hi everybody!
I noticed that when I use __BIC_SR_ISR in an interrupt handler right
after calling a function and immediately before returning from the
interrupt handler, the optimizer delays popping the function's
arguments off the stack. In this case __BIC_SR_ISR is useless since it
simply changes a value on the stack at a fixed offset, which is now in
the wrong place.
So the code below
...
if ( condition ) {
func(a, b, c);
__BIC_SR_ISR(LPM4_bits);
return;
}
might not wake the chip (depending on your optimization settings).
Is there a different, preferred way of handling this, other than
saving the address of future SR as in:
interrupt blah_blah() {
uint16_t *sr;
sr = ( uint16_t *)GET_FRAME_ADDR_F( __FUNCTION__ );
...
if ( condition ) {
func(a, b, c);
*sr &= ~LPM4_bits;
return;
}
I do need to wake up the chip conditionally and I do have to call an
outside function (I know, these things are frowned upon in interrupt
handlers but I have no choice).
Thanks.
Alex
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
