Cascading Timer for Frequancy Counting (32-bit) #1011
Replies: 4 comments
-
Assuming the frequency you're measuring is low enough that more than 16 bits is needed (at 20 MHz, 65536 clocks is around 3.2 ms, or 6.5ms if prescaling by or using the OVF intflag (with int off) to sneak another bit (if you clear the OVF intflag, and then check it when the capt fires, you can see if there was an overflow, and if so, add 65536 to it.), 13ms if you do both) I've thought of making a library for this, but it very rapidly gets to be a very challenging exercise in API design if you expect to be reasonably efficient. Oh - and of course, you need to be using a 2-series, since the 1-series, even the 5 parts that had the second TCB, couldn't cascade, didn't have an overflow bit, and didn't even have clock on event. And the event system was a nuclear shitstorm of bad decisions. too |
Beta Was this translation helpful? Give feedback.
-
Thank you. I will work with signals between 20 and 30 kHz. What would you recommend to me? I use attiny3226. |
Beta Was this translation helpful? Give feedback.
-
Uh, well, I'd recommend not using cascade, because it doesn't improve anything . 20kHz = 20,000 cyc/sec = 50 us/cyc 50us/cyc = 20 clocks per us = 1000 clocks per cycle. So at 20 MHz, the low end of the frequency range you mentioned will take only 1000 clocks. Hence, there is no reason to use cascade. You can see a benefit in maximum length from turning on cascade only when measuring a pulse longer than 65536 clocks in length (though you can use the trick I mentioned to get 0-131071 clock range without cascade, or 0-8.6 billion with cascade. These numbers are thus:
As you can see, cascade mode is not meant for measuring frequency but rather fairly long pulses. The limits are silly when you are considering them as frequencies I think they're 4.6 mHz (millihertz), 2.3 mHz, and 1.15 mHz. The full resolution limit of at least 0.0023 Hz translates to measuring a pulse of up tio 434 second pulse duration with a precision of 0.05 microseconds. The maximum precision with which anything can be measured by a tinyAVR 2-series is 1 system clock cycle (this is true with almost any microcontroller. A few have async timers that can do input capture (tiny 1-series and Dx-series have TCD, which can be used very awkwardly, for 12-bit input capture based on it's timebase. Officially the spec is ,max 48 MHz out of the PLL 2 or 3 times the system clock. That spec is incredibly conservative. Turns out they have a 4x secret multiplication option (they left it in the first version of the headers, that's how I know about it), and - at least for PWM (I've never actually used it as input capture because it's like 1000x harder to use than a TCB, and because of the accuracy limit described below) the TCD seemed alarmingly . The question :Can I get 32-bit resolution with input capture by using cascade mode? is not really coherent question, because resolution isn't a crisply defined thing - there are at least two different values one could quote as the resolution - the first is the maximum number of bits - 32, 33 actually if you use the ovf bit of the sderd. But if you're measuring something that never runs longer than 65535 ticks (yours is far lower and in fact stops around 1000), the high timer will never get a count event, so it's madness to describe that as 32-bit resolution. Some people would call that ~10 bits of resolution (2^10 = 1024, so that's 9.9something bits of information). That is the limit it would be if you were using a device clocked from a perfect clock. But you're not using a perfect clock. The internal oscillator is accurate to 2% or so, frequently better, but it's on that order (depends weakly on temperature and voltage. The period of each clock is also not perfectly constant (the average is stable, but I certainly saw some variation over shorter timescales. Whether that was due to changes in conditions, I'm unsure - it wasn't a precision experiment, just a verification that it was not of a magnitude that would invalidate the tuning sketch the core includes. These don't support a crystal, but external clocks are available with crystal like (tens to hundreds of ppm) accuracy at reasonable prices. So your you have precision of 50 ns, and accuracy of around 1-2% or whatever the external clock you used is accurate to. This is achieved with normal 16-bit input capture frequency mode - there's no benefit to the cascading unless your timebase is more than 65535 times the frequency you're measuring. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the very beautiful answers. |
Beta Was this translation helpful? Give feedback.
-
Can I configure the timers as cascade and make a frequency measurement with 32-bit resolution?
Beta Was this translation helpful? Give feedback.
All reactions