cli();/sei();... Are interrupts skipped or deferred?

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

I have an ISR that updates a multibyte variable (yes, it's declared as volatile). When I access it out of the ISR, I've discovered that it's necessary to wrap the access in a cli();...sei(); block. Sort of a "duh" moment for me. But the question now is this: will interrupts that are triggered during that time be deferred until sei(); is executed and happen immediately thereafter, or will they simply be ignored and skipped? I'd like to believe they were deferred, but it'd be nice to know for sure.

 

If it matters, the interrupt for this particular case is the timer 0 CTC compare interrupt, but I'd be interested to know if the answer is different for different interrupts. The device is a Tiny84, but, again, I'd be interested to know where the answer changes.

This topic has a solution.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

will interrupts that are triggered during that time be deferred until sei(); is executed and happen immediately thereafter

Yes.

Regards,
Steve A.

The Board helps those that help themselves.

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

Excellent. Thanks!

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

On thing to be aware of:  Each interrupt source has only a flag to indicate that there is a pending interrupt.  If a source comes along, the flag is set.  If the global interrupt flag is also set, the interrupt is serviced (which also clears the source's flag).  If the global interrupt flag is NOT set, the interrupt is not serviced until the global interrupt flag becomes set.  Until then, the source's flag remains set.  If the global interrupt remains disabled for too long, it is possible for ANOTHER event from the same source to come along.  This new event will not be queued.  All that will happen is the source's flag will be set.  Since it is ALREADY set, the effect is that the event is 'lost'.

 

The moral of the story:  keep interrupts disabled for the MINIMUM time possible.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Oh, absolutely. The code is literally:

 

static inline unsigned long getVal() {
    cli();
    unsigned long temp_val = val;
    sei();
    return temp_val;
}

The optimizer turns that into a fetch of 'val' into whatever register is required, wrapped by cli()/sei().

Last Edited: Fri. May 22, 2015 - 06:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using GCC compiler?  The gurus developed ATOMIC_BLOCK and friends.  Might be a good read...

http://www.nongnu.org/avr-libc/u...

 

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

Interesting. I tried it just now, but unfortunately, it wound up not inlining the code, while my version does. I suppose I could see if I can find the pragma or command line arg to force inlining...

 

Yeah, adding __attribute__((always_inline)) fixed that. I think I'll keep that version. I like that it restores the prior state.

Last Edited: Fri. May 22, 2015 - 07:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

be sure to use volatile in declaring a global static in an ISR

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

stevech wrote:
be sure to use volatile in declaring a global static in an ISR
nsayer wrote:
I have an ISR that updates a multibyte variable (yes, it's declared as volatile).

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]