how to safely re-enable interrupts ASAP (can ISR_NOBLOCK be aded to ISR()?)

[Petr Stehlík]

Hi all,

I'd like to combine V-USB and PinChangeInt in one project. V-USB does not tolerate basically any time with interrupts disabled thus all interrupt routines must be declared with ISR_NOBLOCK so that the interrupts get re-enabled as soon as the interrupt routine is entered. This would lead to re-entrancy problem when CPU executing the PCint() routine would be interrupted again by another interrupt on the same port and started executing the same routine, wouldn't it? Or is ATMEGA designed to not invoke another interrupt on the same port when one is being executed already? I admit I am not that familiar with the CPU and decided to ask those that know it off-hand before spending time to figure it out by myself.

Thank you,

Petr

[Michael Schwager]

You can tenable interrupts while in an interrupt routine. I have not tried it, but I believe it should work with little problem. I believe the compiler will handle the stack correctly because all the pushing of registers should be part of the interrupt routine.

See http://stackoverflow.com/questions/5111393/do-interrupts-interrupt-other-interrupts-on-arduino

--
You received this message because you are subscribed to the Google Groups "arduino-pinchangeint-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to arduino-pinchangeint...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Petr Stehlík]

Thanks for your answer. In the meantime I have implemented a minimal interrupt routine that contains just a single instruction for storing the PINB value to a ring buffer. This takes 13 cycles so it was safe to wrap in a cli()/sti() (V-USB can actually handle up to 25 cycles of disabled interrupts). The ring buffer is then analyzed in a normal (non-interrupt) code regularly.

I was too afraid of the nested interrupts. Even if local variables were handled correctly the globals ones might not. Or the stack could overflow if too many interrupts got nested. My solution should be a bit safer, even though it's still a thin ice...