[Thumbgps-devel] Raspberry PI on Piday; better yet, generate our own system tick with a PPS synced PLL

[tz]

http://elinux.org/Rpi_Low-level_peripherals

http://www.raspberrypi.org/

Probably the cheapest linux embedded device, though it is a full GUI -
hook up your HDMI TV, a keyboard and mouse..0.  It doesn't have an
onboard real-time clock, but if the GPS has battery backup it might be
more than enough.  (I would swap the supercap for 3v in AA or larger
batteries for the Sparkfun SkyTraq module).

The ethernet port is USB based and has a USB connector, but also has a
console port and GPIOs which can generate interrupts.  It might be
possible to configure the other pins to provide a CTS interrupt input
but I don't see one based on the initial datasheet v.s. pins.

I don't think it does Power-over-ethernet, but if it did it could
become a box you could put outside.

A few thoughts:  1. It wouldn't route as such so we could throw away
lots of the Linux housekeeping daemons to reduce jitter.  2. It could
become a fairly precise NTP server if we pushed the software, e.g.
grabbing time in the kernel interrupt.  3. It might be a hybrid of my
"pingbot" model - if it is only responding to time requests it could
do so efficiently, both NTP and proprietary bufferbloat UDP/IGMP
packets.

There appears to be no direct way to have the timer tick (or other
output compare) interrupt from the system clock set a GPIO pin.  If it
could, then a simple microcontroller could measure the error between
the tick and the PPS edge and provide direct feedback with ZERO jitter
error.  There might be internal kernel latencies to use the info, but
we could put the tick interrupt right at the PPS edge if we could see
it.  A second-best woudl be if the tick interrupt is highest priority
and interrupts other interrupts so would have a very low latency so it
could toggle the GPIO pin.  It would be easy to see it working (or
not) on an oscilloscope.

One of the Atmel chips with USB has two input captures  (one of
sparkfun's new Pro arduinos, but Aargh, it only has one input capture
going out to a connection).

One hardware hiccup when we get very precise - both the existing
system timer tick and the PPS are both interrupts, so unless there is
a dual core, one will block the other.

Better yet, we can move the system tick itself off to a GPIO pin
causing an interrupt, and use a PLL frequency multiplier that syncs
exactly to 100x (or 1000x) the PPS.  The PPS could be a second
interrupt if there was no other easy way to indicate the UTC boundary
from the other pulses.  The GPIO interrupt can sample the internal
clock and do what it needs for the sub-tick timing.  I don't know
which other peripherals, but maybe they could read the sub-tick or
even the "time of day in microseconds" from our system over I2C or
SPI.

This could be a fairly simple circuit (worries about noise, drift...),
or there's a chip...

http://www.analog.com/en/clock-and-timing/clock-generation-and-distribution/ad9548/products/product.html?ref=ASC-PR-142
http://www.analog.com/static/imported-files/application_notes/AN-1002.pdf