ESP8266 Developer Zone

Re: Interrupts and sdk func

2015-10-12T03:34:09+08:00

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.

Statistics: Posted by joostn — Mon Oct 12, 2015 3:34 am

Re: Interrupts and sdk func

2015-10-12T01:04:27+08:00

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.

Statistics: Posted by eriksl — Mon Oct 12, 2015 1:04 am

Re: Interrupts and sdk func

2015-10-09T02:16:02+08:00

system_os_post is safe to call from an interrupt. Otherwise it would have no purpose..

Statistics: Posted by joostn — Fri Oct 09, 2015 2:16 am

Re: Interrupts and sdk func

2015-10-08T23:13:01+08:00

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:

...
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.

Statistics: Posted by dkinzer — Thu Oct 08, 2015 11:13 pm

Re: Interrupts and sdk func

2015-10-08T20:54:28+08:00

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.

Statistics: Posted by SpenZerX — Thu Oct 08, 2015 8:54 pm

Re: Interrupts and sdk func

2015-10-08T15:35:32+08:00

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.

Statistics: Posted by joostn — Thu Oct 08, 2015 3:35 pm

Re: Interrupts and sdk func

2015-10-08T04:07:35+08:00

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?

Statistics: Posted by SpenZerX — Thu Oct 08, 2015 4:07 am

Re: Interrupts and sdk func

2015-10-08T03:34:14+08:00

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").

Statistics: Posted by dkinzer — Thu Oct 08, 2015 3:34 am

Interrupts and sdk func

2015-10-08T02:22:40+08:00

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?

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