Hello Daniel,
Indeed, as Mark said, the maximum interrupt rate that the device can handle is about 500kHz (interrupts take about 2us at 50MHz).
This is because the Interrupt Latency.
The term interrupt latency refers to the number of clock cycles required for a processor to respond to an interrupt request, this is typically a measure based on the number of clock cycles between the assertion of the interrupt request up to the cycle where the first instruction of the interrupt handler exected.
Ideally, the interrupt latency should be low.
The interrupt latency of the ARM Cortex M4 is, in the best case, 12.
In addition, as in any program code, the ISRs take time to execute.
In the case of your application and using Processor Expert, the ISR takes about 80 clock cycles to execute it and I takes about 10 to Return Latency.
In conclusion, if we add all the clock cycles that requires to execute an interrupt, we have 102 clock cycles that means:
1 clock cycle -> 20 ns
102 clock cycle -> 2.040 us
Hope this information will be useful for you.
Have a great day. :smileyhappy:
Best Regards,
David Diaz.
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Daniel
1MHz is too fast for the K20D50 - the maximum interrupt rate that it can handle is about 500kHz (interrupts take about 2us at 50MHz).
However 250kHz and 50kHz interrupts on two flex timers is not a problem:
Here I have measured two FlexTimer interrupts toggling the LEDs on the board at 50kHz and 250kHz rates. The 50kHz toggle is very stable but the faster one has some jitter.
The binary is attached.
The third LED is togged at 2.5Hz by a software timer and the UART on the OpenSDA virtual COM connection is fully operational at the same time.
I don't know if or why the PE configuration may have problems with specific speeds but you can compare the register setups to maybe see something.
I set up the FlexTimers in the uTasker framework as follows:
TIMER_INTERRUPT_SETUP timer_setup; // interrupt configuration parameters
_CONFIG_PORT_OUTPUT_FAST_LOW(A, PORTA_BIT2, (PORT_SRE_FAST | PORT_DSE_LOW)); // configure port outputs (LEDs)
_CONFIG_PORT_OUTPUT_FAST_LOW(C, PORTC_BIT3, (PORT_SRE_FAST | PORT_DSE_LOW));
timer_setup.int_type = TIMER_INTERRUPT;
timer_setup.int_priority = PRIORITY_TIMERS;
timer_setup.int_handler = timer_int; // interrupt handler
timer_setup.timer_reference = 0; // FlexTimer 0
timer_setup.timer_mode = (TIMER_PERIODIC); // period timer interrupt
timer_setup.timer_value = TIMER_US_DELAY(20); // 20us periodic interrupt
fnConfigureInterrupt((void *)&timer_setup); // configure for first timer
timer_setup.timer_reference = 1; // FlexTimer 1
timer_setup.int_handler = timer_int_1M; // interrupt handler
timer_setup.timer_value = TIMER_US_DELAY(4); // 4us periodic interrupt
fnConfigureInterrupt((void *)&timer_setup); // configure for secondtimer
The interrupt handlers do:
static void timer_int(void)
{
_TOGGLE_PORT(C, PORTC_BIT3);
}
static void timer_int_1M(void)
{
_TOGGLE_PORT(A, PORTA_BIT2);
}
Note however that generally a timer will not be used to perform such a function because it is much easier and more accurate to configure a PWM output on the FlexTimer to generate a high precision output without any interrupt overhead.
Regards
Mark
Kinetis: µTasker Kinetis support
K20: µTasker Kinetis TWR-K20D72M support / µTasker Kinetis FRDM-K20D50M support / µTasker Kinetis TWR-K20D50M support / µTasker Kinetis support
Hardware Timers: http://www.utasker.com/docs/uTasker/uTaskerHWTimers.PDF
For the complete "out-of-the-box" Kinetis experience and faster time to market
