4 ms·

Others have already reported that the asynchronous serial port ("RS232") is a "native" uart (so I assume properly timed interrupts are available). But: For the

by cnvogel 13y ago

Others have already reported that the asynchronous serial port ("RS232") is a "native" uart (so I assume properly timed interrupts are available). But: For the serial data of a timing GPS receiver, that fact should be completely pointless if you settle to use one of the GPIO pins (of which I assume that board has several available for your use, or at least some that can be re-purposed from other chip-functions by changing the pin-muxes) for the timing critical PPS signal. See here for an example to connect the PPS to a raspberry-pi GPIO pin and use that function with ntp, I assume that the example could be transfered easily to the i.MX of the particular board mentioned in this thread. http://ntpi.openchaos.org/pps_pi/ http://ntpi.openchaos.org/pps_pi/

dfc 13y ago
Your comment has enough "I assume" in it that it is clear that we have different very different opionions of the world.
- cnvogel 13y ago
  I see that I should check my posts for repeating figures-of-speech... .But let me try a second (and last time) to persuade you of my arguments! :-) But I can assure you that it's ok to have a timing GPS connected to a USB serial port, as long as you feed the timing signal to an input that supports proper PPS timestamping. Here's a graph of a Trimble Thunderbolt PPS connected to a PC's parallel port. The serial port the device connects to is a USB dongle, but that's completely irrelevant for the PPS precision. http://vogelchr.blogspot.de/2011/10/thunderbolt-gpsdo-pps-signal.html http://vogelchr.blogspot.de/2011/10/thunderbolt-gpsdo-pps-si... (it's a pretty busy old Pentium) So, up to this point, there's no speculation about using a USB serial device, while the actual timing signal is connected elsewhere, and here's where I speculate only a little: I have no reason to assume that the generic PPS on GPIO support would be any worse than the parport- solution, because the implementation is pretty much identical (recording a timestamp in a minimal interrupt routine), especially as it's been shown to work for a conceptually similar CPU.

by cnvogel 13y ago

dfc 13y ago

Your comment has enough "I assume" in it that it is clear that we have different very different opionions of the world.

cnvogel 13y ago
I see that I should check my posts for repeating figures-of-speech... .But let me try a second (and last time) to persuade you of my arguments! :-) But I can assure you that it's ok to have a timing GPS connected to a USB serial port, as long as you feed the timing signal to an input that supports proper PPS timestamping. Here's a graph of a Trimble Thunderbolt PPS connected to a PC's parallel port. The serial port the device connects to is a USB dongle, but that's completely irrelevant for the PPS precision. http://vogelchr.blogspot.de/2011/10/thunderbolt-gpsdo-pps-signal.html http://vogelchr.blogspot.de/2011/10/thunderbolt-gpsdo-pps-si... (it's a pretty busy old Pentium) So, up to this point, there's no speculation about using a USB serial device, while the actual timing signal is connected elsewhere, and here's where I speculate only a little: I have no reason to assume that the generic PPS on GPIO support would be any worse than the parport- solution, because the implementation is pretty much identical (recording a timestamp in a minimal interrupt routine), especially as it's been shown to work for a conceptually similar CPU.