Pine64-LTS overlays for uart ports fixed!

[Kaya Saman]

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:
>>>> Hi guys,
>>>>
>>>>
>>>> just wanted to say that I managed to fix the overlay issue for
>>>> the uart
>>>> ports. I just updated my bug report:
>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239390
>>>>
>>>>
>>>> So, thanks to everyone who provided assistance and especially
>>>> Milan for
>>>> the introduction to the 'overlay' system and the dtso file :-)
>>>>
>>>>
>>>> Just need to figure out why PPS isn't working now, my GPS
>>>> receiver is
>>>> sending the information so it definitely is a system config issue
>>>> -
>>>> either wrong pin or something in the OS... (still looking into
>>>> it). Also
>>>> needing a driver in lcdproc for my Newhaven displays and after
>>>> that the
>>>> project will be perfect :-) :-) :-)
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>>
>>>> Kaya
>>>>
>>>>
>>> Is the GPS receiver delivering the pps signal on one of the uart
>>> pins
>>> such as cts?  If it's using cts, you probably need this change to
>>> your
>>> overlay:
>>>
>>> --- sun50i-a64-uart4.dts.orig	2019-07-30 18:35:19.188762000
>>> -0600
>>> +++ sun50i-a64-uart4.dts	2019-07-30 18:37:02.015479000 -0600
>>> @@ -30,7 +30,7 @@
>>>    		target = <&uart4>;
>>>    		 __overlay__ {
>>>    			pinctrl-names = "default";
>>> -			pinctrl-0 = <&uart4_pins>;
>>> +			pinctrl-0 = <&uart4_pins &uart4_rts_cts_pins>;
>>>    			status = "okay";
>>>    		};
>>>    	};
>>>
>>> You may also need to set sysctl dev.uart.4.pps_mode=1 for CTS, in
>>> /etc/sysctl.conf.
>>>
>>> If it's using some other pin such as RI or CD, there is no pre-
>>> written
>>> pinctrl entry for it in those overlays you found, and some more
>>> research into how to add the right pinctrl nodes will be needed.
>>>
>>> -- Ian
>>>
>> Bingo!!! :-) :-)
>>
>>
>> Thank you so much Ian.....
>>
>>
>> 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....


Still lots of work to go but it's definitely a really fun project :-)


Regards,


Kaya