On Sun, Jul 12, 2020 at 5:08 AM Matthias Welwarsky <[email protected]> wrote:
> > If you think about using an AM3358, there's zero reason to use a GPIO for PPS > input. There are much better options, like the gptimer inputs or the eCAP > engine, which runs on a 200MHz clock and is therefore able to create much more > accurate timestamps. A much better way to go for sure. There would be just the latency of the PPS vs the capture block's clock, plus anything in the logic of that block. All the delays that happen afterward, both just in getting the interrupt to the CPU and also in handling the interrupt in software before a PPS timestamp can be generated, can be subtracted out by using the timer. How much difference does it make? I've actually got data on that, see attached graph. This is for a Cyclone V, but it's very comparable to an AM3358, other than being dual core. The uncorrected jitter histogram is similar to what using a GPIO would give. Though it uses a custom PPS driver, which I wrote to try to do a good job at timestamping the interrupt consistently. The time measured here is the difference of the PPS timestamp vs 1 second on the system clock. This means we have: Jitter in the Telit JN3 GPS PPS signal Delay for PPS hardware in CycloneV to detect an edge. I think it had about a 200 MHz clock. Jitter in the system clock for τ=1 sec All the delays getting that interrupt to the CPU over AXI, interrupting the ARM, querying the INTC, etc. that I've already gone on about for some length. Software time spent in kernel code (Interrupt handler, GIC driver, PPS driver), before we get to create a timestamp. Of course this is just the jitter in this latency. The constant part we don't actually know. And this is usually about 1.5 µs, but can be up to 100 μs. The Corrected part of the histogram is what you'd get with a capture mode timer. In this case the clock was 50 MHz for that timer. This leaves the jitter from the first three sources: the GPS, the PPS capture hardware, and the system clock. And this puts us down in the 100 ns range, with a worse case of up to about 1 µs. So that's what using a timer to capture a PPS can provide. Two orders of magnitude decrease in jitter. We can also see that if one isn't using a timer, the jitter in how long an interrupt handler takes to generate a timestamp totally dominates the jitter from the GPS, system clock, and a timer module.
_______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
