M. Warner Losh skrev:
: 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.
Yes, this is why you must disable interrupts. You aren't racing other
parts of software, but rather you are racing the wrapping of the
counter in hardware. To reliably cope, you have to make sure that a
third-party can't interrupt you producing the cases you describe...
I agree. It is only the actual reads which needs protection for this
processing to work. There might be other constraints which require a
large part of the code to be protected, for only for the reliable
readout you can make the post-processing anytime you want.
The cases of my 3 read situation is:
early overflow:
read high
overflow
read low -+
read high -+- correct pair
late overflow:
read high -+
read low -+- correct pair
overflow
read high
no overflow:
read high -+- equal value => pick any of them freely
read low |
read high -+
Cheers,
Magnus
_______________________________________________
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.
