
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Mar 8, 2024, at 3:29 PM, Tom Wiltshire wrote:<br class=""><div><blockquote type="cite" class=""><div class=""><div class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">At the same time, you need something that is keeping track of how long has passed since the last MIDI Clock pulse. That's going to be *another* timer peripheral, prescaled to to give you a good number of counts for likely tempos. There's no point counting 64MHz clock pulses with a 16-bit timer if it's going to overflow five times before you even get your next pulse. Equally, you don't want to lose resolution by finishing up with counts of only a few dozen for typical tempos. If realistic tempos are in the range 30BPM to 300BPM (a decade) then we'd ideally like those tempos to give timer results between (say) 60,000 and 6000 for a 16-bit timer. Reality will intrude here and we'll take whatever we can get that's closest, but that's the general idea.</div></div></blockquote></div><br class=""><div class="">You're definitely on the right track. It's possible that you'll get stuck between a rock and a hard place, where a 16-bit timer can't possibly have both enough resolution and enough range.</div><div class=""><br class=""></div><div class="">One possible solution is that some chips allow a pair of 16-bit timer/counter peripherals to be combined into a single 32-bit timer/counter.</div><div class=""><br class=""></div><div class="">Another solution is to remember that overflow can cause an interrupt, and you can increment a state variable on every overflow. Thus, if it turns out that you do need 64 MHz timing resolution (for some reason, I'm not worried about whether that's a realistic number at the moment), then you can count the overflows and end up with a count that is both very precise AND very large. This, by the way, is how stacking 16-bit timers into a 32-bit timer works - it's just more convenient to have the hardware count the overflows and present the entire thing as a 32-bit count.</div><div class=""><br class=""></div><div class="">Brian</div><div class=""><br class=""></div><div class="">p.s. I've been working with ARM for the last decade, having finished with the PIC18F before that. The timer/counter peripherals in certain ARM chips can be even more powerful than what the PIC has. Regardless, there's usually a way to solve these problems no matter what.</div><div class=""><br class=""></div></body></html>