joepasquariello
Well-known member
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;
}