user40213: I have an Adafruit 2.8" cap touch display, which has an interrupt pin (IRQ). I tried to use this with my Arduino Nano, but encountered a problem:
When trying to get the touched point from the display during a display triggered interrupt, it would not work because the touch screen is connected via I2C and according to this post, it is not possible to call I2C functions inside an ISR on an Arduino. Therefore the IRQ pin does not make much sense to me, as I would have to poll if the screen is touched inside the main loop.
My question now is: is this a problem specific for the AtMega 328p? I am thinking about getting an ESP32 based board. Would it be possible to get the I2C data inside an ISR on this chip? Or is it just not possible at all?

user359: The better way to do it would be to set a volatile flag in the ISR and handle that in the main loop.
This relies on you making sure the main loop never blocks so the flag can be check often.
volatile bool isr_happened;

void isr(){
    isr_happened = true;
}

void loop(){
    if(isr_happened){
        //do i2c

        isr_happened = false;
    }

}


user10214: I started writing this as a comment, but the more I wrote the more I needed space to complete my thoughts, so here it is as answer.
In my opinion, reacting to a user interaction should NOT be put in ISR; consequently the best thing to do is to avoid the interrupt and poll that wire. 
IMHO interrupts need to be used in very few cases, and only when the reactivity to a trigger is needed within (tenths of) microseconds. Whenever the latency can become greater than one millisecond it is much better to avoid the interrupt and all its problems, which are (not limited to)

the need for the microcontroller to save the context
interrupting other "tasks", which can be time critical (see for instance the timing in a software serial)
interrupts can happen any time (maybe in the middle of a write to a int variable)
variables shared between an interrupt and "normal" program cannot be optimized (should always be declared volatile)
ISRs must be as short as possible
usually you can't have multiple interrupts (you become blind to other interrupts, or they get delayed until your ISR is completed)

Point 1 delays your actions uselessly.
Point 2 will be a problem when trying to debug some strange problem in your communication or acquisition or software PWM or anything based on precise timing.
Point 4 implies that shared variables will always be read from memory rather than saved in register (and this will slow down your code)
Point 5 and 6 state that you cannot use long communication routines (serial, I2C, SPI, anything) inside the ISR.
These are common to all microcontrollers generally speaking, so my advice is don't use the interrupt, at least not in this case, since reacting to a user interaction is slow (even 50-100ms will not be noticeable). Poll the wire, then when you detect it ask the controller the position.

user4143: Here is an analogy for you to help you understand why using the IRQ is a good idea.
Imagine you are at a conference. There's hundreds of you in the audience, and you are in a question and answer session with the person on the stage. Maybe their presentation has just come to the end and they're fielding questions from the audience.
Lots of people have questions, and any member of the audience can raise their hand at any time to ask a question.
Now there's three ways of the presenter handling it.
The first way is your way of using an interrupt and responding to the interrupt within the interrupt handler itself.  This is like the presenter stopping what he is saying mid sentence to answer the new question. That's just nasty, and both confusing for the presenter and the audience.
The second way is for the presenter to continue until the current question has finished being answered, then pick someone at random from the sea of hands. While the question is being answered people are getting antsy waving their hands around to get noticed, and there's no guarantee that it will be first come first served. People may then not be paying attention to what is a good answer to an important question because they are fixated on theirs.  That's just the same as you polling the interrupt line, or polling the screen directly. If the interrupt line isn't active at the time you poll it you'll miss it.
The third, and best way, is if the presenter sees a hand go up while he's answering a question, and acknowledges that person with an "Ok, I'll come to you next.". Everyone else knows that waving their hand around is pointless, so don't bother - and the next question can be asked immediately after the current question has been answered. Everyone is happy.  That's the proper way of handling a system like this - when the interrupt triggers you remember "Ok, I'll come to that interrupt signal in a moment when I'm ready". Then in your loop, when you have the time, you act on the interrupt that you remembered earlier. You get to respond at your speed to a signal that you may otherwise have missed.
So to sum up: using an interrupt to remember that something is pending and then act on that remembered state is how you should use interrupts to manage communication.

40213: <p>I have an Adafruit 2.8" cap touch display, which has an interrupt pin (IRQ). I tried to use this with my Arduino Nano, but encountered a problem:</p>

