Harlan, This has come up several times over the years (I give you the parse clocks as one approach). Here has been my reply on these occastions.
Almost all reference clock derivers can be designed as a state machine which has largely been implemented in the reference clock interface. There is a state machine for received messages and another for transmitted messages. For most drivers this is rather simple with only silly details of polling and timeout remaining to be resolved. That took a good deal of development over several versions with a serious goal to keep it simple. What you might have in mind is the timecode interpretation. Once upon a time this was done in vastly different ways with lots of icky code. The reason for this was Dennis Fergusson's desire to use the code in an embedded system with no Unix library. Now the Unix library is in a wristwatch computer. Believing in Occam's Razon, I submit the ASCII timecode state machine of choice is the scanf() routine. The state machine program is simply the format string. Simple, fast and not too intrusive. I've never found an ASCII timecode that couldn't be easily parsed and error-checked this way. With the interface and these routines there isn't much else and what else would be hard to handle with a common state machine. Most drivers I have written use the read line/chunk routines in the interface, check line length, call scanf(), tease out the quality and leap bits and pass the data structure to the interface. Drivers are written so that several machines can share the received data while one of them polls the clock. For these reasons and long experience in crafting the interface and writing drivers, I don't think more is better. Dave Dave Harlan Stenn wrote: >>>>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Hal Murray) writes: > > > Hal> I'd like to be able to say "Z3801A" rather than whatever line settings > Hal> it actually uses. > > I agree and suggest: > > http://support.ntp.org/bin/view/Dev/NewNtpConfFormat > > as I did in a previous reply on the parent thread. > > Hal> I'd also like to be able to specify the raw line details in case I find > Hal> a box that is close enough but uses some strange line settings. (The > Hal> Z3801A is a good example. That was the only change it took.) > > I've wanted this for a long time too: > > http://support.ntp.org/bin/view/Dev/LoadableRefclockDrivers > > where I talk about a lightweight "refclock processing language". > > H _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
