FreqCount caution

analog&RFmodels

Well-known member
after running several hundred cold starts the 100% safe thing to do is on FreqMeas, delay for 40 microsec just after ...begin AND do two dummy cycles before real measurements,
this only costs about 52 microseconds

similarly on FreqCount, do one dummy meas cycle before real measurements (i knew the TLC usually needed this) in my typical application this really has no cost because i just start
my FreqCount loop one time interval early, loop one more time than required, and when pulling results out of the array later just start w index one higher than i would have

in my typical applications these work-arounds are simple and do not stop the show

these cautions are applicable to the TeensyLC and Teensy4, and i have not tested Teensy 3.6, and cannot test any others
i am not sure how to link threads so i will start a new one w this same content titled FreqCount caution.
 
There is an open thread on this :: pjrc.com/threads/58026-Teensy-4-FreqMeas-problem

There may hopefully be a way to fix this in the FreqMeas.begin() - pjrc.com/threads/58026-Teensy-4-FreqMeas-problem

Links for any post can be had with 'right click' on the "post #" hyperlink for that post.

Links can be included with Ctrl+L - or clicking the "Globe Icon with 'chain link'" shown on it - then fill in the link and hit Enter.

Not sure starting this extra thread until above linked thread gets attention/resolution is the best?

And AFAIK the easy way to discard the first erroneous readings is posted on that thread:
Code:
FreqMeasure.begin();
delayMicroseconds(15);
while (FreqMeasure.available()) FreqMeasure.read();
 
Post #2 code does not work … now with second thread it requires editing in two places … Teensy-4-FreqMeas-problem

… code like this actually resolves the issue:
Code:
      FreqMeasure.end();
      FreqMeasure.begin();
      {
        while (!FreqMeasure.available());
        int yy = 0;
        while (FreqMeasure.available() || yy < 2 ) {
          if ( FreqMeasure.available()) {
            FreqMeasure.read();
            yy++;
          }
        }
        Serial.print("\t\t DISCARD INITIAL READS #=");
        Serial.println(yy);
      }
 
confused

after running several hundred cold starts the 100% safe thing to do is on FreqMeas, delay for 40 microsec just after ...begin AND do two dummy cycles before real measurements,
this only costs about 52 microseconds

similarly on FreqCount, do one dummy meas cycle before real measurements (i knew the TLC usually needed this) in my typical application this really has no cost because i just start
my FreqCount loop one time interval early, loop one more time than required, and when pulling results out of the array later just start w index one higher than i would have

in my typical applications these work-arounds are simple and do not stop the show

these cautions are applicable to the TeensyLC and Teensy4, and i have not tested Teensy 3.6, and cannot test any others
i am not sure how to link threads so i will start a new one w this same content titled FreqCount caution.

i am confused by post 2 and 3 - the whole reason i created "FreqCount caution" was to call attention to the FreqCount funny
whereas post 2 and 3 focus on FreqMmeas which maybe belong under "teensy4 FreqMeas problem?" ???
 
i am confused by post 2 and 3 - the whole reason i created "FreqCount caution" was to call attention to the FreqCount funny
whereas post 2 and 3 focus on FreqMmeas which maybe belong under "teensy4 FreqMeas problem?" ???

Opps :: More confusion here it seems - was rushing to do some things and conflated Freq Count and Measure.

However - quite possible a similar problem and solution apply as they both rely on "count - count_prev" to return the desired value.
And both do .begin() in effect with :: count_prev = 0;
Code:
uint32_t FreqCountClass::read(void)
{
    count_output = count - count_prev;
    count_prev = count;
    //Serial.println(count - count_prev);
    count_prev = count;
 
i agree, however, i have glanced thru the library files and can only say - way above my pay grade.

i think you or some other professional programmer will have to tackle that.
 
Not sure if there is a way at .begin() to get a true start value synchronization? I found something close - but it is uniformly off and stays that way once I hack it.

I'm not up for reading the book to understand operation just now - just into my outdoor summer chores - and fall is about a month gone.

Maybe just need to add a .flush() with a timeout to get the initial 2 reads after .begin():
Code:
        {
        int yy = 0;
        while ( yy < 2 ) {
          if ( FreqMeasure.available()) {
            FreqMeasure.read();
            yy++;
          }
        while ( FreqMeasure.available()) FreqMeasure.read();
        }
 
Back
Top