Difference between Global Interrupt Enable and Peripheral Interrupt Enable bit
- Thread starter khatus
- Start date
hi k,
A Global interrupt enables All the interrupts.
A peripheral is assigned to a particular device ie: UART , Timer , etc,
Look at this link.
http://picguides.com/beginner/interrupts.php
E
A Global interrupt enables All the interrupts.
A peripheral is assigned to a particular device ie: UART , Timer , etc,
Look at this link.
http://picguides.com/beginner/interrupts.php
E
Global: as the name suggests, commands (enables/disables) any interrupt (ALL!) no matter what. My ex used to function exactly as that.
Peripheral: each peripheral has basically, one specific interrupt assigned to it, that could be enabled or not.
You can enable/disable the peripheral/s of your choice only.
Go to the datasheet and revise the details. Look in the excerpt (18F family) where the GIE signal enters into play and where those of the peripherals. Who is the boss?
Peripheral: each peripheral has basically, one specific interrupt assigned to it, that could be enabled or not.
You can enable/disable the peripheral/s of your choice only.
Go to the datasheet and revise the details. Look in the excerpt (18F family) where the GIE signal enters into play and where those of the peripherals. Who is the boss?
Just a small clarification...
Global Interrupt does not enable all interrupts as in "any interrupt (ALL!) no matter what." While it is essential for an interrupt to function, the datasheet will say something to the effect that it enables all "unmasked" interrupts.
That is, any interrupt you want to function needs to be "unmasked" (enabled) by its own particular settings before the Global Enable will enable its function. It's worth noting that interrupt flags, at least on PIC devices, are set regardless of whether an interrupt is enabled or not.
Global Interrupt does not enable all interrupts as in "any interrupt (ALL!) no matter what." While it is essential for an interrupt to function, the datasheet will say something to the effect that it enables all "unmasked" interrupts.
That is, any interrupt you want to function needs to be "unmasked" (enabled) by its own particular settings before the Global Enable will enable its function. It's worth noting that interrupt flags, at least on PIC devices, are set regardless of whether an interrupt is enabled or not.
Last edited:
A bit of additional insight on why this is the case.
During initialization you don't want ANY interrupts to occur while the devices associated with the interrupts are being initialized. So you start the initialization process with things in the power on reset state. As you initialize things you enable the peripheral interrupt bits as each device is initialized, leaving the Global Interrupt Enable off. When all of the initialization is complete as the final step you turn the GIE bit on. Before the GIE bit is turned on, interrupts can occur, but they will not be serviced. After GIE is turned on, ALL interrupts will eventually be serviced, in the priority order determined by the algorithm implemented. No interrupts are "lost" in this process, but data "overrun" is possible if the initialization process is protracted. Interrupt service routines must be able to recover from this situation and pickup wherever they happen to wake up.
Variations on this approach can be implemented, but you really need to have a reason to do so, because doing it differently can be hard to debug.
During initialization you don't want ANY interrupts to occur while the devices associated with the interrupts are being initialized. So you start the initialization process with things in the power on reset state. As you initialize things you enable the peripheral interrupt bits as each device is initialized, leaving the Global Interrupt Enable off. When all of the initialization is complete as the final step you turn the GIE bit on. Before the GIE bit is turned on, interrupts can occur, but they will not be serviced. After GIE is turned on, ALL interrupts will eventually be serviced, in the priority order determined by the algorithm implemented. No interrupts are "lost" in this process, but data "overrun" is possible if the initialization process is protracted. Interrupt service routines must be able to recover from this situation and pickup wherever they happen to wake up.
Variations on this approach can be implemented, but you really need to have a reason to do so, because doing it differently can be hard to debug.
Described above and elsewhere you have posted the same question. Simply put, if you do not "unmask" an interrupt, it is masked. Unmasking will involve one or more additional "enable" bits. By "enable" bits I mean those that define the action as well as those that include "enable" in their name.
What specific interrupt do you want to enable? It would be simpler to tell you the settings rather than staying generic. There are differences, for example, between setting an interrupt for Timer 0 and for a change in state of an input pin.
You May Also Like
-
MCU Roundup: 3 New MCUs Push Performance at the Edge
by Aaron Carman
-
Keysight Introduces First Integrated Toolset for Quantum System Design
by Duane Benson
-
Keysight Grows Its Line of Signal Source Analyzers to Cover Up to 54 GHz
by Jake Hertz
-
Renesas Rolls Out Entry-Level MCU With ‘Best-in-Class’ Power Consumption
by Jake Hertz
