Subject: Re: new-API for DCD time stamps
To: Alan Barrett <apb@iafrica.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 04/21/1998 01:55:53
>Instead of the #ifdef PPS_TRAILING_EDGE stuff being a compile-time
>decision, how about making everything else use three three states: off /
>on (rising edge) / on (falling edge).
thanks for the constructive criticism; it's welcome.
I did think about that, but I think that having the once-per-second,
on-the-UTC_second-epoch pulse on the trailing egde is really a
hardware bug. All GPS clocks I know of require TTL to RS-232 level
converter (as in Mill's schematic, or the TAPR "TAC" kit). The
level-conversion hardware can and should handle a polarity inversion.
Users with hardware that doesn't, can recompile with "options
PPS_TRAILING_EDGE". That's the historical tradeoff, and it seems
good enough to me.
Anyone out there got a Garmin clock with a noninverting level convereter?
I've also got some prototype code which hooks the PPS signal to a
parallel-port interrupt line. No glue logic is needed for that so
there I think tristate is the right thing.
And as you pointed out in private email, the ugly overloaded ioctl() can
be handled even more tersely with a fallthrough:
> + case TIOCDCDTIMESTAMP: /* XXX old overloaded API */
> + com->sc_dcd_timestamping = 1;
> + /*FALLTHROUGH*/
> + case TIOCLASTDCDTSTAMP:
> + *(struct timeval *)data = com->dcd_timestamp;
and Stephen Ma noticed the patch I posted is missing a closing paren.
I'll put a updated patch on the FTP server for perusal tomorrow,
possibly with hardpps() too.