the Chronometer is an excellent feature, it works pleasingly well and accurate…

for assembler code (ARM Cortex M7), I get a clock cycle delta of 12-15 cycles per instruction and I pinned that down to an exact (really exact) overhead of 11 cycles per single step… which gives me a precise instruction delta of 12-11=1 or 13-11=2 cycles per instruction. It fits so well, I can see the delta timing of instructions that need multiple cycles to execute. Theory (reference manual) vs Reality just fits. I just need to subtract the 11-cycle overhead for each single-step, so it would be great if settings had an option so set the overhead per single-step command, which then gets automatically subtracted… how to get the 11 cycles? well, that’s my job to determine this value. And it’s actually not hard… single step in the disassembler window and use the minimum value you see, minus 1 for the actual instruction execution.

I also noticed for conditional instructions, that the timing jumps to 24 cycles. I omit the if-then intrinsic (“it”) as gas assembler generates those for me. I’m not sure, but I assume that VisualGDB issues multiple single-step commands (2 here) to gdb to catch up with the source file, instead of using a temporary hardware breakpoint. If that’s the case, it just highlights the accurate of this feature 11+1+11+1=24.

So, an overhead adjustment (with accounting for multiple single-steps internally) would be fantastic.