Summary: When developing for Arduino using the arduino IDE, one
doesn't have access to a proper emulator and hence a hardware profiler.
(A profiler gives you a histogram showing where your program is spending
it's time). I have developed a software-only profiler that works
within the memory constraints of even an Arduino UNO. Along the way
I show how to get mixed C/assembler listings out of the avr-g++ compiler
used by the arduino IDE, and how to defeat one particular compiler
optimization that caused the profiler demo to fail.
Nice.
Even better would be if the profiling macros weren't necessary in each function you wish to profile. You could look at SPL and SPH in your ISR to see what code was executing when the ISR fired. Given RAM limitations, you would need to do some hashing of the address and some sort of LRU algorithm.
The problems with looking at the program counter are:
No EASY way (that I know of) to map address to where in the source code you are executing.
Using the PF() macros, it's easy to make the bins as small as you need, in order to
exactly pin down where the slow parts are. If you want to make the bins arbitrarily
small using the "normal" technique of sampling the program counter, then you can
easily run out of RAM on an Arduino UNO.
I chose the macro technique specificially so I could turn an arbitrary section of code
into a profiling bin. Also, dividing the code up into subroutines makes more intuitive
sense than dividing it up into chunks representing equal numbers of bytes.
wfdudley:
The problems with looking at the program counter are:
No EASY way (that I know of) to map address to where in the source code you are executing.
Compile with -g and you should get line number to symbol mapping from avr-objdump
I chose the macro technique specificially so I could turn an arbitrary section of code
into a profiling bin. Also, dividing the code up into subroutines makes more intuitive
sense than dividing it up into chunks representing equal numbers of bytes.
That's not what I am suggesting. The subroutine can be determined from the address.
I'm used to using profilers like gprof, so that's what my idea is based on. http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html
It looks pretty nice. Since you're defining the bins "manually", you ought to the the use give them names instead of just numbers (which is just an indirection to a table of names off in flash, so it shouldn't be very expensive.)