counter question
jstjohnz
Posts: 91
I am trying to measure the timing error in a 1hz pulse. My plan is to set CTRA to count clock pulses when the input is low, and CTRB to count clock pulses when the input is high.
Whenever the input signal changes state, I will get the count from the counter that's not presently counting and add it to my total, then reset that counter.
My question is, will the total of these counters always be equal to the total number of elapsed system clock cycles, or is there a possibility of missing a count, or getting an extra count, depending on exactly when the transition on the 1 hz line occurs?
(This question/plan also posed in my GPSDO thread, but also here as it's a generalized counter question)
Whenever the input signal changes state, I will get the count from the counter that's not presently counting and add it to my total, then reset that counter.
My question is, will the total of these counters always be equal to the total number of elapsed system clock cycles, or is there a possibility of missing a count, or getting an extra count, depending on exactly when the transition on the 1 hz line occurs?
(This question/plan also posed in my GPSDO thread, but also here as it's a generalized counter question)
Comments
If you are worried about precision, I would avoid GATED clocks like the plague, and I'd also avoid reset of any counters.
You can avoid both easily.
To be sure about the PLL, I'd also suggest count your 10MHz ref, via a counter. (in POSEDGE mode), and check it really is always running at exactly 1/8 of the PLL value count rate.
Run one counter from the 80MHz, and use WAITPEQ/WAITPNE to 'edge-snap' your code to the 1pps edges.
I think that snap is to 1 LSB, (the wait simply stretches) - on one of those edges, capture the counter, and increment your edge count, and calculate your frequency by the differences in readings.
With no gates and SW clears, you know there are no Sw delay effects, and no +/-1 count wobble, so you can now run a tiered freq compare, at 1 second, and also at 10 and 50 seconds. ( or longer still with a SW counter expand)
Write some simple PC test code using UNSIGNED 32 bit values, and confirm your maths - done with care, there is no wrap-around problem.
The reason I was going to use 2 counters was to avoid having to reset a counter that was counting, I would always be resetting the counter that wasn't counting.
Can you explain your comment about verifying the PLL frequency?
The rest makes sense. Whatever delay there is between the end of the WAIT and the reading of the counter shouldn't vary.
PLLs need to lock, and some have a lock flag. The Prop data sheet just says "wait 100us"
Running a counter just verifies that it really is x8, and so has not lost lock. The counter is free, since you only need one for your time-base.