[LinuxPPS] Attaching PPS to the Kernel
Dave Hart
hart at ntp.org
Fri Apr 1 10:55:26 CEST 2011
On Fri, Apr 1, 2011 at 07:49 AM, <reg at dwf.com> wrote:
>
> Well, I no longer understand how this was supposed to work.
> Yes each of the WWVB/Parse/NMEA/mx4200 drivers have calls to
> time_pps_fetch, which is the PPSAPI call to get the time of the
> PPS signal.
Notice refclock_atom.c has no calls to time_pps_fetch()? Same for
refclock_wwvb.c (despite what you said) -- like atom it solely uses
the common PPSAPI code. Until recently, NMEA did not have any
time_pps_fetch() calls for the same reason. It grew them to better
associate the PPS with the correct second than it could using solely
the shared PPSAPI code.
> But note that ATOM/Parse/NMEA/PARSE/WWVB also refer to the routine refclock_pps
> which also has a call to tme_pps_fetch.
Right, that's part of the common PPSAPI code
> and that NMEA/PARSE/WWVB contain an #include refclock_atom.h which is
> filled in by the atom driver using refclock_pps and returned to the calling
> driver.
Wrong. refclock_atom.h would be better named refclock_ppsapi.h or
common_ppsapi.h Unlike in the past, no drivers call into
refclock_atom.c code.
> Confusing.
> But Dave Mills loves his ATOM driver.
>
> One would have to step thru this code more carefully to see what is really
> going on,
> but I truly believe that these drivers want to use the ATOM driver.
I won't argue what you should believe. I believe they integrate
PPSAPI support so they can, at the operator's discretion, operate as
integrated drivers supporting a reflcock that provides a serial
timecode as well as a PPS signal.
Cheers,
Dave Hart
More information about the LinuxPPS
mailing list