Longer it is away from servicing the WiFi stack, the more likely that memory corruption In general, the CPU must not be hogged by the user code, as the The hard timing requirements depend on the WiFi configuration andĪmount of traffic. Timing is not as tight as an ISR, but it should remain below a few milliseconds. It is not possible to execute delay() or yield() from an asynchronous callback. Than ISRs, but some restrictions still apply. Asynchronous CallbacksĪsynchronous CBs, such as for the Ticker or ESPAsync* libs, have looser restrictions It isĬonsidered best practice to set a flag within the ISR, and then from within the loop()Ĭheck and clear that flag, and execute code.
That executed code should not take longer than a very few microseconds. Or do blocking operations, or operations that disable the interrupts, e.g.: readįinally, an ISR has very high restrictions on timing for the executed code, meaning In addition, it is not possible to execute delay() or yield() from an ISR, Not only that, but the entire function treeĬalled from the ISR must also have the IRAM_ATTR declared.īe aware that every function that has this attribute reduces available memory. That means that, if you use a hardware ISR, such asĪttachInterrupt(gpio, myISR, CHANGE) for a GPIO change, the ISR must have the However, the cache currently can’t be usedĭuring hardware interrupts. Other Causes for Crashes ¶ Interrupt Service Routinesīy default, all functions are compiled into flash, which means that theĬache may kick in for that code.