Hello,
I have not tried with Raspberry (and would not...), but in order to
avoid interrupt latencies and jitter, my approach, using a Zynq, is:
- To implement a counter in the FPGA for use as the Linux clock source,
instead of the ARM timer
- Implement harware timestamping on the PPS, and generate the interrupt
(and since I was there, I use an external clock source for the counter
like the GPSO that gives also the PPS signal, instead of the usually
crappy XO that drives the Zynq clocks)
- And then have a lot of fun convincing the kernel to use the FPGA
counter as clock source, and converting raw PPS timestamp times to wall
clock in the kernel, to be able to give a good timestamp value to ntp/chrony
I have implemented this approach both using a u-blox M8F (using the
30.72MHz signal as source for the timer clock), and using a 10MHz GPSDO.
Best regards,
Javier, EA1CRB
On 12/12/21 22:55, Poul-Henning Kamp wrote:
--------
Interrupts are no longer hardware phenomena, but bus transactions
which must lay claim to one or more busses, send a formatted message
which is received by some kind of "interrupt prioritizer" which
again, may or may not send another message on another kind of bus
to the instruction sequencer in one or more CPU cores.
Both of these message transmissions will very likely involve
clock-domain-crossings.
The good news is the per-interrupt overhead is lower, thanks to
interrupts being 'gently woven into' the instruction stream, instead
of hitting it with a sledgehammer.
But the latency and jitter is literally all over the place...
Fortunately a lot of "counter-module" hardware can be used
to hardware-timestamp signals, even if the design does not
exactly support it.
For instance, the code I wrote for the Soekris 4501 uses two
hardware counters:
The first one, free-running, is the "timecounter" which the system
clock is based on.
The second one starts counting at the same rate as the first
when the PPS signal comes in.
By the time the CPU comes around to read both counters, it subtracts
the second from the first, to figure out what time the hardware
signal happened.
_______________________________________________
time-nuts mailing list -- [email protected] -- To unsubscribe send an
email to [email protected]
To unsubscribe, go to and follow the instructions there.
