Duration of timer's IRQHandler with PWM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2015-10-26 8:29 AM
I'm using STM32F303 Discovery board.
I try to evaluate how much code can be performed intimer's IRQHandler without causing desynchronization with PWM of the same timer.//interrupt code
if (TIM_GetITStatus(TIMX.name, TIM_IT_Update) != RESET)
{
TIM_ClearITPendingBit(TIMX.name, TIM_IT_Update);
GPIO_SetBits(GPIOE, GPIO_Pin_0);
for(aaa=0;aaa<6;aaa++)
__nop();
GPIO_ResetBits(PIOE, GPIO_Pin_0);
}
//some init strings
//---
base_timer.TIM_Prescaler = 8
base_timer.TIM_Period = 20;
base_timer.TIM_ClockDivision = 0;
base_timer.TIM_CounterMode = TIM_CounterMode_Up;
//---
oc_init.TIM_OCMode = TIM_OCMode_PWM1;
oc_init.TIM_OutputState = TIM_OutputState_Enable;
oc_init.TIM_Pulse = 10;
oc_init.TIM_OCPolarity = TIM_OCPolarity_High;
oc_init.TIM_OCNPolarity = TIM_OCNPolarity_High;
oc_init.TIM_OCIdleState = TIM_OCNIdleState_Set;
oc_init.TIM_OCNIdleState = TIM_OCNIdleState_Set;
So due to toggling pin inside IRQHandler i saw necessity that time of code performing was less then half of PWM duty cycle.
I also try to use CCR2 interrupt but situation is the same.
Can somebody explain the reason of such behavior? And maybe it's real somehowachievepossibility to use full time of PWM duty cycle fortimer's IRQHandler?
Thank you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2015-10-26 8:33 AM
I'm not sure what you're describing. How much time you spend in the handler would seem irrelevant to whether the timer ticks, and generates a pwm signal. Your GPIO is another matter, and is going to get butchered once you saturate the processor.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2015-10-26 9:09 AM
Thank you, Clive for so fast reply. Try to clarify my problem.
It's success situation when IRQHandler execution is less than half of PWM duty cycle. As you see software toggling of GPIO in IRQHandler (blue signal) follows toggling of PWM (yellow line) equidistantly (at the same time interval).desynchronization
of my software toggling with PWM toggling. I expected saw it in case when IRQHandler execution time is close to PWM duty cycle but not it half.So what the reason of such behavior? And it's possible to chanhe it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2015-10-26 9:28 AM
The processor gets to your IRQHandler when it can, at saturation it is going to directly tail-chain at exit back into the same IRQHandler. The latency is going to depend on how much time/cycles you are sucking up, it is not going to preempt itself. Just prior to saturation it will exit, pop context, and then very soon push context, and come back in. Seem to think that might eat 24 cycles. Joseph Yiu's book probably has a chart.
The system is going to saturate with interrupts at several 100 KHz. Write your handlers more optimally? Doesn't the F3 want you to use CCM RAM? The Flash is very SLOW.Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2015-10-26 9:42 AM
Does your system have other interrupts running of equivalent period and priority?
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2015-10-27 2:25 AM
I understood it but as i said I expected saw that in case when IRQHandler execution time is close to PWM duty cycle but not it half. I have project with clear main loop and one interrupt for timer's update.
I try to change PWMpulse and understood that i was wrong with moment which corresponds to interrupt handler.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2015-10-27 4:03 AM
Once the interrupt happens, the processor needs to save many registers onto the stack to be able to safely execute your interrupt routine. Even when the memory can be accessed in one cycle, that may take some time.
It is entirely possible that there is some more processing going on beyond your interrupt handler. I recently had some trouble with an interrupt taking about 8 microseconds beyond my ''toggle the IO pin'' inside my handler......- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2015-10-27 5:56 AM
You'd have to look at the code generated by the compiler, the calls, and the optimization settings.
You've presented a very narrow view of what you're doing with a selective cut-n-paste rather than present something that can be reviewed and compiled. Figure every word from FLASH takes 4 cycles to fetch, vs 1 from SRAM, when computing cycles for assembler code emitted. You can burn 50-100 cycles pretty quickly and achieve very little.Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2015-10-27 6:17 AM
[deleted, please ignore]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2015-10-27 8:07 AM
That's all code without init part.
void TIM3_IRQHandler(void)
{
if (TIM_GetITStatus(TIMX.name, TIM_IT_Update) != RESET)
{
TIM_ClearITPendingBit(TIMX.name, TIM_IT_Update);
GPIO_SetBits(GPIOE, GPIO_Pin_0);
for(aaa=0;aaa<6;aaa++)
__nop();
GPIO_ResetBits(GPIOE, GPIO_Pin_0);
}
}
//-------------------------------------
int main(void)
{
int i;
HWinit();
TIM_ITConfig(TIMX.name, TIM_IT_Update, ENABLE);
TIM_CtrlPWMOutputs(TIMX.name,ENABLE);
TIM_Cmd(TIMX.name, ENABLE);
while(1)
{
}
}
So as i understood there is aconsiderable latency between event causing interrupt and its handler. But in this case how to work on frequencies about few MHz?
It's interesting info about CCM RAM, will read about it for sure. But how it can be implemented in this case?