<p>When trying to get the touched point from the display during a display triggered interrupt, it would not work because the touch screen is connected via I2C and according to <a href="https://forums.adafruit.com/viewtopic.php?f=47&amp;t=66428" rel="nofollow noreferrer">this post</a>, it is not possible to call I2C functions inside an ISR on an Arduino. Therefore the IRQ pin does not make much sense to me, as I would have to poll if the screen is touched inside the main loop.</p>

<p>My question now is: is this a problem specific for the AtMega 328p? I am thinking about getting an ESP32 based board. Would it be possible to get the I2C data inside an ISR on this chip? Or is it just not possible at all?</p>
 359: <p>The better way to do it would be to set a <code>volatile</code> flag in the ISR and handle that in the main loop.</p>

<p>This relies on you making sure the main loop never blocks so the flag can be check often.</p>

<pre><code>volatile bool isr_happened;

void isr(){
    isr_happened = true;
}

void loop(){
    if(isr_happened){
        //do i2c

        isr_happened = false;
    }

}
</code></pre>
 10214: <p>I started writing this as a comment, but the more I wrote the more I needed space to complete my thoughts, so here it is as answer.</p>

<p>In my opinion, reacting to a user interaction should NOT be put in ISR; consequently the best thing to do is to avoid the interrupt and poll that wire. </p>

<p>IMHO interrupts need to be used in very few cases, and only when the reactivity to a trigger is needed within (tenths of) microseconds. Whenever the latency can become greater than one millisecond it is much better to avoid the interrupt and all its problems, which are (not limited to)</p>

<ol>
<li>the need for the microcontroller to save the context</li>
<li>interrupting other "tasks", which can be time critical (see for instance the timing in a software serial)</li>
<li>interrupts can happen any time (maybe in the middle of a write to a int variable)</li>
<li>variables shared between an interrupt and "normal" program cannot be optimized (should always be declared <code>volatile</code>)</li>
<li>ISRs must be as short as possible</li>
<li>usually you can't have multiple interrupts (you become blind to other interrupts, or they get delayed until your ISR is completed)</li>
</ol>

<p>Point 1 delays your actions uselessly.</p>

<p>Point 2 will be a problem when trying to debug some strange problem in your communication or acquisition or software PWM or anything based on precise timing.</p>

<p>Point 4 implies that shared variables will always be read from memory rather than saved in register (and this will slow down your code)</p>

<p>Point 5 and 6 state that you cannot use long communication routines (serial, I2C, SPI, anything) inside the ISR.</p>

<p>These are common to all microcontrollers generally speaking, so my advice is don't use the interrupt, at least not in this case, since reacting to a user interaction is slow (even 50-100ms will not be noticeable). Poll the wire, then when you detect it ask the controller the position.</p>
 4143: <p>Here is an analogy for you to help you understand why using the IRQ is a good idea.</p>

<p>Imagine you are at a conference. There's hundreds of you in the audience, and you are in a question and answer session with the person on the stage. Maybe their presentation has just come to the end and they're fielding questions from the audience.</p>

<p>Lots of people have questions, and any member of the audience can raise their hand at any time to ask a question.</p>

<p>Now there's three ways of the presenter handling it.</p>

<p>The first way is your way of using an interrupt and responding to the interrupt within the interrupt handler itself.  This is like the presenter stopping what he is saying mid sentence to answer the new question. That's just nasty, and both confusing for the presenter and the audience.</p>

<p>The second way is for the presenter to continue until the current question has finished being answered, then pick someone at random from the sea of hands. While the question is being answered people are getting antsy waving their hands around to get noticed, and there's no guarantee that it will be first come first served. People may then not be paying attention to what is a good answer to an important question because they are fixated on theirs.  That's just the same as you polling the interrupt line, or polling the screen directly. If the interrupt line isn't active at the time you poll it you'll miss it.</p>

<p>The third, and best way, is if the presenter sees a hand go up while he's answering a question, and acknowledges that person with an "Ok, I'll come to you next.". Everyone else knows that waving their hand around is pointless, so don't bother - and the next question can be asked immediately after the current question has been answered. Everyone is happy.  That's the proper way of handling a system like this - when the interrupt triggers you remember "Ok, I'll come to that interrupt signal in a moment when I'm ready". Then in your loop, when you have the time, you act on the interrupt that you remembered earlier. You get to respond at your speed to a signal that you may otherwise have missed.</p>

<p>So to sum up: using an interrupt to remember that something is pending and then act on that remembered state is how you should use interrupts to manage communication.</p>
