Teensy 4 FreqMeas problem ?

Looks like this part - where 40us delay is just the start:
Code:
  FreqMeasure.begin();
  delayMicroseconds(40);
// dummy meas 1
  delay(fmd);
fmea:
  nm = FreqMeasure.available();
  if (!nm) goto fmea;
  fm = FreqMeasure.read();
// dummy meas 2
  delay(fmd);
fmeas:
  nm = FreqMeasure.available();
  if (!nm) goto fmeas;
  fm = FreqMeasure.read();

Is the rough equal to this - no explicit wait of time - just until stay until two FreqMeasure.available()'s are .read() - takes 249us total:
Code:
        int yy = 0;
        while ( yy < 2 ) {
          if ( FreqMeasure.available()) {
            FreqMeasure.read();
            yy++;
          }
        }

Not sure I saw : "posted edits to two of the FreqCount lib files"?
 
i got in too big a hurry doing editing of post #25 this thread - did some "harmless" editing that i posted and did not compile it (sloppy sloppy)

of the two pgms in post 25 the first pgm (does not do overhead timing) will not compile and needs one line REMOVED:

line 135 et1=etime;
 
Not sure I saw : "posted edits to two of the FreqCount lib files"?

in thread "Teensy 4 FreqCount compile error" one of the posts has a github link
you only have to do minor editing to 2 files in the lib and then T4 under 1.48
will compile FreqCount functions
 
in thread "Teensy 4 FreqCount compile error" one of the posts has a github link
you only have to do minor editing to 2 files in the lib and then T4 under 1.48
will compile FreqCount functions

Oh … remembering that missing .end() code now … Teensy-4-FreqCount-compile-error

I didn't run the p#25 code - was just looking to see how 'delayMicroseconds(40);' was the fix … it is that and then waiting for make two reads. I did wonder what SerMon output for the code timing was though … to compare to the 249us taken by code #2 posted in #26. I gave up on delay and just made it {while not read two} - but that it seems will hang when no freq is present on Read pin #22.
 
Sorry I didn't post yesterday but had a retiree reunion to go to. Not an expert here but going through the freameasure lib yesterday morning and this morning and bouncing against the manual did not see anything that jumped out as an obvious issue. DId some selective prints to check a few things:
  1. counters are all be initialzed to zero when you do a begin
  2. as you said on first cycle the capture may not start at the same time - the code is set to capture at the rising edge of a signal so not sure why it would not.
  3. As @defragster noted - delays not effective.
  4. Did read in the manual about pwm_ext_sync but have to do a lot more experimenting to figure that one.
  5. Yep, freqCount does exhibit the same tendency for the first reading.
  6. In doing a bunch of prints from the ISR (yes I know you should do that). The period_val stays constant after the first reading in the begin (in the section on calculating head-tail).
  7. Not sure that that code block is doing though with the 12 count and head and tail etc but that's me.
  8. Still looking though on and off.
 
Oh … remembering that missing .end() code now … Teensy-4-FreqCount-compile-error

I didn't run the p#25 code - was just looking to see how 'delayMicroseconds(40);' was the fix … it is that and then waiting for make two reads. I did wonder what SerMon output for the code timing was though … to compare to the 249us taken by code #2 posted in #26. I gave up on delay and just made it {while not read two} - but that it seems will hang when no freq is present on Read pin #22.

there is a place early in the code where it watches for a change on the pin - loop label is wtchg or something like that - did not do a timeout on elapsed millis because the radio messages are
often as much as 60 sec apart. but once the change happens and the message has actually started, the real code does have some timeout traps. i have not even tested the no signal
response of the test programs - does not surprise me if it will hang. all of that is out in the test pgm because i wanted as simple as possible just to test cold/warm-start ability to get
"good numbers" right from the get go and/or tweak on it until that was true.
 
Sorry I didn't post yesterday but had a retiree reunion to go to. Not an expert here but going through the freameasure lib yesterday morning and this morning and bouncing against the manual did not see anything that jumped out as an obvious issue. DId some selective prints to check a few things:
  1. counters are all be initialzed to zero when you do a begin
  2. as you said on first cycle the capture may not start at the same time - the code is set to capture at the rising edge of a signal so not sure why it would not.
  3. As @defragster noted - delays not effective.
  4. Did read in the manual about pwm_ext_sync but have to do a lot more experimenting to figure that one.
  5. Yep, freqCount does exhibit the same tendency for the first reading.
  6. In doing a bunch of prints from the ISR (yes I know you should do that). The period_val stays constant after the first reading in the begin (in the section on calculating head-tail).
  7. Not sure that that code block is doing though with the 12 count and head and tail etc but that's me.
  8. Still looking though on and off.

thank you for looking on and off - as i said in a previous post - almost of the library code is way above my pay grade.

the work arounds we have found are good enuf for relatively slow work like fsk over a voice channel,
and i know my app is demanding as far as hit the ground running after a power up or bailout restart.
 
Back
Top