Is it possible to use FreqMeasure with pins other than the one specified?

Status
Not open for further replies.

450nick

Active member
I'm having some trouble reliably reading an incoming frequency on an analogue pin on a Teensy 3.2 and was hoping to be able to use this library but it appears to only work with a single pin that I'm already using for serial communication. Can it be used with a conventional analogue pin? If not, is there a good way to determine frequency seen with some other library or method?

Thanks!
 
I am not an expert on this...

But a quick look at the sources:
In particular FreqMeasure\util\FreqMeasureCapture.h

I see the section:
Code:
// Teensy 3.1, 3.2, 3.5, 3.6
#elif defined(__MK20DX256__) || defined(__MK64FX512__) || defined(__MK66FX1M0__)
  #define CAPTURE_USE_FTM1_CH0 3    // FTM1 CH0 is pin 3
  //#define CAPTURE_USE_FTM1_CH1 4  // FTM1 CH1 is pin 4
  //#define CAPTURE_USE_FTM2_CH0 32 // FTM2 CH0 is pin 32 (Teensy 3.1 and 3.2)
  //#define CAPTURE_USE_FTM2_CH1 25 // FTM2 CH1 is pin 25 (Teensy 3.1 and 3.2)
  //#define CAPTURE_USE_FTM2_CH0 29 // FTM2 CH0 is pin 29 (Teensy 3.5 and 3.6)
  //#define CAPTURE_USE_FTM2_CH1 30 // FTM2 CH1 is pin 30 (Teensy 3.5 and 3.6)
So it looks like it may be possible to uncomment a different line here for a few different options.
 
Thanks Kurt! I might give that a go - before I do though I'm curious as to why it is pin specified - is there something about that pin that makes it work above others? Ultimately I need to monitor two sets of pulses with one arduino - RPM and Speed signal, one up to 3kHz, one up to I guess 600Hz
 
Thanks chaps, I think I will go another way with this. I think I've managed to crack it using an interrupted pin rising method working in micros.
 
FreqMeasure will give much better performance, because the FTM timer hardware captures the event. In it unaffected by interrupt latency, unless (the unlikely case) interrupts are delayed for so long that the next event is captured. Because the event it captured by hardware, it doesn't matter if another interrupt or code which temporarily disables interrupts causes it to read from the hardware with a small delay.

Using a pin interrupt will have sensitivity to interrupt latency. Maybe that's not a big problem, if you don't need high accuracy? But if you stay with that approach, one thing you can do to improve it is raise the priority of the pin interrupt you're actually using. That still won't make it as good as a FTM timer's input capture hardware, but it will at least avoid some inaccuracy if the pin changes while a USB or Systick interrupt is in progress.
 
Status
Not open for further replies.
Back
Top