applet.interface.freq_counter: implement basic frequency counter

[attie]

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:

• [ ] Create FrequencytCounterInterface class
• [x] Add duration command line argument - longer run offers higher resolution
• [ ] Clean up output
• [ ] Present measurement precision / error in output (as calculated below)

NOTE: This PR differs from #216 - that is providing more complex (but still basic) signal analysis, while this provides a pure frequency / edge counter.

[attie]

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). 1 LSB = ~366.211Hz.

edge_count=120
signal_freq=43945.312

edge_count=121
signal_freq=44311.523

---

I've thought about this a little more... the resolution of the output is the sample period (or its frequency).

• Above, the sample period / frequency is 48e6 Hz / 131072 = 366.21 Hz, therefore 1 LSB = 366.21 Hz, or ~2.73066ms
• Extending the sample period to 0.5 seconds produces a resolution of 1 / 0.5 sec = 2 Hz
• Extending the sample period to 1 second produces a resolution of 1 / 1 sec = 1 Hz
• Extending the sample period to 2 seconds produces a resolution of 1 / 2 sec = 0.5 Hz

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.

[whitequark]

re aliasing:

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.

[attie]

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.