= Solution
A 32-bit free-running timer operates modulo $M=2^{32}$. If its previous reading is $p$, and the actual elapsed count is $d$ with $0\leq d<M$, the new reading is $(p+d)\bmod M$. The <modulo-counter elapsed-time identity> therefore gives
$$
\boxed{(\texttt{uint32\_t})(\texttt{now}-\texttt{previous\_tick})=d.}
$$
<Unsigned integer arithmetic in C> reduces the subtraction modulo $2^{32}$, so the identity remains valid when a wrap occurs between pulses. For example, readings $2^{32}-8000$ and $8000$ give 16,000 ticks, hence one millisecond, rather than a negative interval.<C11 committee draft N1570>[Section 6.2.5 paragraph 9, unsigned arithmetic modulo one greater than the maximum representable value]{ref}
At the specified clock rate, \b[the true wrap period is $2^{32}/16{,}000{,}000=268.435456$ seconds]. The printed 256 seconds is inconsistent with the other two specifications. The implementation uses the stated 32-bit width and 16 MHz rate. Assuming consecutive handled pulses are less than 256 seconds apart is a sufficient conservative bound; the exact allowable bound is less than 268.435456 seconds.
This calculation requires less than one entire timer modulus of elapsed ticks between successive stored timestamps. If a whole wrap or several wraps elapse, identical register readings cannot reveal how many occurred; an overflow counter or an independent longer-range clock would be needed. Also assume pulse events are not lost and interrupt latency is constant or sufficiently small for the required accuracy: timestamps read in software measure handler-to-handler intervals, not perfect hardware capture times. Conversion to milliseconds occurs after modular subtraction, so separately rounded absolute timestamps cannot corrupt the wrap calculation.
Back to article page
