Would calculation affect timer

RE: Would calculation affect timer

mich_x — Sun, 17 Dec 2017 20:51:16 GMT

Thank you all very much for all the help and patience. Turns out, the reason is that I did not wait for some time after I turned off the trigger window. I found that it takes about 10 seconds for the plot actually take effect after I click stop on the trigger window. And after I turned off and waited this time, everything is fine.

RE: Would calculation affect timer

MartinBL — Thu, 14 Dec 2017 09:59:35 GMT

One more thing; as is explained here, it is advised to turn off the Trigger window in the PPK software when looking at timings. After I did that I saw the timer interrupt spikes occurring at exactly 300ms intervals.

RE: Would calculation affect timer

MartinBL — Thu, 14 Dec 2017 09:49:44 GMT

I have tested with PCA10056 running the app_ble_template example and S140 v5.0.0-2.alpha and I'm still not able to reproduce this. With a logic analyzer I can still see that the interrupt triggers at 300ms intervals. With the PPK though, I do see some variations in the order of 10-20ms. However, I talked to the PPK HW guy, and he told me that this is to be expected because the time axis in the PPK software is not that accurate. Especially if you are running the software on Windows 10.

RE: Would calculation affect timer

mich_x — Tue, 12 Dec 2017 18:35:58 GMT

No, I have not got time to work on this. Did you add Softdevice when you run the test? I think I have to run the test on top of the S14.

RE: Would calculation affect timer

MartinBL — Tue, 12 Dec 2017 09:41:15 GMT

Hi @mich_x. Did you solve the issue? If not, can you post a screenshot of your current measurements? I did a quick test with a logic analyzer and the timer handler seems to be called at ~300ms with or without your calculations inside it.

RE: Would calculation affect timer

AmbystomaLabs — Mon, 04 Dec 2017 19:43:36 GMT

Or so you don't have to interface to the device, just have it toggle a gpio and then you can measure the rate with an o-scope. I would assume you will see some jitter in the basic timing since the ble stack has highest interrupt priority but the basic rate should still be 300msec.

RE: Would calculation affect timer

AmbystomaLabs — Mon, 04 Dec 2017 19:28:16 GMT

You are correct. You are defining the tick rate.

On the for loop, I think it is minimum 6million opcodes since you force it to write i to d. Or about 93 msec to execute.

It is an interesting problem. Still I would probably choose to let it keep track of time and see if it does that correctly while running the for loop.

RE: Would calculation affect timer

mich_x — Mon, 04 Dec 2017 18:53:18 GMT

No, my timer interrupts every 300 ms

RE: Would calculation affect timer

mich_x — Mon, 04 Dec 2017 18:52:12 GMT

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.

RE: Would calculation affect timer

AmbystomaLabs — Mon, 04 Dec 2017 18:46:02 GMT

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.

RE: Would calculation affect timer

AmbystomaLabs — Mon, 04 Dec 2017 18:42:16 GMT

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.

RE: Would calculation affect timer

AmbystomaLabs — Mon, 04 Dec 2017 18:39:51 GMT

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.