ESP8266 Community Forum

This look like you're doing a sleep (delay) in an interrupt callback or other callback. Never do that. Interrupts should return within a few cycles, other callbacks also "quickly". If you have to use os_delay_us, for more time than just a few ms, at least make sure it's not in interrupt context. Make the interrupt callback or other callback "post" a task and put the sleep in the "post" task. If you need to sleep for more than a few ms, you should use another approach anyway. Use a timer and if you need to wait still, insert a small sleep and make sure you get called again (e.g. with a post callback).

This is really other stuff than atmel or pic, where you can have the complete microprocessor to yourself!

Dropouts hardware timer using not NMI interrupt (SDK 1.3.0 WiFi Scan) (> 1.156 ms)

In a typical WiFi connection and transfer files over TCP:
CLK CPU 80 MHz -> dropouts 120..162 us
CLK CPU 160 MHz -> dropouts ~80 us
limit repeat interrupt: 5 us (CLK CPU 160 MHz).
NMI -> 4 us, jitter < 10 ns.

https://github.com/pvvx/esp8266web/blob ... _run_new.c
https://github.com/pvvx/esp8266web/blob ... -vectors.c

I think it's futile to try to reach such accuracy in software. I suggest you make some simple low-level piece of hardware that relieves the software of this part.

eriksl wrote:I think it's futile to try to reach such accuracy in software. I suggest you make some simple low-level piece of hardware that relieves the software of this part.

Limit 4us repeated NMI interrupt (full WiFi and SDK work) + jitter 10ns enough for me.