gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] GPSd on FreeBSD


From: Gary E. Miller
Subject: Re: [gpsd-dev] GPSd on FreeBSD
Date: Mon, 9 Sep 2019 21:18:23 -0700

Yo Daniel!

On Tue, 10 Sep 2019 13:04:45 +0930
"O'Connor, Daniel" <address@hidden> wrote:

> > I am unsure what's different now between freebsd and netbsd, but my
> > impression is that one does pps on serial by doing pps ioctls on a
> > serial port, rather than a specific /dev entity just for pps edges
> > derived from another /dev entity.  
> 
> This is a bit different to a normal PC approach.
> 
> The GPS engine is connected to a normal UART (/dev/cuau2) but there
> is a special driver  (dmtpps -
> https://github.com/freebsd/freebsd/blob/master/sys/arm/ti/am335x/am335x_dmtpps.c)
> that uses an input capture timer on the Beaglebone SoC to capture the
> PPS edges. This lets you avoid the interrupt latency because the
> hardware captures a 24MHz counter and then raises an interrupt. The
> kernel driver reads out the timer value to work out when it happened.

That is certainly unique.  If you understand the issue then see if
you can come up with a patch.

> >>> It seems it isn't actually opening /dev/pps0 (based on the -2 for
> >>> FD)  
> >> 
> >> No, re-read the message.  It just says it can not use TIOMCIWAIT.
> >> It should use KPPS instead, which is better, but that also failed.
> >>  I'm not afmiliar enough with *BSD to know why, but it does work
> >> for others.  
> > 
> > AIUI, TIOMCIWAIT is an extension to the standards-defined PPS, and
> > is present in Linux and OpenBSD, but not in NetBSD.  
> 
> Yes that is a red herring here, it should use time_pps_* on the
> dmtpps device node.

If you understand the issue, then send a patch.

> >> I'm unfamiliar with ppsapitest.  What does "ppscheck /dev/pps0"
> >> show?  
> > 
> > ppsapitest probably tests to the spec.  I'm assuming ppscheck is
> > from gpsd, and would test to what gpsd uses - of course quite
> > relevant here.  
> 
> Unfortunately as per my other email it doesn't build because it
> requires TIOMCIWAIT which FreeBSD doesn't have.

Ah, yes, scons is not building due to no TIOMCIWAIT.  I thought that
had been fixed...

> 
> >>> Examining the code shows a big chunk is Linux specific so I guess
> >>> I will have to modify it but if someone has advice on what the
> >>> "right way" to do is that would be great :)  
> >> 
> >> When you compiled gpsd it auto-detects your system.  It will
> >> autodetect many flavors of *BSD and work just fine.  
> > 
> > The PPS code assumes there is some ioctl to "wait until a pps
> > edge", not found in RFC? that defined the original PPS interface,
> > and there was no path to it working well without that - a fairly
> > minor (probably 4 hours to code and debug) reorg is needed to make
> > it work without,  without impairing performance on systems that
> > have the ioctl.
> > 
> > I was thinking about this years ago, and have never gotten around
> > to it.  
> 
> I am not 100% sure what you mean, but I see gpsd has calls to
> time_pps_* but it feeds them an FD of -2 which looks like a bug.
> There are a number of '#ifdef __linux__' blocks which I haven't fully
> decoded yet though.

The FD of -2 is after the first failure.  The first failure is the
failure to open the device, which returned the error code of -2 in place
of an FD.  It does look like gpsd should not have continued using the
error return as an FD.  But the first failure was earlier than you are
looking.

> > The ntpd that's part of NetBSD base understands PPS and works with
> > PPS devices (without gpsd).  I would expect that FreeBSD base
> > system ntpd, or FreeBSD ports ntpd would also do that.  
> 
> Yes, initially I got ntpd to parse the NMEA sentences and use the PPS
> edge captures, sorry if I wasn't clear enough about that on my
> initial email.

Figure out what NTP is doing and let's see if we can get gpsd to do
similar on your distro.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgp_jVYgPeXJT.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]