ESP8266 Community Forum

- Sat Sep 05, 2020 7:08 am #88681 I have some sketches which used pinMode inside an ISR to control some pins which were used bi-directionally.

These worked fine, but a change in the arduino core esp8266 in Dec 2019 broke this and now pinMode or the underlying macro GPF(p) will cause a crash when used inside an ISR.

I have worked around this by directly controlling the GPIO registers to reverse the pin direction and have raised this as an issue on the gitHub.

- Wed Sep 09, 2020 10:10 pm #88732 I am not sure where I read this but you cannot use a lot of the functions in a ISR. Blocking code is probably the most documented. I try to keep my ISR's as short as possible. I typically set a global flag and get out. Then in my main program I check the flag and process accordingly. Remember our code is not the main code for the machine, it is a function. It also has to respond to the network traffic etc. If you are use to the typical Arduino you have a lot more processing power and speed in the ESP devices. Remember timing will not be stable with this part as system interrupts are occuring in the background without regard to your code. WiFi activity is a definite time variable.

- Thu Sep 10, 2020 6:14 am #88736 I am aware of the need to keep isr short and that some functions can't be used safely in them.

However, in some cases just setting a flag does not work, particularly if one is using an isr to have servicing operational in the background and need to do things like simple i/o or time measurement. Many of my esp8266 applications do use isr (timer and input triggered) without problems.

In this instance pinMode is a low level basic function that used to work in an isr until a change was made in Dec 2019 to a macro in the esp8266 core support that meant that it was making a reference to program memory rather than the small RAM look up table it was using previously. I had an application that had been running successfully for several years but a recompile with the latest esp8266 broke it. Details were spelt out in the github issue that I raised.