ISR not in IRAM on ESP8266

[tkerby]

The ESP8266 needs all the ISRs and functions called from them to be located in IRAM to function correctly. They’ve recently introduced checking for this and when hardware pin rise interrupts are turned on in LMIC the code compiles but the ESP8266 crashes.

Could a macro or conditional block be added to locate the ISR correctly? See esp8266/Arduino#6127 for discussion.

[terrillmoore]

Sorry you're having problems. I'm not really surprised.

I have been meaning to remove interrupt support as an option -- it's not tested, and I don't believe it actually works, because there's no interlocking between ISR code and background code (see comments in the code from the original authors). So before we do this, we need a working test case. Interrupts, when supported, need to have a very brief ISR stub, followed by joining the work in the background OS scheduler. That's a pretty major change. (In fact, what's really needed is a timer interrupt that can schedule the hard real-time operations.)

If someone wants to contribute a pull request that solves the build issue, I'll be happy to review. But the current interrupt system is not worth investing much effort in, if it's not an easy fix.

[tkerby]

I think you’re right that it’s best to avoid the interrupts. I was handling some led blinking in the main loop with delays - hence the interrupts but I think reading a timer within the loop to accomplish this may be better.

It looks like the common use of interrupts with LMIC to use a single shared DIO line then poll the radio on SPI to find the source isn’t ideal as the ISR shouldn’t be handling the SPI request.