Why My system clock frequency is 66 666 666

Hi,

    See, details in this post below.

    set Tiva C series 80MHZ

- kel

Thank you Markel

OK, but the problem still persist. Even if I compute my delays for 80 000 000 system clock frequency, I get wrong delay periods. Here is my code: 

#define SYS_CLOCK   80000000
#define DELAY		SYS_CLOCK/3  // For 1s delay
int main(void)
{
	SysCtlClockSet (SYSCTL_XTAL_16MHZ | SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
    SysCtlDelay(20);

    GPIOPinTypeGPIOOutput(GPIO_PORTD_BASE, GPIO_PIN_0);

    while(1)
    {
    	GPIOPinWrite( GPIO_PORTD_BASE, GPIO_PIN_0, 0x01 );
    	SysCtlDelay(DELAY);
    	GPIOPinWrite( GPIO_PORTD_BASE, GPIO_PIN_0, 0x00 );
    	SysCtlDelay(DELAY);
    }
}

And This is the scoped output:

I still can't calculate my time delay properly.

Hi,

Looking to your picture there is a good delay interval  (2 divs at 500.0ms) between pulse changes. If you need the period to be 1 second, then there are two such time intervals, defined by the delay function, so a small calculation will solve...

Petrei

Thanks Petrei, 

I know how to attune my delay interval to match 1s. The problem is that I expect the frequency to be exactly 2Hz not 2.23Hz as you can se on the picture. I know that the SysCtlDelay function takes 3 clock cycles for each iteration. Thats why I divided the system clock freq by 3, so to achieve exactly 1 sec delay interval. Excuse my poor English I hope you understand my point.

Thanks Amit. Its OK now :)

I made these macros to make the delay function little bit more user friendly. 

#define SYS_CLOCK   	(40000000)
#define DELAY_CYCLE		(SYS_CLOCK/3)  
#define delay_ms(x)		SysCtlDelay((DELAY_CYCLE/1000)*(x))
#define delay_us(x)		SysCtlDelay((DELAY_CYCLE/1000000)*(x))

It actually works very well. 

Thank you again.

Radoslav Marinov said:

It actually works very well. 

True that - but at the trade-off of one-half of the MCU's rated speed!  Is that good - is that (always) proper?

While "SysCtlDelay()" is appealing - might your investigation into 1 of the MCU's Timers - enable even more precise delays - yet not compromise your MCU's speed of execution? 

ARM Timers are numerous - and (likely) escape that (hidden) prefetch buffer, "gotcha."  May warrant your consideration - surely you'll (need) a real timer - later if not sooner...  What's claimed to, "work very well" is likely sub-optimal - and a superior method may have been (here, now) presented...

I totally agree that timers have many advantages over the SysCtlDelay function. I don't argue with that. I was surprised from the accuracy of the delay function since I read this into the Driver Library Sheets: "It is important to note that this function does NOT provide an accurate timing mechanism".

About the use of SysCtlDelay

SysCtlDelay has the problem of not being consistent. A value that gives a delay of 1s, can give a delay of 2s, depending on the interrupts that you have enabled .

I have a generic project, with all the options and paths i normally need. It has also functions that configure the system tick timer to interrupt every 1ms, the interrupt handler and a function that works as a precise delay.
I advise you to do something similar.
When i need to create a new project i simply add that project, with the option to copy into workspace enabled, and rename the project to whatever i want.

It's something i really like about eclipsed based editors 

Hello Radoslav,

For that matter a "for loop" used for a delay may not result in the same delay across devices-platforms.

Regards

Amit

SysCtlDelay() and/or "for loop" - both may fall victim to prefetch/other gremlins.

MCU's Timers - clocked by system clock - provide precise & predictable timings/delays - and may be easily "scaled" should system clock vary w/application. 

Timers - despite their (missing advocacy) here - really are the best option when timing accuracy & repeatability concern...

And may I add reduced software overhead and complexity for timing...

Regards

Amit