How can you make code run faster? Analysing micro-performance with the nRF52

RE: How can you make code run faster? Analysing micro-performance with the nRF52

EAB — Wed, 14 Jun 2023 08:47:54 GMT

Very Nice! [emoticon:9b06bfad0e6a482e801e5eb8fd9025d6]
Surprised you haven't gotten more upvotes.

RE: How can you make code run faster? Analysing micro-performance with the nRF52

Andrzej Kuros — Mon, 24 Apr 2017 05:36:43 GMT

is the cpu cache turned on by default when using nRF SDK 13 with softdevice s132?

RE: How can you make code run faster? Analysing micro-performance with the nRF52

butch — Thu, 16 Feb 2017 19:22:30 GMT

#include "nrf.h"

#ifdef NRF52
    NRF_NVMC->ICACHECNF=0x01;
#endif

RE: How can you make code run faster? Analysing micro-performance with the nRF52

David García Polo — Wed, 19 Oct 2016 07:48:08 GMT

"Turning the CPU cache on (NVIC->ICACHECNF=0x01) is wrong."

Should be "Turning the CPU cache on (NVMC->ICACHECNF=0x01)

Is there a button to edit a blog post?

RE: How can you make code run faster? Analysing micro-performance with the nRF52

Susheel Nuguru — Thu, 15 Sep 2016 12:05:12 GMT

Oh yes, I remember that you told me you wrote this in pure assembly. I was thinking that this might be collision in bus trying to access same slave (could happen because of piplelining). I agree that there is a possibility like you say that this could be because of the switching.

Move data and code to two different blocks (RAM slaves) and access them with two different buses (code with ICODE and data with DCODE).This should eliminate collision if it did not improve.

Move data and code to same block and access them using ICODE. This it should have been switching between busses.

PS: Sorry for too many edits, there is no "minor edit" checkbox here in blogs.

RE: How can you make code run faster? Analysing micro-performance with the nRF52

RK — Thu, 15 Sep 2016 11:47:50 GMT

Thanks Aryan, do you mean stack pointer or do you mean data pointer, because the stack, apart from the start/end of the routine, isn't used? My guess was it was the data read (in the 0x20000000 block) vs the code read (in the 0x800000) block which was causing the stall because the bus had to switch between both blocks. Definitely however I could adjust the data pointer (and the lookup table pointers) so they are in the same block as the code, just need to subtract the fixed offset from both.

Perhaps I'll give that a try over the weekend.

RE: How can you make code run faster? Analysing micro-performance with the nRF52

Susheel Nuguru — Thu, 15 Sep 2016 11:38:10 GMT

Hi RK,

Very nice article and very good experiment. You wrote

However, when the code is in CODERAM (0x800000) for some reason there's an extra load stall, which I cannot explain.

Running your code from CODERAM should not have affected the LSU part. I think that your stack pointer is pointing to the same RAM block in which your code resides. So when you are running code in CODERAM then there could be collisions because now we are accessing the same slave RAM block with two different busses. The collision could result in extra wait cycles. If you do this experiment with stack pointer pointing to some other RAM block than we should see the wait cycles for LSU should atleast be same for both.

RE: How can you make code run faster? Analysing micro-performance with the nRF52

Wojtek — Mon, 12 Sep 2016 12:46:27 GMT

Thank you for that post, didn't know about those DWT features. really nice analysis!