Setting GIMSK PCIE bit to 1 vs calling sei function.

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found some code like this somewhere and was curious what the difference was between setting the GIMSK PCIE bit to 1 and calling sei function. Thanks :)

 

void setup()
{
    GIMSK = 0b00100000;    // turns on pin change interrupts
    PCMSK = 0b00010011;    // turn on interrupts on pins PB0, PB1, & PB4
    sei();                 // enables interrupts
}

 

This topic has a solution.
Last Edited: Wed. May 13, 2020 - 12:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
sei();

Is not a function but a defined macro that execute the asm instruction sei 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

sei();

Is not a function but a defined macro that execute the asm instruction sei 

Ah okay. I think I found the answer. I believe sei enables all interrupts, while the GIMSK PCIE bit enables specifically pin change interrupts, so calling sei is probably not necessary if you're just wanting pin change interrupts.

Last Edited: Tue. May 12, 2020 - 11:40 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are a number of interrupt sources, each with their own enable bit. Then there's the global interrupt enable - this is set/reset by sei/cli. So both are required to be set in order for the interrupt system to operate.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No sei enable interrupts, if not set no interrupts will be executed.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

There are a number of interrupt sources, each with their own enable bit. Then there's the global interrupt enable - this is set/reset by sei/cli. So both are required to be set in order for the interrupt system to operate.

 

Okay I see now. Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But - caveat: it's been a while since I played with deep and dirty AVR code - I seem to recall that there is a (sort of) use case for setting individual interrupts without the global interrupt being set.

 

In this case, if the interrupt event occurs, the interrupt flag will be set. A polling program - it may have tight timing requirements that can't be interrupted - can then tell after the event that an asynchronous something has occured.

 

Equally, one might disable the overall interrupt for a sensitive bit of code while leaving individual interrupts enabled: when the main interrupt is reenabled, anything that was pending will trigger interrupts in priority order.

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

barnacle wrote:
I seem to recall

I think you have the mechanism mixed up a bit.  In general the event flags (...IF generally) on an AVR8 will be set when the event occurs, regardless of the setting of the enable flag (...IE generally) or the state of the global interrupt enable bit.  So the fact that you might be polling SPI completion or ADIF is not directly related to whether you are using interrupts for pin-change or other.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quite feasibly. In which case, queueing interrupt around sensitive code remains the use case.

 

Neil