Posted on April 14, 2013 at 15:31 Clive, thank you for your answer.
Yes, it is true, that IRQ routines write output to the serial (and it is maybe time consuming) - but this is what I need...
Also the sprintf function can be time-consuming.
Here is my IRQ routine code snippet:
void TIM1_CC_IRQHandler(void)
{
char buffer[10];
RCC_ClocksTypeDef RCC_Clocks;
RCC_GetClocksFreq(&RCC_Clocks);
/* Clear TIM1 Capture compare interrupt pending bit */
TIM_ClearITPendingBit(TIM1, TIM_IT_CC2);
/* Get the Input Capture value */
IC2ValueT1 = TIM_GetCapture2(TIM1);
if (IC2ValueT1 != 0)
{
DutyCycle = (TIM_GetCapture1(TIM1) * 100) / IC2ValueT1;
distance = DutyCycle;
sprintf(buffer, ''%f'', distance);
//write the results to console
USART_puts(USART1, ''SENSOR 1 - DUTY CYCLE: '');
USART_puts(USART1, buffer);
USART_puts(USART1, ''\r\n'');
}
else
{
DutyCycle = 0;
}
}
An IRQ routine for the second timer is same...
What is the worst, the need is to capture 6 PWM signals (I planned using other channels of those two timmers within the same two IRQ routines) and still get informations from the accelerometer and do some computings with all of those values...
And that's not all...
There are another 2 timers running, each with 2 channels engaged - for 2 servos and 2 motors PWM controll signal generation...but they don't use IRQ routines.
I hope it doesn't means that I'll have to use separate CPU for each couple of sensors and one for final computation
🙂 Maybe the solution could be to stop all timers with IRQ routine when executing one of them and in the end of the while cycle (in the main function) start them again...
Another solution should be (possibly) to take into account the IRQ priority but I am not experienced with this...
Any idea how to solve this problem?
Thank you once more for your help.
