Forum Rule: Always post complete source code & details to reproduce any issue!
Page 15 of 15 FirstFirst ... 5 13 14 15
Results 351 to 355 of 355

Thread: TeensyTimerTool

  1. #351
    Quote Originally Posted by luni View Post
    It is supposed to do the second.

    However, as joepasquariello mentioned, those functions are currently not implemented for the FTM timers. As a first fix I implemented the setNextPeriod() function which changes the next period after you call it. Implementing setPeriod() (i.e. hard stop the current timer and restart with a new period) is kind of difficult since all FTM Channels of one module use the same underlying counter. I'll see if I can work around this on the weekend.

    You can find the new code in the "fixFTM" Branch on the gitHub repo.
    @luni, it looks to me like the new setPeriod() in your fixFTM branch will do what you want. Because you have FTMEN=0 in the FTMx_MODE registers, and you are using output compare, writes to the CV registers take effect on the next FTM clock, so they "override" the current period. The code in start() does the right thing, i.e. add the new period (in clocks) to the current value of the FTM clock CNT.

    Code:
        errorCode FTM_Channel::start()
        {
            ci->chRegs->CV = regs->CNT + ci->reload;     // compare value (current counter + pReload)
            ci->chRegs->SC &= ~FTM_CSC_CHF;              // reset timer flag
            ci->chRegs->SC = FTM_CSC_MSA | FTM_CSC_CHIE; // enable interrupts
            return errorCode::OK;
        }
    
        errorCode FTM_Channel::stop()
        {
            ci->chRegs->SC &= ~FTM_CSC_CHIE; // enable interrupts
            ci->chRegs->SC &= ~FTM_CSC_CHF;  // reset timer flag
    
            return errorCode::OK;
        }
    
        // errorCode FTM_Channel::setPeriod(float us)
        // {
        //     stop();
        //     ci->reload = ticksFromMicros(us);
        //     start();
        //     return errorCode::OK;
        // }
    
        errorCode FTM_Channel::setNextPeriod(float us)
        {
            ci->reload = ticksFromMicros(us);
            return errorCode::OK;
        }

  2. #352
    Junior Member
    Join Date
    Aug 2022
    Posts
    5
    Hi luni,

    thanks for the follow up, I see the fixFTM branch and the new commit you pushed up to the repository. I noticed this commented-out block:

    Code:
        errorCode FTM_Channel::setPeriod(float us)
        {
            stop();
            ci->reload = ticksFromMicros(us);
            start();
            return errorCode::OK;
        }
    This looks like it has the functionality I want (going back to my original desire, to ensure that the period of the purple trace starts perfectly aligned with the pulse shown in the yellow trace)

    Previously, I was calling stop() and then start() again, but I realized that this just temporarily pauses the timer and then un-pauses it again (which is not what I wanted).

  3. #353
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,892
    This looks like it has the functionality I want (going back to my original desire, to ensure that the period of the purple trace starts perfectly aligned with the pulse shown in the yellow trace)
    As mentioned above, the setPeriod functionality does not seem to work as intended (at least during my very first tests it didn't stop the period but did the same as SetNextPeriod()). I'll have a closer look on this and Joe's results on the weekend. Anyway, feel free to uncomment and see if it will work for your needs.

    Can you elaborate a bit what you want to achieve in the end? Looks like you have got some external 1Hz signal and you want to sync a 10Hz signal to it? If so, I'd rather let an IntervalTimer running and use the external signal to finetune the frequency of it. I.e., something like this (modulo details):
    • Use the timer callback to save a current timestamp (e.g. using the cycle counter)
    • Use the pinInterrupt callback to calculate the time difference to the last timestamp.
    • Use this difference to adjust the Intervaltimer period on the fly. Maybe a simple PID would help to adjust the period.

  4. #354
    Junior Member
    Join Date
    Aug 2022
    Posts
    5
    Quote Originally Posted by luni View Post
    • Use the timer callback to save a current timestamp (e.g. using the cycle counter)
    • Use the pinInterrupt callback to calculate the time difference to the last timestamp.
    • Use this difference to adjust the Intervaltimer period on the fly. Maybe a simple PID would help to adjust the period.
    Hi luni, this is an interesting idea, yeah a PID would be one way to achieve this, thank you!

  5. #355
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,892
    I just published a new release of the TeensyTimerTool (v1.0.1) .

    Two main changes:
    • To be compatible with the new toolchain (1.58beta) I needed to remove the capability to enter timer periods in frequency units (e.g. 12.3_kHz etc). Since this was a wild hack anyway I'm not too sorry. Hope that nobody used this feature in production code. The usual time based units (e.g. 42ms, 145.5us, 800ns etc) still work of course.
    • I changed the underlying callback system from std::function (quite heavy) to my new staticFunctional library. staticFunctional has a much smaller memory footprint and doesn't use any dynamic memory. Ideally, library users should not note any difference.
      Please note: The new system is only active if you use the new 1.58beta toolchain (GCC version >= v7). Using the old toolchain (GCC v5.4) the TimerTool will fall back to function based void(*callback)() callbacks automatically.


    Please let me know if you find any incompatibilities or other bugs

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •