Stream callback & ISR context #616
Replies: 2 comments
-
I think I figured out the answer to my question. It's basically a limitation of the ESP32. I cannot treat network callbacks as ISRs since they are long running, they'll definitely crash the ESP. Basically, I need to run a blocking However, although it seems that the ESP32 is dual Core, one of these Cores ( Maybe a quad core microcontroller / Raspberry is required? Because that would resolve the issue:
|
Beta Was this translation helpful? Give feedback.
-
I can't get what you post until you update with comment. You should know the critical concept of interrupt which not only the execution time of routine function is critical, but the stack memory required for keeping the previous state data is the most critical too. In case of nested interrupt, your stack memory will overflow, and device crashed because of wdt in ESP device. You have to prevent nested interrupts by bypassing it from the routine function. You can use core 0 for all your tasks unless WiFi related task. |
Beta Was this translation helpful? Give feedback.
-
Is it safe to attribute the stream callback function with
IRAM_ATTR
I need theupdateState()
method, which is run on an object from within the callback to be, by extension, an ISR so that I can take a mutex from another method of the same object,refreshState()
, which is run by repeatedly accessed from another task.I'm trying to prevent the
refreshState
method, which is run at high frequency, from being accessed at the same time as theupdateState
method, which takes precedence, since these methods are run on an object by 2 different tasks running on different cores. (I assume the library usesCore 0
by default for its callbacks as does the WiFi library, please correct me if I'm wrong.)Basically, my question is it safe or necessary to attribute my callback function with
IRAM_ATTR
in an attempt to make it and the functions called from it ISRs?e.g.
Beta Was this translation helpful? Give feedback.
All reactions