profiling on a nrf51422

[Torsten Robitzki]

Hi, have some of you expierence with profiling on a nrf51422? I think what would be nessesary, is at least one high priority timer, to sample the program counter, some kind of channel to get the data out of the µcontroller (ant for example) and something analyse the data off target, like google perftools. In addition it would be very helpfull to get the top of the callstack (just the function backtrace) for analysis of the cumulative cpu usage of some functions.

I wonder if it would be doable in conjuction with a softdevice. Especialy the high priority timer part of idea.

cheers, Torsten

[Nenik]

When I needed to optimize some of my code, I did two things:

1. Selected 2 GPIOs for LEDs, toggled the LEDs at key milestones of the code. One line was kind of synchronization (start of the repeated computation), the other was progress. I have then used scope to analyze the time spent in individual parts.
   
2. I wrote a "test suite" for unit testing that also does timing. Basically, I type "make test" and it rebuilds the "test-main.c" against all other sources, flashes it to the device (where it runs all the tests and stores the results in a binary log), waits some time, pull back the memory with the binary log and parse the log. This not only helped me tremendously when implementing complex computations, but it also allowed me to record the timing of the building blocks of those computations.

[Torsten Robitzki]

Hi Nenik, I didn't understood how you use the LEDs. Some kind of pulse width modulation and the brightness of the LEDs give you an impression on the performance?

[Nenik]

The LEDs were just to have visual feedback (when the outer testing loop was in hundreds of ms). The LEDs are optional, I have used the oscilloscope to actually measure the time of individual "milestones" in the code flow. Trigger the scope (channel 1) on the the synchronization pulse (generated at the start of the code you profile), watch the toggles on the channel 2, use the scope cursor to measure the time.

You can adapt that approach to different situations. For the sake of example, imagine you'd need to sort a list. You'd toggle ch1 on start/end of sort (so the total sort time would be width of ch1 pulse), then e.g. toggle ch2 around your comparison function. Under this arrangement, you'd see: How many times the comparison run, how much time it spent in each comparison, and what was the overall proportion of other code vs. the comparison function (as duty cycle).