gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] gpsd processor load


From: Andy Walls
Subject: Re: [gpsd-dev] gpsd processor load
Date: Wed, 30 Oct 2013 20:27:12 -0400
User-agent: K-9 Mail for Android

time_pps_fetch() on Linux 3.5 works well and does indeed block until the next event. You need to install the pps-tools to get the timepps.h header.

In fact today I just wrote a client that uses a blocking time_pps_fetch() and then examines time in the NTP0 shared memory segment in a loop.

Regards,
Andy

"Gary E. Miller" <address@hidden> wrote:
Yo Chris!

On Wed, 30 Oct 2013 16:16:24 -0700
Chris Kuethe <address@hidden> wrote:

TIOCMIWAIT is what sleeps and wakes up the thread. It would need
to be replaced with some sort of usleep() and then KPPS would need
to actually work on BSD. Doable, but a lot of work, and only a BSD
person could do it.
I don't think any of the BSDs seem to have TIOCMIWAIT.

I baffled how they can manage without TIOCMIWAIT. How can you write any
sort of low level serial client without it? BSD has to have some way to
wake on control changes...

I think select() will return a ready fd with no data bytes from
read() when a control line changes.

Thn the PPS thread would wake up on every character as well. Not good.

Could we fake it on that?

Maybe, but it all needs KPPS to work to get any sort of time. And if
KPPS is working we just need to wake up the thread a few times a second
and check if KPPS has anything for us.

Looking at RFC 2783, there is a way to have time_pps_fecth() block until
the next edge. Linux does not need that and has no documentation if it
would work. That might be the answer if you can figure it out.

RGDS
GARY


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

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
reply via email to

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