You have to use the technique shown in the link you posted in reply #2.

You use the interrupt handler to set a 'flag' and you test the flag (and write to the LCD when required) outside of the interrupt handler.

Don

Hello Don,

yes thats the dirty solution. But why to use an interrupt to set an flag which i verify each run in the loop, i can also verify the state of the digital pin in the loop. In my opinion it should be possible to write to the LCD within the interrupt and it is an advantage of an interrupt to resolve the need of verify the pin state in the "main loop".Another question is it possible to write to an "normal connected" LCD within an Interrupt?

In my opinion it should be possible to write to the LCD within the interrupt ...

It is possible to write to the LCD within the interrupt, just as it is also possible to drive 75 mph in a 55 mph speed zone.

It is just something that you should not do since it 'interrupts' everything else that the processor is trying to do, such as keeping track of time. When you interrupt the processor just long enough to set a flag it does not upset the timekeeping mechanism. When you write to the LCD outside of the interrupt routine, a process that takes an enormous amount of time in the microprocessor world, the timekeeping mechanism can still function properly.

In my opinion it should be possible to write to the LCD within the interrupt ...

It is possible to write to the LCD within the interrupt, just as it is also possible to drive 75 mph in a 55 mph speed zone.

It is just something that you should not do since it 'interrupts' everything else that the processor is trying to do, such as keeping track of time. When you interrupt the processor just long enough to set a flag it does not upset the timekeeping mechanism. When you write to the LCD outside of the interrupt routine, a process that takes an enormous amount of time in the microprocessor world, the timekeeping mechanism can still function properly.

Don

Hello Don,

ok that makes sense to me. So in my opinion setting a flag is a sulotion for my problem.

The advice of doing very little or as little as possible in an ISR is generally good advice but it is recommending a solution based on anassumed set of circumstances and limitations.

Doing time consuming things from an Interrupt function is definitely possibleand there are situations where it makes sense and is useful.

That said there are some reasons for the "do as little as possible" advice particularlyin an AVR Arduino environment since time consuming processing simplycan't be done with the same ease as doing it from non interrupt level.

There are 2 main reasons to keep an ISR short and sweet.- Blocking/delaying other interrupts- Reentrancy issues.

Both of these issues can be solved and often are in other environments.Often times they can even be worked around on the AVR as well, but they are impossibleto fully solve on the AVR in a generic way particularly when using Arduino. And solving these is not somethingthat could be done from an Arduino sketch and would come with limitations.

The first issue is a quite obvious: Blocking other interruptsIt relates to the simplistic interrupt handling inside the AVR.The AVR does not have multiple interrupts levels so while the handling of simultaneous interrupt sources are prioritized,there is only a single interrupt level. What that means is that by default, once an interrupt happens,no other interrupt can happen until that ISR runs and leaves.If your ISR takes longer than the time until something else wants to interrupt like say the timer interrupt,you delay the processing of that interrupt.With Arduino, the timer interrupt wants to run every 1ms.Writing to the LCD is VERY slow. Even a single character can take more than 1msparticularly on something like i2c.A clear, or HOME takes 20+ ms.This problem can be easily solved by simply having the ISRre-enable interrupts in the ISR routine. Sounds easy enough.....However, doing that causes the 2nd problem to rear it's ugly head.

The second issue is not always as obvious: ReentrancyISR Reentrancy has 2 basic problems.- RAM/stack usage.- code/resource re-entrancy

Reentrancy problem: RAM/Stack usageYes an AVR ISR can re-enable interrupts to allow other ISRs to run, but depending on the type of interrupt, its frequency and the duration of the ISR code that re-enables the interrupts (i.e. a long/slow ISR routine)that may not work since the that same ISR itself might be re-entered and if it occurs enough times, eventually causes a stack over flow.At a minimum it can cause things to get processed out of order.

Consider a case were an interrupt occurs every 5ms. If that ISR triggers something that writesto the LCD (which takes longer than 5ms) then the LCD processing can't complete before another interrupthappens (which interrupts the previous LCD write operation).In that case, "re-ordering" would occur, since the second ISR LCD update would happen before thefirst completed.If this continues to happen, you could end up with a stack overflow,since each ISR and call to code that writes to the LCD uses up stack space, eventually the stackis overflowed and the processor will crash.

On the other hand if you know that ISR is a slow ISR or never nests (can't occur again until the ISR leaves)then sure you can re-enable interrupts and take as long as you want inside the ISR and it wouldnot have a problem with stack overflow. (it still migh have code/resource re-entrancy issues)

Reentrancy problem: code/resource reentrancyThis is the not so obvious part of reentrancy.Most code is not written to be re-entrant. That means that the code cannotproperly handle more than a single instance running at one time.While not truly possible on a single processor like the AVR, it logically happenswhen the code is called from an ISR.Since the ISR interrupts whatever is running it can interrupt anything.Suppose a lcd.write() operation is in the middle of running (say from inside your loop() code)and then an ISR interrupts it and then the ISR processing code calls lcd.write(). From a logical point of view the second lcd.write() is now running concurrently with the first lcd.write().This has the potential to screw things up since the first lcd.write() was talkingto the LCD hardware and now some other piece of code is going talk to that samepiece of hardware, perhaps before it is ready.This is a problem all over in the Arduino code because the core code and librariesare simply not designed for re-entrance.So even if your code is capable of re-entrancy, it may call an Arduino core codefunction that is not.

Now if there is the need to write to the LCD an ISR as part of some "last resort" debuggingmechanism and you can closely control how it is done (i.e. like perhaps never call the LCD code anywherebut inside the ISR) It is definitely possible and might be useful.

At first thank you for your and detailed response This clears up some Questions.

My first Idea was to create an Interrupt to call an Settings Dialog. This were an huge time consuming operation within an Interrupt. As i´m programming a Terrarium Controller i have no "space" for time consuming Operations blocking other Operations.

So i think the solution over an Flag is good for this Problem. But now i´m a litle bit worry about my other Idea: I wanted to use Timer Interrupts to verify against a Table if something exist to switch. Like: