Pine64-LTS overlays for uart ports fixed!

[Ian Lepore]

On Wed, 2019-07-31 at 16:17 +0100, Kaya Saman wrote:
> On 7/31/19 3:06 PM, Ian Lepore wrote:
> > On Wed, 2019-07-31 at 14:33 +0100, Kaya Saman wrote:
> > > On 7/31/19 1:42 AM, Ian Lepore wrote:
> > > > On Wed, 2019-07-31 at 00:46 +0100, Kaya Saman wrote:
> > > > > 
[...]
> > > 
> > > I am seeing this:
> > > 
> > > gpsd:PROG: PPS:/dev/gps1 Assert cycle:  999973, duration:  799977 @
> > > 1564579823.472659791
> > > gpsd:PROG: PPS:/dev/gps1 Assert rejected missing last_fixtime
> > > 
> > > 
> > > Perfect ;-)
> > > 
> > > 
> > > I think I need to add pps_mode=0x11 or 17 in dec. as the pulse is
> > > inverted.
> > > 
> > > 
> > > This setup was working previously using a Prolific Serial to USB adapter
> > > for testing purposes as of course the USB introduces high latency.
> > > 
> > 
> > Actually, not so much as you'd think.  I expected both high latency and
> > a lot of jitter when using a usb-serial for PPS, and what I found was a
> > fixed latency of less than a millisecond and jitter on the order of 60-
> > 80 microseconds.  Even trying to saturate the usb bus by doing
> > continuous or bursty IO to a disk drive didn't noticibly increase the
> > pps latency or jitter.  I was pretty surprised.
> > 
> > -- Ian
> > 
> > 
> 
> That's very interesting!
> 
> 
> My finding was that the accuracy went from the 10's of uS using a 
> standard RS232 D-Sub port on one of my x64 systems to the 100's of uS 
> range when switching to the Pine64 and using the USB->Serial adapter.
> 
> 
> Looks like the PPS signal just kicked in:
> 
> 
> gpsd:PROG: KPPS:/dev/gps1 Clear cycle:  999974, duration:  799981 @  
> 1564585351.860177245
> gpsd:PROG: PPS:/dev/gps1 Clear cycle:  999974, duration:  799981 @  
> 1564585351.860177245
> gpsd:PROG: PPS:/dev/gps1 Clear rejected this second already handled
> gpsd:PROG: KPPS:/dev/gps1 assert  1564585352.060170121, sequence: 5543, 
> clear   1564585351.860177245, sequence: 5543 - using: assert
> gpsd:PROG: KPPS:/dev/gps1 Assert cycle:  999974, duration:  199992 @  
> 1564585352.060170121
> gpsd:PROG: PPS:/dev/gps1 Assert cycle:  999974, duration:  199992 @  
> 1564585352.060170121
> gpsd:PROG: PPS:/dev/gps1 Assert rejected 1Hz trailing edge
> 
> 
> After stopping the gpsd service and restarting it's finding it difficult 
> to startup again. I attempted with dev.uart.4.pps_mode=0x21 for 'narrow' 
> pulses even though 200ms-1 shouldn't be considered 'narrow'?? I'm guessing.
> 
> 
> Once I understand a little bit more about the behavior and quirks of the 
> setup I'll probably start looking at how to enable an input switch on a 
> GPIO pin then trying to get/write a driver for lcdproc and the Newhaven 
> display. The aim is to use the retractive mechanical switch to change 
> the LCD display from clock to GPS info....
> / {
> 	pps at 0 {
> 		compatible = "pps-gpio";
> 		pinctrl-names = "default";
> 		pinctrl-0 = <&pinctrl_pps0>;
> 		gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */
> 		status = "okay";
> 	};
> };
> 
> The gpios= property will need to refer to the right bank and
> 
> Still lots of work to go but it's definitely a really fun project :-)
> 
> 
> Regards,
> 
> 
> Kaya

I've never used gpsd and don't know how to interpret its output. 
Narrow-pulse mode is for pulses down in the few-microseconds range
(professional timekeeping equipment often has very short pps pulses, in
the 1-100us range).

I've always been uneasy with the idea of using CTS for a pps signal,
since the uart hardware itself may want to use that line.  I wonder if
it would help to use the .lock device to force off rtscts flow control?

Or, maybe even better, instead of using that pin as a uart cts signal,
maybe redo the pinmux to make it a gpio pin, then use the standard
gpiopps driver.  You might need to add a symlink from /dev/gpiopps0 to
/dev/gps1 or whatever gpsd expects.

I'm not sure how to do the pinmux node for a gpio pin on that hardware,
but you can probably find an example of that.  The dts source to enable
a gpio pin for pps is:

/ {
	pps at 0 {
		compatible = "pps-gpio";
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_pps0>;
		gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */
		status = "okay";
	};
};

The gpios= property will need to refer to the right bank and pin number
for that hardware.

-- Ian