This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Would calculation affect timer

I am using a power profiler to measure the timing of my program and I found something wrong. So I tested with a simple pure timer.

So first I set the timer during to 300ms

#define half_epoch_during		APP_TIMER_TICKS(300)
err_code = app_timer_create(&half_epoch_timer, APP_TIMER_MODE_SINGLE_SHOT, half_epoch_timer_handler);
err_code=app_timer_start(half_epoch_timer,half_epoch_during,NULL);

And I did nothing in the callback function

static void half_epoch_timer_handler (void * p_context)
{}

The timing is all right. I measure a periodic change in current every 300ms. Then I add a for loop to simulate calculations in the callback function.

static void half_epoch_timer_handler (void * p_context)
{
	int d;
	for (int i =0; i<3000000; i++)
	{	
		d = i;
	}
}

And now, the timing is wrong. I can measure a current change every 240ms. So my question is why would calculation make the timer shorter?

ps: My board is nRF52840 PDK.

Parents
  • Without digging into this a lot, just looking at the fact that the app timer interrupts every 1msec means that there is quite a bit of code running already. I assume the timer handler probably reloads the timer, updates some local variables, etc.

    Then you have your for loop running. Every time that kicks in the processor has to create the local variable, load it with 3 million, then theoretically it could do the count directly in the processor registers but I would guess it actually involves a few opcodes to carry out the task. I would guess this total thing could involve 6million or more opcodes (ie, instructions) to complete.

    And, then both of these are ISR's so every time the processor shoves its registers to the stack, updates the pc, etc. etc. Anyway the point is a processor that carries out 64mips is really working when you ask it to carry out several million instructions in 300msec.

Reply
  • Without digging into this a lot, just looking at the fact that the app timer interrupts every 1msec means that there is quite a bit of code running already. I assume the timer handler probably reloads the timer, updates some local variables, etc.

    Then you have your for loop running. Every time that kicks in the processor has to create the local variable, load it with 3 million, then theoretically it could do the count directly in the processor registers but I would guess it actually involves a few opcodes to carry out the task. I would guess this total thing could involve 6million or more opcodes (ie, instructions) to complete.

    And, then both of these are ISR's so every time the processor shoves its registers to the stack, updates the pc, etc. etc. Anyway the point is a processor that carries out 64mips is really working when you ask it to carry out several million instructions in 300msec.

Children
No Data
Related