Any way to know if current code is running from ISR?

I have an ISR that shares a variable with main code. Variable is “volatile” and when accessing it via main code, I disable interrupts.

I would prefer to have a single setter for the variable rather than having multiple paths to set it, however in case I am setting it from ISR, I do want to disable interrupts, as this can cause problems when called from ISR (well, problem is not so much disabling, as in re-enabling after). Obviously I can pass in a flag to tell my setter if it is inside ISR or not, but I was wondering if there is a way to tell automatically? Or, in other words, is there a way to check if interrupts are already disabled?

Thanks,

-HH

Aren't interrupts already disabled if you're in the ISR?

gfvalvo: Aren't interrupts already disabled if you're in the ISR?

Yes, for a good reason, which is why I would like to not enable them while in ISR :-)

-HH

#include <util/atomic.h>

void set( type value )
{
  ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
  {
    // Do your thing here.
  }
}

[quote author=Coding Badly link=msg=3342757 date=1500321001]

  ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
  {
    // Do your thing here.
  }

[/quote]

Thank you. Not exactly what I asked for, but it looks like EXACTLY what I need. Thank you so much.

-HH

hichhiker: I would prefer to have a single setter for the variable rather than having multiple paths to set it, however in case I am setting it from ISR, I do want to disable interrupts,

As you have not posted the code it is a bit difficult to see the multiple paths or offer advice about solving the problem.

The code in an ISR is always going to be separate from other code - that's the whole purpose of an ISR.

...R

however in case I am setting it from ISR, I do want to disable interrupts,

Interrupts will already be disabled when in an ISR

Robin2: As you have not posted the code it is a bit difficult to see the multiple paths or offer advice about solving the problem.

The code in an ISR is always going to be separate from other code - that's the whole purpose of an ISR.

Well, since Coding Badly answered my question completely (even more completely than I asked for), it was not THAT difficult. (Thanks again, Coding Badly, BTW)

I am not sure what is the point of coming in to a thread and berating someone for not posting a sample code (especially given the code in question is a setter) AFTER the question was already answered. Do we seriously need an example of a setter?

For your education - this is a basic setter function:

type myVariable;

void setMyVariable(type value){
  myVariable = value;
}

Reason for this pattern is that you get to control how variable is stored/set in one place instead of having multiple random accesses throughout the codebase, leading to unmaintainable "spaghetti" code. Of course it is not a big deal to access variables directly in a small program, but when you reach tens of thousands of lines of code, you learn there is a reason for maintaining basic discipline in your code.

And no, ISR's purpose is not to be separate from other code, it is to service interrupt requests - its kinda in the name. Most of the ISR usage is to let things interact with your code, or let your code interact with other things, both of which are hard to do if you do not let ISRs and your code interact with each other... Now, you have to be very careful as to how you do that, which led to my question.

HTH,

UKHeliBob: Interrupts will already be disabled when in an ISR

This is already explained a few posts above. When you disable interrupts, you usually have to enable them back - it is enabling them that is problematic as if you are in an ISR, you may not want them enabled.

-HH

hichhiker: This is already explained a few posts above. When you disable interrupts, you usually have to enable them back - it is enabling them that is problematic as if you are in an ISR, you may not want them enabled.

-HH

You should expect a little befuddlement. Situations in which it is ever necessary to enable interrupts in an ISR are extremely rare.

hichhiker: For your education - this is a basic setter function:

I was not looking for an example of a setter function. I asked you to post your complete program so we could understand the problem and so that other readers can benefit.

And no, ISR's purpose is not to be separate from other code, it is to service interrupt requests - its kinda in the name.

I know the name. Feel free to show me a piece of code from an ISR that is shared with another part of the same program.

...R

aarg: You should expect a little befuddlement. Situations in which it is ever necessary to enable interrupts in an ISR are extremely rare.

Exactly why I needed/wanted to avoid the situation, which I now can :-)

@Robin2 The question was answered without any issues, everyone was happy, why do we need to start a random argument after the fact for no good reason that I can see? I got better things to do, I bet you do too :-)

-HH

hichhiker: I have an ISR that shares a variable with main code. Variable is "volatile" and when accessing it via main code, I disable interrupts.

I would prefer to have a single setter for the variable rather than having multiple paths to set it, however in case I am setting it from ISR, I do want to disable interrupts, as this can cause problems when called from ISR (well, problem is not so much disabling, as in re-enabling after). Obviously I can pass in a flag to tell my setter if it is inside ISR or not, but I was wondering if there is a way to tell automatically? Or, in other words, is there a way to check if interrupts are already disabled?

Thanks,

-HH

Normally your "setter" would just be an assignment statement. The critical section needed for the main program to write the variable is for setting/reading all the relevant volatile variables, so its not necessarily a single setter at all.

I can't think of any good reason for this. ISRs are intentionally separate from the main code. They aren't object-oriented. Trying to make them objects is trying to create problems.

I'll tell you a secret: all the processors that run object-oriented code aren't object-oriented at all.

MarkT: Normally your "setter" would just be an assignment statement. The critical section needed for the main program to write the variable is for setting/reading all the relevant volatile variables, so its not necessarily a single setter at all.

Point taken - this would also apply to any shared method or to multiple setters - depending on your needs. In my case I had a single variable and wanted to avoid having multiple setters for same variables - a bad practice. Coding Badly's suggestion does just that - allows me to safely use same block in both ISR and main code without causing problems. In addition same macro also solves potential problems if one critical section happens to include another - which is unlikely, but possible. Using traditional cli/sei pattern you can quickly run into trouble in that scenario, creating a race condition :-/

MorganS: I can't think of any good reason for this. ISRs are intentionally separate from the main code. They aren't object-oriented. Trying to make them objects is trying to create problems.

I'll tell you a secret: all the processors that run object-oriented code aren't object-oriented at all.

LOL, No idea what this has to do with OO vs non-OO, but ok, I guess people are now putting in random comments on whatever pet religious flame war they like. I can play too - "VI rules, EMACS drools!." Anybody got a Android vs IOS opinion they want to share while we are miles off-topic? ;-)

-HH

hichhiker: @Robin2 The question was answered without any issues, everyone was happy, why do we need to start a random argument after the fact for no good reason that I can see? I got better things to do, I bet you do too :-)

hichhiker: LOL, No idea what this has to do with OO vs non-OO, but ok, I guess people are now putting in random comments on whatever pet religious flame war they like. I can play too - "VI rules, EMACS drools!." Anybody got a Android vs IOS opinion they want to share while we are miles off-topic? ;-)

Occasionally we come across unfriendly new members - sad.

...R

"Doctor! It hurts when I do this!"

"Well, don't do that."