what details do i get from disassembly.I have never done it before
Do compiler produces any valuable data to be checked, or is it debuggers that I must entrust?
You'll need to get familiar with the machine language of your particular PIC if you want to start dabbling in optimization. Quite often, you'll see some code which looks innocent enough in C, but in terms of how many machine language instructions it takes, well...
The canonical example of the power of the PIC24 XC16 compiler:
_LATA0 ^= 1; // toggle a bit
becomes this in machine language:
mov.b _LATA,W0
and.b W0,#1,W0
btg W0,#0
and.b W0,#1,W0
and.b W0,#1,W2
mov.w #0x02c4,W1
mov.b [W1],W1
mov.b #0xfe,W0
and.b W1,W0,W0
ior.b W0,W2,W0
mov.b W0,0x02c4
even though there is a bit-toggle machine language instruction btg. Why does this happen? C compilers often don't take advantage of special hardware in their target micros unless the compiler authors specifically target that hardware.
Your first pass at optimization (before measuring) should be a quick browse of the disassembly. See which C instructions are translated into the highest number of machine language instructions. Try different approaches to the problem and see which yield the fewest instructions. You'll quickly build up some experience with what code patterns to avoid and which to stick with.
How can I measure which firmware is best?
What are the common tools available to measure the performance of a firmware?
Is it possible with a Debugger like Pickit3 /ICD3? I got a pickkit3 at hand.
As others have said, the easiest ways are generally:
- by physically toggling some I/O lines and measuring with a scope
- by using the simulator and stopwatch tool available in MPLAB
You 'wrap' your target code with the bit-toggles (or breakpoints) and measure how long execution takes. Then, if you find a performance issue, go back to your disassembly, figure out which code is taking a long time and refactor it, then retest.
