-
Notifications
You must be signed in to change notification settings - Fork 228
applet.interface.freq_counter: implement basic frequency counter #218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
re aliasing: With a ~44.1kHz input, we'll typically see one of the following two outputs over a 131072 clock period (@48MHz = 2.73ms). I've thought about this a little more... the resolution of the output is the sample period (or its frequency).
From here we get diminishing returns, so I think I'll set the default duration to 2 seconds, for a 0.5 Hz resolution. I might also present the resolution or error for the measurement in the output. |
The ripple counter's length is essentially unlimited, right? (Limited only by FPGA size.) So you can make something obscenely large, like a 32 bit counter, and run it for a second or even several seconds. That's like averaging you suggested on IRC but with less work. |
|
Yes, correct. I'm planning to make the sample period configurable at runtime, but with a default of 1-2 seconds to help improve this. |
48a781f to
46d9214
Compare
This commit is work-in-progress: - Create `FrequencytCounterInterface` class - Add duration command line argument - longer run offers higher resolution - Clean up output
| clk=self.pads.i_t.i, | ||
| clk_en=self.running, | ||
| width=64, | ||
| width=32, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The gateware doesn't care about the register width at all, a 1-bit one is as atomic as a 128-bit. The reads are always atomic. The writes are never atomic, they are shifted in in 8-bit chunks. (This is probably a bug.)
As discussed in
#glasgow, this PR will implement a basic frequency counter, based on a ripple counter, paired with using the Glasgow's clock as a time reference.This commit is work-in-progress:
FrequencytCounterInterfaceclassNOTE: This PR differs from #216 - that is providing more complex (but still basic) signal analysis, while this provides a pure frequency / edge counter.