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.