ESP8266 Community Forum

- Fri Jun 30, 2017 7:15 am #67761

Thanks for the quick answer but why does a Serial.print work inside the ISR?

And if I use the "flag" methode in the ISR there is no need to use the interrupt system.
If I need to check the flag in the mainloop I can check the button also in the mainloop straight away.

That is my opinion as well. An interrupt should have the ability to take action Now. Of course that action needs to be considered in the context of the whole program, including deeper structural code. And it can't take too long.

- Fri Jun 30, 2017 8:17 am #67764 But It seems I have no choice. I use the "flag" methode now and it works. Thanks a lot for the hint.

- Fri Jun 30, 2017 8:22 am #67766 A lot of it will depend on precisely what the code is doing and what else is going on. With the ESP8266/Arduino code a lot of other stuff is running besides your sketch, in the background handling things like the Wifi stack.

As I understand it, the main problem with doing too much within an ISR is that while your ISR code is running other interrupts are disabled. The other background tasks rely on interrupts and wont work properly if they don't happen when expected, so if your ISR is preventing the other interrupt ISRs from getting called then unexpected things could start going wrong - buffers overflowing, Wifi timeouts and disconnecting etc, perhaps Exception 9's and a stack dump

The MQTT client.publish call requires quite a lot of code to be executed under the covers - to make a TCP requests over Wifi and blocks waiting to get back a response. If any of that code is dependent on another ISR it wont work while your ISR has interrupts disabled. You could try re-enabling interrupts within your ISR but I imagine that could quite easily cause other issues.

With the question of why not just do everything in the main loop? I think the main reason is because the main loop only runs sometimes and will be delayed by the other background stuff so if you just check for button presses in the main loop you could miss some button presses whereas using an interrupt for the button then that is less likely.

- Fri Jun 30, 2017 9:01 am #67768

check the button also in the mainloop straight away.

In theory that wouldn't be a problem, but I noticed catching button-clicks with a hardware interrupt is much more reliable and smoother.

As a rule, interrupts should always be as quick as possible.
Have a read through this article for a more in-depth explanation.

[EDIT]
I now see there were more pages and my reply is a bit useless atm...

Assumption is the mother of all f*ckups. At least: that's what I'm assuming.