Timeline for Interrupt handling in microcontrollers and FSM example
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 11, 2015 at 8:57 | comment | added | Umberto D. | Yes! That may be a solution because in the actual design I frequently go in LPM3 (MSP430) with global interrupts enabled and I exit from LPM3, resuming the execution, as soon as an interrupt is detected. So a solution is the one you presented which I think is reported in the second part of the code: enable interrupts as soon as I start to perform the do activity of a state that needs it and disable before going to the transitions block. May another other possible solution be to disable interrupt just before leaving the "Do activity block" and re-enable sometime (when?) after? | |
| Apr 11, 2015 at 2:49 | comment | added | Adam Davis | In your example code, I would consider disabling the specific button interrupt when not needed, and enable it when needed. Doing this frequently isn't an issue of its by design. Leave global interrupts on so you can add other interrupts to the code later if needed. Alternately, just reset the flag when you go to state A and otherwise ignore it. If the button is pressed and the flag set, who cares? Ignore it until you get back to state A. | |
| Apr 10, 2015 at 21:42 | comment | added | Umberto D. | I have updated the post to better explain the situation I am working at :) | |
| Apr 10, 2015 at 19:47 | history | answered | Adam Davis | CC BY-SA 3.0 |