• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 33 subscribers
  • Views 2018 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EK-TM4C123GXL: How to benchmark code?

Laura Brandt
Prodigy 160 points
Part Number: EK-TM4C123GXL


EDIT: Fixed a bug, but still yields the same result.

I tried to use SysTick to time a segment of code, but I am getting an answer that I can tell is wrong. This is what I have done:

SysTickPeriodSet(10000000);

SysTickEnable();

uint32_t numCycles = SysTickValueGet();

// time-intensive code runs here

numCycles = SysTickValueGet() - numCycles;

uint32_t clockRate = SysCtlClockGet();

I then calculate numCycles/clockRate and get 53 seconds as my time, when I can clearly tell that the code is running in less than a second. Am I using SysTick incorrectly/is there a better way to time code on the TM4C123? I need microsecond resolution.

Thanks.

  • 0
    Guru 27665 points

    Laura Brandt said:
    numCycles/clockRate

    What are you expecting this to return?

    Laura Brandt said:
    /is there a better way to time code on the TM4C123? I need microsecond resolution.

    Toggle a pin and use a Digital Storage oscilloscope or Logic Analyzer set in envelope mode with persistence. You will get min and max times as well as a good feel for the time distribution. You should also get a measure of/feel for scheduling jitter.

    Robert

  • 0 in reply to Robert Adsett
    Prodigy 160 points
    I expect numCycles/clockRate to return seconds.
    This is because I interpreted SysTick to be counting clock cycles. Is this incorrect?
  • 0
    TI__Guru 72500 points
    What frequency were you operating at? At 16Mhz the 24-bit system tick counter will overflow in about one second.
  • 0 in reply to Bob Crosby
    Guru 117855 points

    As stated in another (similar) thread - poster has exceeded the 24 bit capacity of SysTick by 1.

  • 0 in reply to cb1_mobile
    Prodigy 160 points
    Thanks for catching this. I reduced the period of SysTick to 10,000,000 (which should easily fit within 24 bits), and am still getting exactly the same issue.
  • 0 in reply to Laura Brandt
    Guru 13040 points
    Laura,

    When you first get your systick counter, it can be any value within the systick cycle of 10,000,000.
    Then you run your code and read it a second time. It could have rolled over that limit, and the second value is lower than the first.
    Your destination variable is a uint32_t, and "god only knows" what the conversion from the negative value will become.

    But as said here, a better way is to use GPIO's and measure it externally, but that might not be so practical/fast. Maybe you'll want to use a 32-bit timer instead of the 24-bit systick? Still, you will have to create a conditional in the case of rollover. Or, since you are using a TM4C123, just go all the way and use a 64-bit timer, there are 6 available if I ain't mistaken!

    Bruno
  • 0 in reply to Laura Brandt
    Guru 117855 points

    If you (seriously) seek to "benchmark" code segments - perhaps its time to consider use of one of the "Pro" IDEs (IAR, Keil) which include an "in-built, Cycle Counter" - which requires NO/ZERO "special coding" - and may be set to report the "Cycles Elapsed" from any 2 code points you specify.

    The use of "less than pristine" tools - while "free" - effectively "charges you in (many) other ways" - as you are noting...

    Lesser tools force you AWAY from your central task - often into areas where you're not sufficiently practiced/experienced - and this (clearly) lessens your productivity.

    As both poster Robert (and I, earlier) have suggested - a strategically placed "pair" of  "GPIO toggles" (surrounding the code block of interest) may prove faster & easier for you.     (and - poster Robert's suggestion of "Envelope Mode" thus revealing "timing variations" (if such are critical) may offer results beyond the "Cycle Capture" of the Pro IDE.      Yet - nothing competes w/the Cycle Counter for quick, zero effort, general benchmark use!)

    Which IS - exactly what you are seeking!

  • 0 in reply to Bruno Saraiva
    Guru 27665 points

    Bruno Saraiva said:
    But as said here, a better way is to use GPIO's and measure it externally, but that might not be so practical/fast.

    It should be faster to use a pin than a timer and it should have less of an affect on the program. Practically it uses tools that are essential to your toolbox and it relies on an extra pin. One reason you should strive to have extra pins available, but worst case use a pin controlling an LED.

    Bruno Saraiva said:
    Maybe you'll want to use a 32-bit timer instead of the 24-bit systick? Still, you will have to create a conditional in the case of rollover

    Not for a 32 bit timer on an ARM (or any processor that supports a uint32_t C type). A least as long as you are certain successive reads are within 2^31 counts of each other in time (~26s at 80MHz). 

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points

    Robert - "love" your inspired "Tag" - bravo. (somehow you "resisted" MCU & Date...)

    You are challenging Bruno's concern re: "conditional detect of rollover" - is that understanding correct?    (so long as "time" measured is w/in ~26.8S.)

  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:
    You are challenging Bruno's concern re: "conditional detect of rollover" - is that understanding correct?

    I am. It is unnecessary and more prone to bugs.

    C/C++ guarantee correct behaviour within the limits I noted(I believe it's a strict guarantee).  It's also going to be correct in assembly on an ARM processor (most 32 bit processors actually).

    Robert