> If a carry occurs between the two high readings, then we can expect > the low reading to be close to 0 on either side of the wrapping. > Which side determines which holds the right value. If the wrapping of > counter happend before reading the low part, then the low part will > be just above 0 where as if it happends just after the low read but > before the high read, the low read will be just below the maximum > counter value.
I'm interested in the case where interrupts and scheduling are enabled so there may be arbitrary gaps inserted into the simple code. My rule-of-thumb for "works right" is that the final answer has to correspond to a time between the first read and the last read. (Anywhere in there is OK.) I though I had convinced myself the above scheme would work, but now that I try again I'm not so sure. I think this case doesn't work right: read high overflow long gap read low read high Suppose the low half overflows once a second so I can use handy numbers. If the long gap is 0.6 second, the MSB of the low half will be on so we use the first high sample. That corresponds to a time 0.4 seconds before the overflow. That's outside the first-last window. (I'm assuming all the reads and checking take negligible time which seems reasonable if we are talking about 0.6 seconds of gap.) I think there is a mirror image case: read high read low long gap overflow read high Suppose the long gap is 0,6 seconds so the low half will read 0.4. The MSB will be off so we use the second high sample. That will produce an answer 0.4 seconds into the future. -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
