How to achieve max. accuracy for static timing event

[florianaugustin9]

Posted on November 17, 2013 at 00:24

Hello :)

I want a timer to execute ISR all 4 ms but for academic reasons (interest) I want it as accurate as possible. So I chose TIM_Prescaler = 0 and TIM_ClockDivision = 0.

Is there anything else that could increase accuracy? Here's the code: 

  /* Timer2 (250 Hz) initialization */

  RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE);

  /* Prescaler of 1 */

  TIM_TimeBaseStructure.TIM_Prescaler = 0;

  /* To get 250ms */

  TIM_TimeBaseStructure.TIM_Period = 0x52080;

  /* No preprescaler */

  TIM_TimeBaseStructure.TIM_ClockDivision = 0;

  TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up;

  TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure);

  /* Timer2 IRQ */

  NVIC_InitStructure.NVIC_IRQChannel = TIM2_IRQn;

  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;

  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 2;

  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;

  NVIC_Init(&NVIC_InitStructure);

  TIM_ITConfig(TIM2, TIM_IT_Update, ENABLE);

  /* Timer2 enable counter */

  TIM_Cmd(TIM2, ENABLE);

void TIM2_IRQHandler(void)

{

    TIM_ClearITPendingBit(TIM2, TIM_IT_Update);

   ...

}

Thank you!!

[Tesla DeLorean]

Posted on November 17, 2013 at 00:39

The Prescaler of zero buys you no accuracy, but will limit you to 32-bit timers.

Remember the Prescaler and Period are N-1 values, so (336000 - 1) is needed in your case.

[Danish1]

Posted on November 17, 2013 at 14:19

''For academic reasons'' you want to make the timing of the event as accurate as possble.

As this is academic rather than practical, it is worth mentioning some of the things that might reduce the accuracy:

1) Your clock source. If your processor is running from the internal HS oscillator then you'll only get 1% or thereabouts.

An external crystal is much better, typically 20ppm for a well-designed system.

But you can do better with a dedicated clock module (perhaps approaching 1 ppm), and if you choose one that is intended for a cellular telephone than it can be relatively cheap.

2) Interrupt latency.

The processor is unable to service interrupts if it is handling a higher-priority interrupt (so make your timing-critical one the highest priority), or you have disabled interrupts for any other reason (your OS might do this momentarily for things like mutexes).

3) Context Switch. There is a delay while the processor saves its current state onto the stack. For a one-off delay you need to allow for the time this takes (whereas for a repeating event often only the interval between successive events is important). As processors get more complicated, there is more and more to save on the stack. The stm32f4 might have to save the state of its floating-point unit while a simpler stm32f2 does not have one to save. The stm32f4 tries to be clever to decide if the floating-point unit's state does need saving, but if on some interrupts it does need saving but not on others than you will get a _difference_ in delay for those two situations. Some 8-bit micros are much more predictable here, as is dedicated hardware.

Some of this can be mitigated by the specific code for this function, but other aspects can only be improved by overall system design.

Hope this helps,

Danish

[emalund]

Posted on November 17, 2013 at 15:28

In the hope that your interest is not purely acaddemic (I can count the crap I have seen by academics) there is a few thingas about delays worth mentioning

in embedded apps it is extremely rare (I know of none) where a delay need be precise it need be minimum = x

setting a delay ISR to highest priority to avois other events extending the dely would be sheer folly

conclusion: in practical as opposed to academic applications it is impossible to have a precise delay so why on earth would an academic fool around with figuring it out since it has no PRACTICAL application.

Erik

[florianaugustin9]

Posted on November 17, 2013 at 21:40

I want to thank you for the answers! Especially Danish for spending time on the detailed answer. I'm a student and yes of course for my application this doesn't matter, but for me it's not about beeing very productive but to learn as much as possible doing my projects. I'm not very familiar with Cortex-M4 architecture and therefore I asked this :)

The thing with context switches is something I had in mind but I didn't realize that larger controllers are more affected by this. 

In some PowerPc Controllers there is a dedicted Timer Unit that can do a lot of things without causing any Interrupt and with very predicable timing behaviour based on a hardware scheduler doing a very fair scheduling. so I'm of the optinion that for my purposes this is academic but it seems that for some application the timing has to be very precise otherwise there wouldn'texist such solutions. Also I think the amout of Interrupts is something to have in mind.

Can I influence what registers the compiler saves on the stack doing a context switch or is this automatically done?

Best regards,

Florian

[emalund]

Posted on November 17, 2013 at 23:39

<i> it's not about beeing very productive</i>

you are up for a rude awakening if you ever get a job

 

<i>The thing with context switches is something I had in mind </i>

OK, so you get a very precise context timing, and (randomly, you can not control it) various ISR execute.  Now where is your ''precise context timing'

Erik

[florianaugustin9]

Posted on November 18, 2013 at 00:10

I don't see the point why I have to be productive doing my projects at home.

At work I have to be productive, thats right, but not for projects doing only for my own.. In this case it doesn't matter if I'm a student or not. Now I have the time to play around and try to understand the background of µC. 

I think worst case scenarios are always important and it doesn't make any difference if the ISR is called by a timer or by anything else. As the case may be that some actuator is controlled some delay could matter. And it was okay to ask because Danish's text is worth reading!

Best regards,

Florian