From: FreeRTOS info on


>"Chris Stratton" <cs07024(a)gmail.com> wrote in message
>news:81617aff-bcba-449a-95bb-e504338e139f(a)g31g2000yqc.googlegroups.com...
>On Sep 9, 11:06 am, "FreeRTOS info" <noem...(a)mentioned.com> wrote:
>> "Chris Stratton" <cs07...(a)gmail.com> wrote in message
>>
>> news:dbce54cf-ffce-46a2-bc52-4c459fe41359(a)a7g2000yqo.googlegroups.com...
>> On Sep 9, 10:21 am, "FreeRTOS info" <noem...(a)mentioned.com> wrote:
>>
>>
>>
>> >> > How can I count de exact number of cycles spent by processor during
>> >> > a
>> >> > very small code execution?
>>
>> >> > I'm using an EDB9315A with ARM920T processor running Linux 2.6
>>
>> >> > Thanks in advance,
>>
>> >> 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.
>> >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.

>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.

+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T�V as meeting the requirements for safety related systems



From: Ben Bradley on
On Wed, 9 Sep 2009 15:21:53 +0100, "FreeRTOS info"
<noemail(a)mentioned.com> wrote:

>"Ricardo Menotti" <menotti(a)gmail.com> wrote in message
>news:097f5689-58b0-454d-be69-b257f605ca10(a)k39g2000yqe.googlegroups.com...
>> Dear all,
>>
>> How can I count de exact number of cycles spent by processor during a
>> very small code execution?
>>
>> I'm using an EDB9315A with ARM920T processor running Linux 2.6
>>
>> Thanks in advance,
>
>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.

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.

From: Vladimir Vassilevsky on


Ben Bradley wrote:

> On Wed, 9 Sep 2009 15:21:53 +0100, "FreeRTOS info"
> <noemail(a)mentioned.com> wrote:
>
>
>>"Ricardo Menotti" <menotti(a)gmail.com> wrote in message
>>news:097f5689-58b0-454d-be69-b257f605ca10(a)k39g2000yqe.googlegroups.com...
>>
>>>Dear all,
>>>
>>>How can I count de exact number of cycles spent by processor during a
>>>very small code execution?
>>>
>>>I'm using an EDB9315A with ARM920T processor running Linux 2.6
>>>
>>>Thanks in advance,
>>
>>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.
>
>
> 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
http://www.abvolt.com
From: ChrisQ on
Vladimir Vassilevsky wrote:
>
>
> 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.
>

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