Page 1 of 1

Interrupts and sdk func

Posted: Thu Oct 08, 2015 2:22 am
by SpenZerX
Hello,

is it allowed to use sdk functions (os_malloc, strcpy) in interrupts (GPIO)?
Can subroutines called from interrupt get ICACHE_FLASH_ATTR?

Or may this be the cause of random watchdog resets?

Re: Interrupts and sdk func

Posted: Thu Oct 08, 2015 3:34 am
by dkinzer
SpenZerX wrote:is it allowed to use sdk functions (os_malloc, strcpy) in interrupts (GPIO)?
In an ISR, it is not allowed to call a function, either directly or indirectly, that resides in .irom0.text. If you are unsure where a function is located, consult the .sym file (which can be generated from the .elf file by "xtensa-lx106-elf-gcc-nm -n").

Re: Interrupts and sdk func

Posted: Thu Oct 08, 2015 4:07 am
by SpenZerX
So what is the best technique to pass event Information from IRQ immediately to a processing / main task?
(Without stopping main task with polling)

Set up a poll timer (1 millisecound timer) , which can use SDK-Functions?

Re: Interrupts and sdk func

Posted: Thu Oct 08, 2015 3:35 pm
by joostn
In your user_init, register a task queue and a task handler:
system_os_task(..);

In your interrupt handler, say it's an UART RX interrupt:
store the received data in a buffer and signal the task queue by calling:
system_os_post(..);

system_os_post will cause the task handler you registered in system_os_task to be called 'very soon', but outside the interrupt context. In the task handler you do any lengthy processing. While your task handler is running, new interrupts may occur. The interrupt handler should be kept as short as possible. Even if it would be safe to call malloc, doing this in a ISR is bad practise. Instead pre-allocate the necessary buffer space in your user_init.

In a well designed system polling is never necessary.

Re: Interrupts and sdk func

Posted: Thu Oct 08, 2015 8:54 pm
by SpenZerX
system_os_post(..) was my first thought, too. Thanks.

But it is an SDK Function that may be also cached from rom. I will give it a try.

Re: Interrupts and sdk func

Posted: Thu Oct 08, 2015 11:13 pm
by dkinzer
SpenZerX wrote:But it is an SDK Function that may be also cached from rom. I will give it a try.
It isn't. And, by the way, it isn't necessary to just blindly try something. As I mentioned you can generate a .sym file and confirm with certainty whether a particular function (SDK or otherwise) is in .irom0.text. The .sym file excerpt below, from one of my applications, clearly shows that system_os_post is not in .irom0.text. Any function listed between _irom0_text_start and _irom0_text_end is cached. If a function is listed elsewhere, it isn't cached.

Code: Select all

...
40100220 T pvPortMalloc
401008f0 T system_get_time
4010090c T system_os_post
...
40211000 A _irom0_text_start
40211008 T post_init
40211034 T zb_mainTaskAddr
40211034 T zf_Main
...
4023b70c A _irom0_text_end
It should be noted, however, that a non-cached function may call a cached function. One would have to generate a .lss file and examine the code to be certain. Even then, the code for the internal ROM functions (those listed in eagle.rom.addr.v6.ld) won't be listed. It is probably a safe assumption that the internal ROM functions don't invoke irom0 functions unless a callback is involved.

Re: Interrupts and sdk func

Posted: Fri Oct 09, 2015 2:16 am
by joostn
system_os_post is safe to call from an interrupt. Otherwise it would have no purpose..

Re: Interrupts and sdk func

Posted: Mon Oct 12, 2015 1:04 am
by eriksl
Although I completely agree with the approach described by Don Kinzer, I must say that it's not per sé illegal to call another function or use code not in iram. Just be very careful what you do. The problem with calling other functions, especially in non-iram, that they often take too long to complete. Interrupt service routines should be a couple of lines at max to be safe always. Interrupt routines that take long to complete is simply asking for trouble. Golden rule: use background tasks to do the work, indeed. And that's not only on the ESP8266, that's on every platform.

Re: Interrupts and sdk func

Posted: Mon Oct 12, 2015 3:34 am
by joostn
You can mostly get away with it. But the problem is if if an interrupt occurs while a flash write is in progress, and that interrupt will call code in flash, then the ESP will crash. The SDK code will write to flash the access point settings and (presumably?) RF calibration data. You can not be sure when exactly this happens.