Charlie
Thanks very much for your well researched and very clear description
of the issue. I am not familiar with the driver level environment
under Linux and greatly appreciate your insight.
Unfortunately, try as I might, I just cannot get the TIOCMIWAIT call
in gpsd_ppsmonitor to complete successfully, despite the continued
presence of the 1Hz PPS signal on the DCD line (as reported by
statserial).
I tried the following:
1. Added debug statements at all references to CLOCAL and CRTSCTS in
the source code. Only the ones on serial.c are executed. Also added
debug code to verify that the settings made in serial.c are unchanged
by the time we get to gpsd_ppsmonitor. They are the same.
Iterated through the following code changes. In each case, TIOCMIWAIT
fails to complete.
2. Removed CLOCAL from the call to set ( |= )the c_cflag bits.
3. Added CLOCAL to the call to reset ( &= ~) c_cflag bits, on the
theory it might be set by default
4. Moved CRTSCTS from the reset call to the set call, just to be
certain it is set.
I ran out guesses there, so I decided to see if this was the only
issue remaining between me and a high precision time server. So I
turned the gpsd_ppsmonitor control structure into a polling loop that
used TIOCMGET to detect changes in the DCD line directly. Once a
transition was found, control was turned over to the existing
NTP/shared memory code.
C is not really my strong suit, so I just used a select statement to
delay at least 100 usec between calls. This essentially worked, but
apparently produced a fairly ragged clock, because the pulses that
were accepted produce messages indicating a loss of sync from the
NTP/shared memory calls.
There are no doubt more clever ways to do this, but my main goal was
to convince myself that, if I can get TIOCMIWAIT to work, then the
whole high precision gpsd/ntpd clock source thing would work. This
was not entirely successful in that ntpd -q never did indicate that it
had seen the high precision clock in shared memory
So, at this point, I think the next move is to create the simplest
program possible to exercise the TIOCMIWAIT call on /dev/ttyAM0 with
the GPS plugged in, and see if it ever complete there. If it does,
then the problem is with the gpsd code. If it does not, then the
problem is on the OS side. I think.
Thanks and Regards,
jw
BTW I also googled around for 'gpsd pps clocal TIOCMIWAIT' in various
permutations and did not really see this issue addressed.
BTW2: I am running Debian system with a home built 2.4 kernel based
on the TS source code on a 7260. gpsd-2.34 is being used with a Garmin
GPS 18 LVC.
--- In "charliem_1216" <> wrote:
>
> Hi Gonzalo & JW --
>
>
> > > 2. I got the statserial application (apt-get install statserial)
> and
> > > ran it on the GPS port (/dev/ttyAM0), and it clearly sees the
> DCD line
> > > toggling once per second. This indicates the presence of the
> PPS
> > > signal coming from the GPS
>
> Good!
>
> > > following TIOCMIGET call in gpsd_ppsmonitor never completes:
> > >
> > > while (ioctl(session->gpsdata.gps_fd, TIOCMIWAIT,
> pps_device) ==
> > 0) {
> > >
> > > where pps_device is set to TIOCM_CAR
> >
> > Apparently TIOCMIWAIT call may relay on interrupts (is hardware
> > dependent) and it is possible that the serial port is not
> generating
> > interrupts on DCD. This is just a theory thou.
>
> Yes, I think this is right. statserial works because (I guess) it
> uses polling, not interrupts. The EP9301 spec sheet and EP9301 User
> Manual both say interrupts on modem status change lines is
> supported, so why is it not being generated?
>
> Looking at the file ./drivers/serial/ep93xx_amba.c in the TS source
> tree, we see:
>
> old_cr = UART_GET_CR(port) & ~AMBA_UARTCR_MSIE;
>
> if (UART_ENABLE_MS(port, cflag))
> old_cr |= AMBA_UARTCR_MSIE;
>
> So here it decides whether to turn on the modem status interrupt
> based on the test UART_ENABLE_MS. (MSIE is Modem Status Interrupt
> Enable, and CR is the port Control Register).
>
> But if we look at ./include/linux/serial_core.h in the TS tree, we
> see:
>
> /*
> * UART_ENABLE_MS - determine if port should enable modem
> status irqs
> */
> #define UART_ENABLE_MS(port,cflag) ((port)->flags &
> UPF_HARDPPS_CD || \
> (cflag) & CRTSCTS || \
> !((cflag) & CLOCAL))
>
> So it seems the ep93xx_amba.c driver will only turn on the modem
> status interrupt if hardpps is enabled (as mentioned before, by
> patching setserial), OR if CRTSCTS is set, OR, if CLOCAL is NOT set.
>
> Finally, looking in gpsd sources serial.c, we see CLOCAL being set,
> and also ~CRTSCTS being set, thus preventing MSIE from being set by
> the driver.
>
> So, you could try to patch gpsd to not set CLOCAL or to set CRTSCTS.
> Maybe the gpsd mailing list would have some suggestions here, like
> adding a config option to set CLOCAL.
>
> Or you could try patching setserial to enable the hardpps bit (but
> I'm not sure if that alone is sufficient or if you would need other
> supporting patches from the ppskit package).
>
> (Note this is untested as I don't have anything to generate a PPS
> signal myself. Also, I assumed you are using the TS 2.4 kernels.
> The 2.6 amba serial driver is very different, but may have the same
> issues).
>
> Regards, ........ Charlie
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|