Hi
There is a method in the uTasker project which allows stepper motor sequences to be generated using the FlexTimer/TPM and 2 DMA channels so that ramps for accurate acceleration/displacement/deceleration can be defined and executed very accurately and without any CPU intervention (limit of 64k pulses between at each frequency given by the 16 bit timers).
If I use a KL26 and the reference values in this thread (plus I add 20 pulses at 20kHz at the end to show that 20kHz is also not problem) it looks like this:
To do this, one TPM is used to generate a PWM output. The output is then connected to the TPM_CLKIN pin so that it can be used by a second TPM as clock source. This second TPM counts the output pulses of the first and generates a DMA trigger when it overflows (the number of pulses required at the start). This DMA triggers loading the next number of pulses to be counted and also the next output frequency on the first TPM.
A restriction is that although the frequency of the output can be accurately controlled, it is not always 50% mark-space because the TPM generates a PWM output and not a square wave. For most such controls a pulse edge is what is important (with the accurate period between each edge) but if a 50% mark space ration were needed this could be achieved by using a third DMA channel to program the 50% point (as well as the period). Since 20kHz is the highest frequency I have set 50% MSR for that.
Using the uTasker PWM interface it is easy to configure, as shown below:
First of all a table with the frequencies and pulses at each frequency is defined:
static const unsigned short rampFrequencyValue[] = {
PWM_FREQUENCY(4800, 16), // 4800Hz
(PWM_FREQUENCY(4200, 16) - 1), // 4200Hz
(PWM_FREQUENCY(3200, 16) - 1), // 3200Hz
(PWM_FREQUENCY(1000, 16) - 1), // 1000Hz
(PWM_FREQUENCY(100, 16) - 1), // 100Hz
(PWM_FREQUENCY(800, 16) - 1), // 800Hz
(PWM_FREQUENCY(1800, 16) - 1), // 1800Hz
(PWM_FREQUENCY(20000, 16) - 1), // 20kHz
};
static const unsigned short rampCountValue[] = {
10, // 10 pulses at first frequency
(8 - 1), // 8 pulses at next frequency
(4 - 1),
(2 - 1),
(1 - 1),
(2 - 1),
(6 - 1),
(20 - 1),
0, // end (dummy due to buffer delay)
};The frequencies are specified here using a pre-scaler of 16 and the -1 is due to the PWM comparison operation.
Then the two TPMs are configured to control the sequence via DMA and to start it.
PWM_INTERRUPT_SETUP pwm_setup;
pwm_setup.int_type = PWM_INTERRUPT;
// Configure DMA trigger generator (PTB16 is clock input)
//
pwm_setup.pwm_mode = (PWM_EXTERNAL_CLK | PWM_PRESCALER_0 | PWM_NO_OUTPUT | PWM_FULL_BUFFER_DMA | PWM_DMA_PERIOD_ENABLE | PWM_DMA_CONTROL_FREQUENCY); // clock PWM timer from external clock
pwm_setup.pwm_reference = (_TIMER_1 | 0); // timer module 1, channel 0
pwm_setup.pwm_frequency = rampCountValue[0]; // set the input pulse count value until overflow
pwm_setup.pwm_value = pwm_setup.pwm_frequency;
pwm_setup.ucDmaChannel = 2; // use DMA channel 2
pwm_setup.dma_int_priority = 0;
pwm_setup.ucDmaTriggerSource = DMAMUX0_CHCFG_SOURCE_TPM1_OVERFLOW; // load next value on own timer overflow
pwm_setup.ptrPWM_Buffer = (unsigned short *)&rampCountValue[2]; // buffer controlling the DMA trigger points
pwm_setup.ulPWM_buffer_length = (sizeof(rampCountValue) - sizeof(unsigned short));
pwm_setup.dma_int_handler = fnEndOfRamp; // call back on DMA termination
fnConfigureInterrupt((void *)&pwm_setup); // enter configuration for DMA trigger generation
FTM1_MOD = rampCountValue[1];
// Configure PWM output signal (FRDM_KL26 PTE29 which is fed back to PTB16)
//
pwm_setup.pwm_mode = (PWM_SYS_CLK | PWM_PRESCALER_16 | PWM_FULL_BUFFER_DMA | PWM_DMA_PERIOD_ENABLE | PWM_DMA_CONTROL_FREQUENCY);
pwm_setup.pwm_reference = (_TIMER_0 | 2); // timer module 0, channel 2 (red LED in RGB LED)
pwm_setup.pwm_frequency = rampFrequencyValue[0]; // set start frequency
pwm_setup.pwm_value = _PWM_PERCENT(50, PWM_FREQUENCY(20000, 16)); // 50% PWM (high/low) when the frequency is 20kHz
pwm_setup.ucDmaChannel = 1; // use DMA channel 1
pwm_setup.ptrPWM_Buffer = (unsigned short *)&rampFrequencyValue[1]; // buffer controlling the frequencies
pwm_setup.ulPWM_buffer_length = (sizeof(rampFrequencyValue) - sizeof(unsigned short));
pwm_setup.dma_int_handler = 0; // no callback on DMA termination
fnConfigureInterrupt((void *)&pwm_setup); // configure and start the PWM output
As can be seen, TPM1-CH0 is used to control the DMA triggers, using DMA channel 2 for its count value updates. TPM0-CH2 is used to generate an output signal, using DMA channel 1 for its frequency updates. Both DMA channels are triggered by the overflow of TPM1 (the pulse count match).
When the sequence has completed there is an (optional) interrupt called back from the DMA driver which can be used to start further such sequences or to stop the PWM output. For example:
static void fnEndOfRamp(void)
{
FTM0_SC = 0; // stop the PWM output when the sequence has completed
}
Unfortunately this is not 100% compatible with devices with FlexTimer rather than TPM. The reason being that that they don't offer the capability of triggering the DMA on the timer overflow. Instead, the trigger has to be performed on an individual channel match instead, which means that ramp counts value are accumulated, and so looks like this instead.
static const unsigned short rampCountValue[] = {
10, // 10 pulses at first frequency
(18 - 1), // 8 pulses at next frequency
(22 - 1),
(24 - 1),
(25 - 1),
(27 - 1),
(33 - 1),
(53 - 1),
0, // end (dummy due to buffer delay)
};Rather than specifying the overflow interrupt with PWM_DMA_PERIOD_ENABLE, PWM_DMA_CHANNEL_ENABLE needs to be used.
And rather than pwm_setup.ucDmaTriggerSource = DMAMUX0_CHCFG_SOURCE_TPM1_OVERFLOW; pwm_setup.ucDmaTriggerSource = DMAMUX_CHCFG_SOURCE_FTM0_C0 would be used....
Regards
Mark
Professional support for Kinetis: http://www.utasker.com/index.html
Remote desktop one-on-one coaching: http://www.utasker.com/services.html
Getting started to expert videos: https://www.youtube.com/results?search_query=utasker+shorts
Hi
I checked on a FRDM-K66F board and can confirm that the operation is the same as long as I use a TPM as DMA trigger source. Also I tried generating a square wave rather than fixed MSR PWM and this looks also good:
The only thing is that I need to double the frequencies in the table when I use this because the output is "toggled" on each timer overflow rather than a "period" being generated (effectively halves the frequency of the output).
The only changes to the code are:
pwm_setup.pwm_reference = (_TPM_TIMER_2 | 0); // TPM module 2, channel 0
This is to use a TPM instead of FTM to monitor the frequency output so that a DMA trigger can be used on its timer overflow.
pwm_setup.ucDmaTriggerSource = DMAMUX0_CHCFG_SOURCE_TPM2_OVERFLOW; // load next value on own timer overflow
This is the new DMA trigger (from different TPM).
I still used a FTM for the actual output generation (although a TPM can be used by just specifying it rather than a TPM)
There is one thing that worries though and that is the fact that the user's manuals state that no two DMA MUX should be configured to have the same DMA trigger source. Here I use the same for two DMA channels and the operation is OK.
To avoid risks I would recommend that a second TPU (if still free) be set up exactly the same way as the first so that it also generates a DMA trigger at the same time as the first.
One of the triggers could then use the second TPM as its trigger rather than sharing the trigger with the other TPM. This would be:
pwm_setup.ucDmaTriggerSource = DMAMUX0_CHCFG_SOURCE_TPM1_OVERFLOW;
Unfortunately I couldn't confirm the operation with purely Flex Timers - the difficulty with these is the missing overflow DMA trigger source and so a CV register has to be modified (by DMA transfer from the count table) rather than a MOD register. The MOD register works well because it is updated (synchronously) each time it overflows. The writes to the CV register take place but they are only applied/synchonised when the MOD overflows as well. I was under the impression that in the output toggle mode the new value would be loaded on the next clock but this didn't prove to be the case and the delay for it to take place is not acceptable for such an application. As long as there are two (maybe 1 if the advise in the user's manual is ignored and doesn't turn out to be a real issue) free TPMs available I see no problem with using the technique to generate such patterns without CPU overhead (or interrupt jitter, etc.) on parts with TPM, or FTM + TPM (like the K66).
Regards
Mark
