ESP8266 Community Forum

- Tue Aug 25, 2015 11:44 am #27015

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...

- Tue Aug 25, 2015 12:22 pm #27019

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:

Last edited by pvvx on Tue Aug 25, 2015 1:18 pm, edited 6 times in total.

- Tue Aug 25, 2015 12:28 pm #27021

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.

- Wed Aug 26, 2015 4:27 pm #27115

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