ESP8266 Community Forum

pvvx wrote:

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.

nanoseconds...

eriksl wrote:nanoseconds...

Yes. Strobe I / O bus about 26 MHz.
Working in sync is not difficult.
I / O pins has a different clock frequency.... ~ 75ns
SPI CLK 12.5 ns

As a result, jitter of the front I / O, and turns about 10 ns
10 ns - not step. Jitter provided synchronization with the frequency i/o.

I/O bus fifo write:

pvvx wrote:

eriksl wrote:nanoseconds...

Yes. Strobe I / O bus about 26 MHz.
Working in sync is not difficult.

What I mean is that you can't really expect NANOsecond operation in software. If only because of several things you cannot predict:

- cache behaviour
- interrupts
- compiler optimisation

Every interrupt can mess up the cache completely, for instance. If that means your code runs from flash instead of sram (cache), that will make a whole lot of difference.

eriksl wrote:What I mean is that you can't really expect NANOsecond operation in software. If only because of several things you cannot predict:

- cache behaviour
- interrupts
- compiler optimisation

Every interrupt can mess up the cache completely, for instance. If that means your code runs from flash instead of sram (cache), that will make a whole lot of difference.

NMI strobe ~38 ns (~6 CLK CPU 160 MHz)
Code IRAM section.
Synchronise fifo bus...
Output i/o pin = 10 ns jitter.
Min step ~100..200 ns. Steps only synchronise I/O bus