lucian_dusk
Active member
Hey all,
I’m trying to work a clock/trigger signal input in to my project. Couldn't find anything using search - hope this hasn't been already solved somewhere else.
This originally worked as rough-style “tap tempo” code with a button, and I figured the same concept could be used to calculate the period of an input signal. It usually expects very slow clock signals, in the low Hz range, but should accept much faster eventually.
Couple notes: this is very “alpha”. There are a few things that obviously need improvement in their approach. Firstly, the clock input signal is recognized using “Bounce”, which definitely is too slow. The variable this function returns is also in a weird format, e.g. millisecond interval between pulses; it should ideally return a value in Hz.
The first thing I notice is that when I use an encoder to change the value of a clock signal driving the input, I can see that the resulting clkRate is always rounded to the nearest 25.
I assumed might have to do with working coursely in millis and not micros. When I change the variable from elapsedMillis to elapsedMicros and divide the end result by 1000, the results are totally unpredictable.
My questions are such:
1. I know this is a clumsy and awkward approach. Is there a function I’ve never heard of that can accurately read the rate of an input oscillating signal?
2. Why is the clkRate rounding to multiples of 25?
3. Is it fair to drop the Bounce entirely?
Thanks! Been a great learning experience so far.
-L
I’m trying to work a clock/trigger signal input in to my project. Couldn't find anything using search - hope this hasn't been already solved somewhere else.
This originally worked as rough-style “tap tempo” code with a button, and I figured the same concept could be used to calculate the period of an input signal. It usually expects very slow clock signals, in the low Hz range, but should accept much faster eventually.
Couple notes: this is very “alpha”. There are a few things that obviously need improvement in their approach. Firstly, the clock input signal is recognized using “Bounce”, which definitely is too slow. The variable this function returns is also in a weird format, e.g. millisecond interval between pulses; it should ideally return a value in Hz.
Code:
Bounce clkinA = Bounce(0, 1);
elapsedMillis clkinA1;
uint16_t clkRateStart;
uint16_t clkRate = 800;
bool checking;
uint16_t clkIn(){
if (clkinA.update()){
if (clkinA.risingEdge()&&checking==LOW) {
clkRateStart = clkinA1;
checking = HIGH;
}
else if (clkinA.risingEdge()&&checking==HIGH) {
clkRate = (clkinA1-clkRateStart); //duration between two pulses
checking = LOW;
}
}
return clkRate;
}I assumed might have to do with working coursely in millis and not micros. When I change the variable from elapsedMillis to elapsedMicros and divide the end result by 1000, the results are totally unpredictable.
My questions are such:
1. I know this is a clumsy and awkward approach. Is there a function I’ve never heard of that can accurately read the rate of an input oscillating signal?
2. Why is the clkRate rounding to multiples of 25?
3. Is it fair to drop the Bounce entirely?
Thanks! Been a great learning experience so far.
-L
