Thread: Public static class pointer

Okay I check it in a book "C Programming for Microcontrollers", it says the following:
"Volatile is an implemention specific type qualifier that tells the compiler to suppress optimiation that might, in our case, screw things up if we are using pointers to memory mapped registers. We don't want the compiler to help us by using some other memory address since a register is hardwired into the machine and though addressed like memory, isn't ordinary memory.
Volatile also tells teh compiler that the so modified varible can change unexpectedly (like by an interrupt) so it needs to be checked each time it is used and not just stored somewhere like on stack."

Originally Posted by Elysia

That's not necessarily true. It is possible to cause an interrupt within an interrupt, depending in whether interrupts are disabled when processing the ISR or not. I don't know specifically for this hardware, though, but in general that is true.

Your objection to the quoted line in my post is justified. You are correct that nested interrupts can sometimes occur, but only on certain systems that use prioritized interrupts. It is, however, generally considered bad practice to rely on this behavior. In such systems, the more interrupts that are enabled, the more difficult it is to model the behavior of the program. There may be so many possible variations of actions (if multiple interrupts of different priorities occur around the same time) that it makes predictability tremendously difficult.

But if a device does not use an interrupt priority scheme, or only interrupts of the same priority occur, then an ISR must complete before another interrupt is processed. If interrupts of the same priority could interrupt the ISR, then the ISR could never be executed, as it would restart the ISR each clock cycle. The ISR must ignore interrupts (of equal or lower priority) to allow the code to clear the necessary interrupt flag(s).

Originally Posted by Matticus

Your objection to the quoted line in my post is justified. You are correct that nested interrupts can sometimes occur, but only on certain systems that use prioritized interrupts. It is, however, generally considered bad practice to rely on this behavior. In such systems, the more interrupts that are enabled, the more difficult it is to model the behavior of the program. There may be so many possible variations of actions (if multiple interrupts of different priorities occur around the same time) that it makes predictability tremendously difficult.

But if a device does not use an interrupt priority scheme, or only interrupts of the same priority occur, then an ISR must complete before another interrupt is processed. If interrupts of the same priority could interrupt the ISR, then the ISR could never be executed, as it would restart the ISR each clock cycle. The ISR must ignore interrupts (of equal or lower priority) to allow the code to clear the necessary interrupt flag(s).

In AVR ATmega family of microcontrollers which I am personally using, when interrupt occours other interrupts are disabled automatically since Interrupt enable bit is cleared in the Status register (SREG), so unless you enable that bit during your ISR, another interrupt won't occur during present ISR execution.

Out of curiosity, what device are you currently using?

I can also recommend a book if you're interested. It uses C, but teaches a language-independent concept of implementing sophisticated systems using only a single interrupt. This approach helps avoid the issues with nested interrupts that I mentioned above.

Originally Posted by Matticus

Out of curiosity, what device are you currently using?

I can also recommend a book if you're interested. It uses C, but teaches a language-independent concept of implementing sophisticated systems using only a single interrupt. This approach helps avoid the issues with nested interrupts that I mentioned above.

I am using ATmega 324p and ATmega2560.
Yes of course.

"Embedded C" by Michael Pont