Counting number of cycles

It would depend on how small the code is. If it is small enough then you can count it by hand, using the ARM reference manual to get the number of cycles per instruction. If the code is longer then you could run it in a simulator and have the simulator count the instructions for you.

ou

Additionally some processors have cycles counters that can be used for things like this, if they aren't already being used. Keep in mind that any context switches will through off both the measurement, and perhaps the point of even taking a measurement. And once you get into the possibility of cache hits/misses, etc... you are talking more average numbers than specific ones.

...assuming interrupts are disabled, otherwise you are not actually measuring the subject code itself.

ou

of

I do believe I said something about the effect of context switches on both the measurement and the utility of taking a measurement...

Yes - you mentioned ensureing no context switches occurred, I was thinking you meant task switches, not interrupts, so I was just adding in that interrupts should be disabled too. Seems like I just misunderstood you.

- Regards, Richard.

• formatting link
  Designed for Microcontrollers. More than 7000 downloads per month.

• formatting link
  Certified by TÜV as meeting the requirements for safety related systems

Many (all?) compilers thesedays have options to 1. generate an assembly listing output and 2. within that listing generate a column that has the number of cycles to execute each instruction. You still want to read through the processor reference manual, as the listing may contain things such as 1/2 for a branch instruction, which may mean it takes 1 cycle if the branch not taken and 2 cycles if the branch is taken. Read through the manual carefully about the CPU operation as there may be things such as invalidated caches that add cycles to execution time.

With a modern processor, it is generally impossible to count the number cycles taken by a piece of code without a simulator as it depends on too many factors and it is going to be different from one time to another. The state of the pipeline, the branch prediction, the cache, the state of the TLB, the state of the SDRAM, the DMA interferrence - all affects the time of the execution dramatically.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

If this is an embedded board and you have a spare port bit, you can profile code in real time by by setting the port bit at start of section and clear it again on exit. Then just use a scope to measure the pulse width. You need to factor in the time taken to set and clear the bit, but this is usually minimal on modern processors.

If you have interrupts going on as well you can see the min/max times in the jitter...

Regards,

Chris