Delay loop in TM4C123GH6PM

Hi,

Somewhere into documentation (Peripheral driver library) is stated this will take three system clock per iteration, so you can use this to figure how much the delay is.

Another method is to check yourself with something like this:

while(1){

     //set a GPIO output pin high

      SysCtlDelay(2000000);

      // set the GPIO pin low

      SysCtlDelay(200);  // very short delay

}

and use an oscilloscope to measure the duration of high pulse (as wel as the low one)

Then open the .asm listing of the function, look what is inside and count the number of asm instruction inside the loop and compute again, assuming there is only one system clock cycle per instruction (well, some instructions may take two system clock cycle...) and compare with the measurement.

Petrei

Hello Petrei

The System Clock and Code position also has a play. If the code is kept across a prefetch buffer when it is enabled it could be higher delay.

Regards

Amit

And - should a scope not be available/handy - use of a "pro" vendor agnostic IDE (such as IAR, Keil) which includes an "automated" cycle counter - provides the exact number of MCU cycles used.  Even the free versions of IAR include this very helpful feature.

Post suggests that you've some interest in Timer accuracy and/or control.  Para. below describes/details...

Unstated (but well known by both here earlier) is use of one of the many ARM MCU Timers - which avoid many of the pitfalls which may impact SysTick's() accuracy...  Bit more effort to set-up iniitially - but you'll use that Timer repeatedly - long into the future...

Hi, 

// This function provides a means of generating a constant length
// delay. The function delay (in cycles) = 3 * parameter. Delay
// 5 seconds arbitrarily.
//
SysCtlDelay((SysCtlClockGet() * 5) / 3);

This shows that it takes 3 instruction cycles and      "(SysCtlClockGet()*REQUIRED TIME)/3"

I came across this line in example code for pwm.    

Hello Haresh,

Please refer back to my post. SysCtlDelay has a dependence on the prefetch mechanism, so may result in unpredictable behavior between code compiles.

Regards

Amit

Also, SysCtlClockGet() has a bug if it was still not fixed...