Hi! I'm new to the this microcontroller and this is my first post, so be kind. Anyway...
I often find it convenient to wait for some condition by triggering a future interrupt and putting the processor to sleep, then after waking up again processing whatever the event was in the main loop with only minimal logic in the interrupt handler itself (e.g. to avoid error-prone synchronization logic with volatiles and such.)
Alas I'm having a bit of trouble figuring out a clean way of doing this on the 68HCS08 without potential race conditions. That is in the case where the interrupt triggers before the wait instruction and the wait immediately goes to sleep until the next condition arises without having processed the last one.
E.g.
int main(...) { for(;;) { process(...); set_pin_irq(); // If the pin interrupt triggers here we're in trouble _Wait; }}
On the AVR I would clear the sleep-enable bit from within the interrupt handler to avoid this case. About the best method I've been able to come up with on this MCU is to wrap the whole block with the interrupt trigger and wait instruction in a setjmp, but that's problematic on so many levels that it's not even funny.
Solved! Go to Solution.
Hi,
you can put a DisableInterrupts; macro just before the set_pin_irq(); call.
This sets the I bit in the CCR register, that masks every interrupts.
In order to reset the I bit, and thus reenabling the interrupts, you have to use the EnableInterrupts; or _Wait; or _Stop; macros.
Check the datasheets for more infos.
Bye Jack
Hi,
you can put a DisableInterrupts; macro just before the set_pin_irq(); call.
This sets the I bit in the CCR register, that masks every interrupts.
In order to reset the I bit, and thus reenabling the interrupts, you have to use the EnableInterrupts; or _Wait; or _Stop; macros.
Check the datasheets for more infos.
Bye Jack
Ah, so WAIT implicitly enables interrupts. I figured the solution had to be something embarrasingly simple.
Thank you!