From EnneEnneWiki

Contents 1 Hacking the code 1.1 Adding a new LinuxPPS source 1.2 Modifing a reference clock to work with LinuxPPS

If you like LinuxPPS make a donation with PayPal - it's fast, free and secure!

Hacking the code

Adding a new LinuxPPS source

To register a PPS source into the kernel you should define a struct pps_source_info as follow:

static struct pps_source_info pps_ktimer_info = {
        name            : "ktimer",
        path            : "",
        mode            : PPS_CAPTUREASSERT | PPS_OFFSETASSERT | \
                          PPS_ECHOASSERT | \
                          PPS_CANWAIT | PPS_TSFMT_TSPEC,
        echo            : pps_ktimer_echo,
        owner           : THIS_MODULE,
};

and then calling the function pps_register_source() in your intialization routine:

source = pps_register_source(&pps_ktimer_info,
                 PPS_CAPTUREASSERT | PPS_OFFSETASSERT);

The pps_register_source() prototype is:

int pps_register_source(struct pps_source_info_s *info, int default_params)

where info is a pointer to a structure that describes a particular PPS source, default_params tells the system what the initial default parameters for the device should be (is obvious that these parameters must be a subset of ones defined into the struct pps_source_info which describe the capabilities of the driver).

Once you have registered a new PPS source into the system you can signal an assert event (for example in the interrupt handler routine) just using:

pps_event(source, PPS_CAPTUREASSERT, ptr);

The same function may also run the defined echo function (pps_ktimer_echo(), passing to it the ptr pointer) if the user asked for that... etc..

Please see the file drivers/pps/clients/ktimer.c for an example code.

Modifing a reference clock to work with LinuxPPS

While implementing a PPS API as RFC 2783 defines and using an embedded CPU GPIO-Pin as physical link to the signal, I encountered a deeper problem:

  At startup it needs a file descriptor as argument for the function
  time_pps_create().

This implies that the source has a /dev/... entry. This assumption is ok for the serial and parallel port, where you can do something useful besides(!) the gathering of timestamps as it is the central task for a PPS-API. But this assumption does not work for a single purpose GPIO line. In this case even basic file-related functionality (like read() and write()) makes no sense at all and should not be a precondition for the use of a PPS-API.

The problem can be simply solved if you consider that a PPS source is not always connected with a GPS data source.

So your programs should check if the GPS data source (the serial port for instance) is a PPS source too, otherwise they should provide the possibility to open another device as PPS source.

In LinuxPPS the PPS sources are simply char devices usually mapped into files /dev/pps0, /dev/pps1, etc..

In the directory refclocks you can find patches for some refclocks that already support the LinuxPPS API.

If you like LinuxPPS make a donation with PayPal - it's fast, free and secure!