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.

  • 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.

  • But this brings us back to why is it shorter??? hmmm.

    Why not just have the thing keep time while it runs the for loop stuff and see if it still can keep time? I would guess something is just weird the way the power profiler is looking at the data. Maybe it is looking at the dwell time instead of the on time.

  • Oh, and I forgot to mention since the app timer interrupts every msec that means that since your count takes about 6/64 of a second or at the very least 3/64 of a second that means your for loop will be interrupted and shoved to the stack at least 46 times just so the app timer can run and service its ISR.

  • Yes. The problem is I am not even sure which timing is right. Is the power profiler somehow compress the X axis. Or Something running on the board would make the timer wrong.

    The truth is my job was using BLE stack to scan periodically. So I set a timer to start the scan every time. So the callback function is just invoking the scan_start() function which is not a lot of opcodes. But the compression of time shows the same pattern as a FOR loop.

  • No, my timer interrupts every 300 ms

Related