Pine64-LTS overlays for uart ports fixed!
Kaya Saman
kayasaman at optiplex-networks.com
Fri Aug 2 19:09:14 UTC 2019
On 8/2/19 4:14 PM, Ian Lepore wrote:
> On Thu, 2019-08-01 at 13:27 +0100, Kaya Saman wrote:
>> [snip]
>>
>> On 7/31/19 5:22 PM, Kaya Saman wrote:
>>>>> 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).
>>
>> Just found this:
>>
>> https://lists.gnu.org/archive/html/gpsd-users/2017-09/msg00031.html
>>
>>
>> Uh, no. lease reread the output. gpsd is accepting the leading edge, and
>> rejeecting the trailing edge. Just as it should.
>>
>>> /Sep 18 23:36:50 k9 gpsd[15453]: gpsd:PROG: KPPS:/dev/ttyS2 assert> /
>>> /1505777810.100060219, sequence: 8, clear 1505777810.000026753, sequence: 8 /
>>> /- using: assert/
>> Accepted edge.
>>
>>> /Sep 18 23:36:50 k9 gpsd[15453]: gpsd:PROG: PPS:/dev/ttyS2 Assert
>> rejected 1Hz /
>>> /trailing edge/
>> Rejected trailing edge.
>>
>> A pulse has two edges. PPS uses the eading one, and ignores the
>> trailing edge.
>>
>>
>> Looks like it's working properly :-)
>>
>>
>>>
>>> [snip]
>>>> 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
>>>>
>>> This might work better. I'll have a go later today. I did have issues
>>> while trying things out on Armbian so I don't know if it will the same
>>> case with FreeBSD. Virtually what happened was that setting the pin in
>>> the loader didn't take effect.
>>>
>>>
>>> Thanks again Ian :-)
>>>
>>>
>> My GPIO file features this:
>>
>>
>> /dts-v1/;
>> /plugin/;
>>
>> / {
>> compatible = "allwinner,sun50i-a64";
>>
>> fragment at 0 {
>> target = <&pio>;
>> __overlay__ {
>> pps_pins: pps_pins {
>> pins = "PD4";
>> function = "gpio_in";
>> };
>> };
>> };
>>
>> fragment at 1 {
>> target-path = "/";
>> __overlay__ {
>> pps at 0 {
>> compatible = "pps-gpio";
>> pinctrl-names = "default";
>> pinctrl-0 = <&pps_pins>;
>> gpios = <&pio 3 4 0>; /* PD4 */
>> status = "okay";
>> };
>> };
>> };
>> };
>>
>>
>> So in conjunction with reading the example:
>>
>>
>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */
>>
>>
>> If we take the Pi2-bus connector:
>> http://synfare.com/599N105E/hwdocs/pine64/gpiosgeo.html
>>
>> and just use for argument sake pine PC9 as PPS input.
>>
>> Using: gpioctl -lv
>>
>> the pin number becomes: pin 19: 0 PC9<PU>, caps:<IN,OUT,PU,PD>
>>
>>
>> I'm not sure how to interpret this: gpios = <&pio 3 4 0>; /* PD4 */
>>
>> - as pin PD4 is being registered as: pin 31: 0 PD4<>, caps:<IN,OUT,PU,PD>
>>
>> I can only guess that it is 'bank 3' <PD range> , 'pin 4' <PD4> , there
>> for the line would need to be changed to:
>>
>> gpios = <&pio 3 4 0>; -> gpios = <&pio 2 9 0>; Possibly?? <- ok just
>> tested and it's not working :-(
>>
>>
>> Ian, I think I ran in to an issue with the CTS. It might be exactly as
>> you mentioned in that the uart port maybe trying to use it for something
>> else?? I disabled flow control using stty for both cuau4.init and
>>>> Best Regards,> >
>>>>
>>>> Kaya> >
>>>> _______________________________________________> > freebsd-
>> arm at freebsd.org mailing list> >
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm>; > To
>> unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org">
>> ttyu4.init. The interesting thing here is that with the GPS PPS plugged
>> in I get 'PPS time out' messages, if I move the PPS wire to a different
>> ping (a GPIO pin for example) then re-plug it back into the uart4 CTS
>> pin it works?
>>
>>
>> ---- 3rd send attempt; have just contacted @Postmaster about the
>> issue
>> and seems like there is an issue so if anyone else is having issues
>> sending to the list it is being worked on currently :-) -> just an
>> FYI :-)
>>
>>
>>
> When gpio pins are banked and a single device instance handles all the
> banks, which appears to be your case, then it's device-specific how
> gpioctl maps bank+pin to a linear pin number. I would make the same
> guesses you did. Or I would look at the driver code, but I don't even
> know what driver is involved there.
>
> One thing to check is to make sure nothing else is trying to configure
> the PC9 pin if that's the one you chose for gpio-pps input. I created
> that problem for myself last night while setting up a test... I wrote
> an overlay that reassigned a given pin as a gpio input, but forgot that
> elsewhere in the dts that pin was assigned to an sdcard slot. So
> during kernel init the pin was first getting set to my gpio input, then
> later when it got to the sd device's pins it got reassigned back to an
> output. Easily fixed by adding a status = "disabled" for the sd device
> once I remembered it was there.
>
> Another thing I ran into... I wanted to test using CTS as the pps input
> on an imx6 board, and it wasn't working. Eventually I figured out that
> the uart driver for imx6 just doesn't support rts/cts signals at all.
> Doh! So your efforts to use CTS could be running into something like
> that; I suspect imx6 isn't the only arm uart driver that's basically a
> 3-wire driver.
>
> -- Ian
>
>
Initially I performed a few tests on gpio just to see if the OS pin
mappings correlated to the the actual mappings.
Starting with gpioctl -lv - I got a listing of all the pins; great ;-)
pin 19: 0 PC9<PU>, caps:<IN,OUT,PU,PD>
pin 20: 0 PC10<PU>, caps:<IN,OUT,PU,PD>
pin 21: 0 PC11<PU>, caps:<IN,OUT,PU,PD>
pin 22: 0 PC12<PU>, caps:<IN,OUT,PU,PD>
pin 23: 0 PC13<PU>, caps:<IN,OUT,PU,PD>
pin 24: 0 PC14<PU>, caps:<IN,OUT,PU,PD>
pin 25: 0 PC15<PU>, caps:<IN,OUT,PU,PD>
pin 26: 0 PC16<IN>, caps:<IN,OUT,PU,PD>
Then I tried to assign PC9 and PC16 which are adjacent as output pins.
As I don't have a multimeter on hand or CRO I used the next best thing,
a 5v LED. Using jumper cables I coupled the LED between PC9 first and
GND. Then ran:
gpioctl -c 19 OUT
observe output using -lv and yes it has changed. Afterwards I tried to
set the pin to a 'high' level:
gpioctl 19 1
LED illuminates. Fantastic! Same procedure for pin 26 too. Satisfied
that the pin numbers are correct and mapped properly I then looked at
connecting a switch. First set pin 26 to IN. Connect switch between GND
and PC16. Press button and observe output of pin... nothing. Ok fine, it
is waiting for a state change and is already at 0 doh! Let's attempt to
invert the behavior: gpioctl -c 26 II -> no change, nothing is working.
Aaaah but there is a 3.3v output header on the board so let's try that
instead of GND and bang waddya know.... state change from 0 to 1 whoohoo
:-) :-)
Next thing is just simply tying the pin to Lcdproc which shouldn't be
too difficult.
for reference to GPIO I found this
(https://vzaigrin.wordpress.com/2014/04/18/working-with-gpio-on-raspberry-pi-with-freebsd/)
Something interesting I found out. It seems at the initialization
(startup) stage that the TTL -> RS232 shifter is going high on the CTS
pin. This is the reason why my PPS signal is not being detected. If I
power down the board and remove the PPS jumper wire from the CTS header
then power up and start GPSD as normal, then insert the PPS jumper back
into the CTS pin it functions fine. Accuracy is also very good:
# ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
SHM(0) .NMEA. 0 l 12 16 377 0.000 -31.383
16.450
*SHM(1) .PPS. 0 l 11 16 377 0.000 -0.004 0.002
Here I need to do one of two things; 1. set the CTS pin to disabled in
FreeBSD until the PPS signal starts pulsing then enable it - or - 2.
introduce a mechanical switch into the signal path to manually
enable/disable the PPS signal.
Testing with my trusty LED, at startup the voltage on the RS232-TTL
shifter is at a constant high, ie. LED is on. After a while it will
start to pulse. Hence my thoughts above.
Perhaps "
Easily fixed by adding a status = "disabled" for the sd device
once I remembered it was there.
" is what I'm looking for? Where is this set?
Regards,
Kaya
More information about the freebsd-arm
mailing list