ESP8266 Community Forum

- Tue Aug 25, 2015 8:04 am #27003 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!

- Tue Aug 25, 2015 10:15 am #27006 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

- Tue Aug 25, 2015 11:15 am #27008 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.

- Tue Aug 25, 2015 11:29 am #27009

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.